From mailman-bounces@ietf.org Wed Dec 1 09:42:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04321 for ; Wed, 1 Dec 2004 09:42:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZVmR-0001Sw-ED for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 09:48:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSjp-0007jC-FH for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 06:33:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mmusic-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:53:31 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mmusic-web-archive@ietf.org: List Password // URL ---- -------- mmusic@ietf.org ofTV https://www1.ietf.org/mailman/options/mmusic/mmusic-web-archive%40ietf.org From mmusic-bounces@ietf.org Wed Dec 1 13:38:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07995 for ; Wed, 1 Dec 2004 13:38:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZZSl-0007yI-LX for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 13:44:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYU1-0002Dt-Ca; Wed, 01 Dec 2004 12:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXlI-0006G8-3f for mmusic@megatron.ietf.org; Wed, 01 Dec 2004 11:55:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26104 for ; Wed, 1 Dec 2004 11:55:26 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZXqd-0004Za-LO for mmusic@ietf.org; Wed, 01 Dec 2004 12:01:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2004 08:59:44 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB1Gsn2O023118; Wed, 1 Dec 2004 08:54:49 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn4-1319.cisco.com [10.21.85.38]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB1GsM09009885; Wed, 1 Dec 2004 08:54:22 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Wed, 1 Dec 2004 08:54:51 -0800 To: "Alan Clark" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101920063.217061"; x:"432200"; a:"rsa-sha1"; b:"nofws:18367"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"p1WshTKmYBfzAISscLtpT4De3x5/jY8asWa7DEBm1ZC/9OTYm5J2yEtOjoxRc" "/H2NsutRholQWRowh/Qbrs0oqVMEAogKr3BBZIc1a8YZLHTGhYeWxWlZHEns0" "bZ7nZZnfqzm/Dw/DD50tw7GcXuK4oX/+xDsBANky2BIHl5B6c="; c:"From: Mark Baugher "; c:"Subject: Re: [AVT] RFC 3711 and RTCP"; c:"Date: Wed, 1 Dec 2004 08:54:51 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.2 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: [MMUSIC] Re: [AVT] RFC 3711 and RTCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 Content-Transfer-Encoding: 7bit Alan, On Dec 1, 2004, at 4:08 AM, Alan Clark wrote: > Mark > > To provide some background to the list - RFC3611 states the following:- > > "Any encryption or filtering of XR report blocks entails a loss of > monitoring information to third parties. For example, a network > that > establishes a tunnel to encrypt VoIP Report Blocks denies that > information to the service providers traversed by the tunnel. The > service providers cannot then monitor or respond to the quality of > the VoIP calls that they carry, potentially creating problems for > the > network's users. As a default, XR packets should not be encrypted > or > filtered." If this read "MUST NOT be encrypted" then we would not have a potential ambiguity, which is a problem for the signaling. Mark > > I can't conceive of any circumstance in which the contents of an XR > payload > would be remotely useful to an eavesdropper and hence stating that XR > payloads should always be left unencrypted would be (at least in my > opinion) > ok. If we wanted to make this even more specific we could narrow this > requirement down to only XR VoIP Metrics payloads to avoid the > situation in > which some future XR payload may be problematic. > > The availability of VoIP metrics payloads will be a huge issue for > service > providers - as we move through 2005 RTCP XR will be a mainstay of VoIP > performance management and is already a mandatory requirement within > certain > sectors of the industry. Making the VoIP metrics payload unencrypted > by > default may seem a small issue today however it will have major > consequences > to the industry as SRTP starts to roll out. > > Regards > > Alan > > > > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Tuesday, November 30, 2004 6:45 PM > To: Alan Clark > Cc: mmusic@ietf.org > Subject: Re: [AVT] RFC 3711 and RTCP > > > Alan > I am copying MMUSIC (and not cross-posting to AVT) to further > discuss > a possible change to SDP security descriptions, which has completed WG > last call. The change is needed for RFC 3611, and we also discovered > that > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -07.txt does not address the SRTCP E bit properly. I offered the > following text in a posting to AVT: > "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP > packets MUST have the E bit set to zero and MUST NOT be encrypted. > Otherwise, all SRTP packets MUST have the E bit set to one and MUST be > encrypted by default. Individual applications MAY override these > default behaviors in their specifications. In a session where SRTCP > packets are encrypted, therefore, applications that use RFC 3611 MAY > set the E bit to 0 for XR packets as recommended by RFC 3611." > > One of my co-authors pointed out that the last sentence is more than an > editorial change. We also don't like the fact that an offerer or > answerer cannot explicitly signal when it wants the XR packet to be > encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the > default setting and RFC 3611 is also signaled, it is ambiguous as to > whether the SRTCP sender will encrypt the XR packet or not. It's > solely up to the sender. If the offerer or answerer want the XR packet > to always be encrypted, there is no way to signal that. Ditto for the > unencrypted case. > > I think we need to put the first three sentences of the above-quoted > paragraph into SDP security descriptions as an editorial change. I'm > proposing this to the working group. I also propose not to include the > last sentence. Instead, we could add a new signaling parameter, > UNENCRYPTED_XR, which implies that all SRTCP messages are to be > encrypted except for the XR packets, which will have their E bit clear, > of course. > > This new parameter could be placed in an RFC 3611bis or in a revision > of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to > undergo another WG last call. What do you (all) think about this? > > Mark > > On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: > >> Alan >> As Dave Oran has pointed out, the definition that you want is not >> supported in the signaling, at present. The current definition of >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >> -07.txt treats SRTCP encryption as either on or off and does not >> address the problem of setting the E bit in SRTCP packets. This is a >> bug that we need to fix. >> >> MMUSIC has finished last call on >> draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have >> reviewed it. We'll be making some changes at Jon Peterson's request >> and post another version in about a week. This is an opportunity to >> address the E bit, but the MMUSIC chairs or transport ADs may want >> another WG last call. Off the top of my head, I would offer something >> like the following. >> >> "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP >> packets MUST have the E bit set to zero and MUST NOT be encrypted. >> Otherwise, all SRTP packets MUST have the E bit set to one and MUST be >> encrypted by default. Individual applications MAY override these >> default behaviors in their specifications. In a session where SRTCP >> packets are encrypted, therefore, applications that use RFC 3611 MAY >> set the E bit to 0 for XR packets as recommended by RFC 3611." >> >> Mark >> >> On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: >> >>> >>> >>> Mark >>> >>> We tried to flag this in RFC3611 with the following text in the >>> "security >>> considerations" section >>> >>> Any encryption or filtering of XR report blocks entails a loss of >>> monitoring information to third parties. For example, a network >>> that >>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>> information to the service providers traversed by the tunnel. The >>> service providers cannot then monitor or respond to the quality of >>> the VoIP calls that they carry, potentially creating problems for >>> the >>> network's users. As a default, XR packets should not be encrypted >>> or >>> filtered. >>> >>> Could we potentially interpret this as being the definition of what >>> to >>> selectively encrypt in the case of the RFC3611 specification? >>> >>> Regards >>> >>> Alan >>> >>> >>> -----Original Message----- >>> From: Mark Baugher [mailto:mbaugher@cisco.com] >>> Sent: Wednesday, November 24, 2004 2:42 PM >>> To: Alan Clark >>> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R Oran; Michael >>> A. >>> Ramalho >>> Subject: Re: [AVT] RFC 3711 and RTCP >>> >>> >>> So, when the sender and receiver agree to encrypt SRTCP, this would >>> mean >>> only that some SRTCP messages would be encrypted and the sender would >>> decide which ones to encrypt? My personal opinion is that this is >>> not >>> secure because it is unpredictable to the receiver, which may have a >>> policy that all messages related to its session be encrypted. >>> >>> I can think of a few potential approaches to this problem. >>> >>> 1. Let individual SRTCP messages or a bundle of SRTCP messages >>> be signaled to be unencrypted when SRTCP encryption is used. >>> >>> 2. Make a blanket policy that the sender determine what >>> to selectively encrypt, as you suggest. >>> >>> 3. Define the policy of what to selectively encrypt in >>> the particular specification. In other words, a document could >>> re-define the signaling of SRTCP encryption according to its >>> needs. The specification of foo, therefore, could define a new >>> parameter such as foo_ENCRYPTED_SRTCP to be used in place of >>> ENCRYPTED_SRTCP. The foo document would define what gets >>> encrypted and what does not get encrypted as per its needs. >>> >>> I commented on #2 already. I don't like #1 because of its signaling >>> complexity. I like #3 because it limits the complexity to the >>> specific needs of an application. #1 would be more efficient than >>> #3 if lots of applications had their own specific needs for >>> selective encryption of SRTCP message. But I don't think this is >>> the case. >>> >>> Mark >>> >>> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >>> >>>> >>>> If the use of encryption in SRTCP is signalled by an explicit (E) >>>> bit >>>> in the >>>> SRTCP header then perhaps the sender could autonomously decide >>>> whether >>>> it >>>> wants to encrypt? Presumably since the sender is in the best >>>> position >>>> to >>>> decide if the data is sensitive then this would be ok - and the >>>> receiver is >>>> able to just look at the E bit and hence recognize that decryption >>>> is >>>> needed. >>>> >>>> Alan >>>> >>>> -----Original Message----- >>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of >>>> Mark Baugher >>>> Sent: Wednesday, November 24, 2004 1:33 PM >>>> To: David R Oran >>>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>>> avt@ietf.org >>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>> >>>> >>>> >>>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>>> >>>>> >>>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>> I don't see why this would be a problem unless you included SDES >>>>>> and >>>>>> (SR or >>>>>> RR or XR) in the same RTCP packet. SRTP (at least the protocol) >>>>>> is >>>>>> apparently able to decided on a packet by packet basis whether to >>>>>> encrypt >>>>>> RTCP - hopefully SRTP implementations also permit this. >>>>>> >>>>> Sure, they can do this. But remember offer-answer. How does a >>>>> receiver >>>>> communicate such a granular policy to the transmitter? Right now if >>>>> can say whether to auth or auth+encrypt RTP, and auth or >>>>> auth+encrypt >>>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR >>>>> etc. >>>> >>>> Seems to me that this is a problem with SDP security descriptions. >>>> That problem might be there because we forgot about the E bit. This >>>> seems very messy for the reason you mention above - granularity. I >>>> don't think that we want to negotiate the encryption policy for each >>>> type SDP message, which is a problem with something like the E bit. >>>> >>>> Mark >>>>> >>>>> >>>>>> Logically I'd send SDES on its own at the start of a call to >>>>>> provide >>>>>> some >>>>>> user info, but would not send SR/RR/XR until at least 8-10 seconds >>>>>> into the >>>>>> call as I need some time to gather statistics to report. >>>>> That's not exactly what the RTP specs say. RTCP timers don't have >>>>> this >>>>> kind of policy today. In fact, there are porposals on the table to >>>>> use >>>>> RTCP for early feedback to assess reception quality on some initial >>>>> packets - e.g. the RTP-noop proposal. In any event that has no >>>>> bearing >>>>> on the present discussion. >>>>> >>>>>> After the >>>>>> start-of-call exchange there would appear to be minimal need to >>>>>> include >>>>>> SDES. I'm sure we could construct some scenarios in which you >>>>>> "may" >>>>>> need to >>>>>> include SDES with SR/RR/XR however the vast majority of cases >>>>>> would >>>>>> either >>>>>> need only a single initial exchange or may not need SDES at all. >>>>>> >>>>> Any time you change SSRC you potentially need to send SDES. >>>>> That said, I still don't see what bearing this has on the >>>>> discussion >>>>> about whether we need the complexity of encrypting some RTCP >>>>> packets >>>>> and not others for a single session. >>>>> >>>>> It's a tradeoff between extra complexity+less privacy versus >>>>> allowing >>>>> snoopers to gather RTCP stats. >>>>> >>>>> Dave. >>>>> >>>>>> Regards >>>>>> >>>>>> Alan >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>>> Sent: Wednesday, November 24, 2004 9:39 AM >>>>>> To: Alan Clark >>>>>> Cc: Oren Peleg; avt@ietf.org >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>>> Hi Oren >>>>>>> >>>>>>> Yes - encryption is intended to provide privacy however this >>>>>>> relates >>>>>>> primarily to the voice payloads and to information within RTCP >>>>>>> that >>>>>>> may be >>>>>>> associated with individual users (e.g. SDES). >>>>>>> >>>>>>> SR, RR and XR contain only peformance statistics and there is no >>>>>>> privacy >>>>>>> consideration that I can think of related to this type of data. >>>>>>> >>>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>>> don't >>>>>> encrypt >>>>>>> RTCP SR/RR/XR >>>>>> >>>>>> Hi Alan, >>>>>> >>>>>> I am wondering about implementations utilizing your advise >>>>>> "optionally >>>>>> encrypt >>>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>>> >>>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>>> RTCP >>>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>>> highly >>>>>> related to each other. For example (quote out of RFC 3611): >>>>>> >>>>>> "XR packets supplement the existing RTCP packets, and may be >>>>>> stacked >>>>>> with >>>>>> other RTCP packets to form compound RTCP packets [9, Section 6]." >>>>>> >>>>>> Thus, RFC3611 explicitly admits the possibility of (but does not >>>>>> mandate) >>>>>> the piggybacking all the RTCP-XR block types. >>>>>> >>>>>> RTCP implementations would have to know the SRTP encryption rules >>>>>> to >>>>>> make sure they don't perform piggybacking with SDES ... but could >>>>>> allow >>>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR >>>>>> blocks. >>>>>> >>>>>> This RTCP/SRTP interaction/dependency seems to add a burden to >>>>>> both >>>>>> RTCP and SRTP implementations ... let alone the expressiveness >>>>>> required >>>>>> to signal your advise in existing SDP/SRTP mechanisms. >>>>>> >>>>>> Are you aware of any implementations that have actually followed >>>>>> your >>>>>> advise above? I rather go into this one with our eyes open ... >>>>>> developers >>>>>> highly dislike this cross-functional entity dependency (RTCP & >>>>>> SRTP >>>>>> along >>>>>> with expressing it in SDP/SRTP mechanisms). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Michael Ramalho >>>>>> >>>>>> >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Alan >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>>> Sent: Wednesday, November 24, 2004 7:50 AM >>>>>>> To: Alan Clark; avt@ietf.org >>>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>> >>>>>>> >>>>>>> >>>>>>> Isnt encryption is to prevent monitoring from the first place? >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>>>>>> Behalf >>>>>>> Of >>>>>>> Alan Clark >>>>>>> Sent: Tuesday, November 23, 2004 5:42 PM >>>>>>> To: avt@ietf.org >>>>>>> Subject: [AVT] RFC 3711 and RTCP >>>>>>> >>>>>>> >>>>>>>> From the flurry of discussion on RFC3711 it looks as if there is >>>>>>> considerable interest in SRTP implementation. I'd like to add a >>>>>>> request >>>>>>> to >>>>>>> SRTP implementors with regard to manageability. >>>>>>> >>>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>>> block) >>>>>>> contain useful information for network monitoring, and are often >>>>>>> used by >>>>>>> probes and analyzers to support problem diagnosis. RFC3711 >>>>>>> allows >>>>>>> the >>>>>>> selective encryption of RTCP payloads and hence I would strongly >>>>>>> recomment >>>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>>> payloads >>>>>>> as >>>>>>> this >>>>>>> adversely impacts manageability. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Alan Clark >>>>>>> Telchemy >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Audio/Video Transport Working Group >>>>>>> avt@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>> >>>>>>> ***************************************************************** >>>>>>> * >>>>>>> ** >>>>>>> * >>>>>>> ****** >>>>>> * >>>>>>> ******************************** >>>>>>> This email and any files transmitted with it are confidential >>>>>>> material. >>>>>>> They are intended solely for the use of the designated individual >>>>>>> or >>>>>>> entity >>>>>>> to whom they are addressed. >>>>>>> If the reader of this message is not the intended recipient, >>>>>>> you are hereby notified that any dissemination,use, >>>>>>> distribution or copying of this communication is strictly >>>>>>> prohibited >>>>>>> and >>>>>> may >>>>>>> be unlawful. >>>>>>> >>>>>>> If you have received this email in error please notify >>>>>>> postmaster@audiocodes.com and permanently delete the e-mail and >>>>>>> files. >>>>>>> >>>>>>> >>>>>>> ***************************************************************** >>>>>>> * >>>>>>> ** >>>>>>> * >>>>>>> ****** >>>>>> * >>>>>>> ******************************* >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Audio/Video Transport Working Group >>>>>>> avt@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>> David R. Oran >>>>> Cisco Fellow >>>>> Cisco Systems >>>>> 7 Ladyslipper Lane >>>>> Acton, MA 01720 USA >>>>> Tel: +1 978 264 2048 >>>>> Email: oran@cisco.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/avt >>>> >>> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 1 14:19:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11915 for ; Wed, 1 Dec 2004 14:19:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZa64-0000cL-AC for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 14:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZZLt-000437-Fo; Wed, 01 Dec 2004 13:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYSN-0001K8-4Z; Wed, 01 Dec 2004 12:39:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02124; Wed, 1 Dec 2004 12:39:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYXj-0006G1-QD; Wed, 01 Dec 2004 12:45:31 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CZXhL-0004sb-SI; Wed, 01 Dec 2004 11:51:23 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 01 Dec 2004 11:51:23 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: 'Requirements for Internet Media Guides' to Informational RFC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'Requirements for Internet Media Guides ' as an Informational RFC 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 2004-12-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-07.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 1 14:22:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12617 for ; Wed, 1 Dec 2004 14:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZa98-0000rR-DD for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 14:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZZME-0004BQ-Ss; Wed, 01 Dec 2004 13:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYT6-0001jX-Kc; Wed, 01 Dec 2004 12:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02323; Wed, 1 Dec 2004 12:40:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYYT-0006JY-8t; Wed, 01 Dec 2004 12:46:17 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CZXid-0005IO-7F; Wed, 01 Dec 2004 11:52:43 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 01 Dec 2004 11:52:43 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: 'A Framework for the Usage of Internet Media Guides' to Informational RFC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'A Framework for the Usage of Internet Media Guides ' as an Informational RFC 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 2004-12-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-08.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 1 17:03:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01918 for ; Wed, 1 Dec 2004 17:03:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZcf7-0006MR-Ts for mmusic-web-archive@ietf.org; Wed, 01 Dec 2004 17:09:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZc6W-0005d6-IH; Wed, 01 Dec 2004 16:33:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZTH4-00038F-Fh for mmusic@megatron.ietf.org; Wed, 01 Dec 2004 07:07:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19719 for ; Wed, 1 Dec 2004 07:07:55 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZTMN-0006pN-82 for mmusic@ietf.org; Wed, 01 Dec 2004 07:13:28 -0500 Received: from [68.158.5.229] (port=1444 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CZTH2-00015t-3y; Wed, 01 Dec 2004 07:07:56 -0500 From: "Alan Clark" To: "Mark Baugher" Date: Wed, 1 Dec 2004 07:08:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Importance: Normal X-Spam-Score: 1.3 (+) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Dec 2004 16:33:38 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 Content-Transfer-Encoding: 7bit Mark To provide some background to the list - RFC3611 states the following:- "Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets should not be encrypted or filtered." I can't conceive of any circumstance in which the contents of an XR payload would be remotely useful to an eavesdropper and hence stating that XR payloads should always be left unencrypted would be (at least in my opinion) ok. If we wanted to make this even more specific we could narrow this requirement down to only XR VoIP Metrics payloads to avoid the situation in which some future XR payload may be problematic. The availability of VoIP metrics payloads will be a huge issue for service providers - as we move through 2005 RTCP XR will be a mainstay of VoIP performance management and is already a mandatory requirement within certain sectors of the industry. Making the VoIP metrics payload unencrypted by default may seem a small issue today however it will have major consequences to the industry as SRTP starts to roll out. Regards Alan -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Tuesday, November 30, 2004 6:45 PM To: Alan Clark Cc: mmusic@ietf.org Subject: Re: [AVT] RFC 3711 and RTCP Alan I am copying MMUSIC (and not cross-posting to AVT) to further discuss a possible change to SDP security descriptions, which has completed WG last call. The change is needed for RFC 3611, and we also discovered that http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions -07.txt does not address the SRTCP E bit properly. I offered the following text in a posting to AVT: "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP packets MUST have the E bit set to zero and MUST NOT be encrypted. Otherwise, all SRTP packets MUST have the E bit set to one and MUST be encrypted by default. Individual applications MAY override these default behaviors in their specifications. In a session where SRTCP packets are encrypted, therefore, applications that use RFC 3611 MAY set the E bit to 0 for XR packets as recommended by RFC 3611." One of my co-authors pointed out that the last sentence is more than an editorial change. We also don't like the fact that an offerer or answerer cannot explicitly signal when it wants the XR packet to be encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the default setting and RFC 3611 is also signaled, it is ambiguous as to whether the SRTCP sender will encrypt the XR packet or not. It's solely up to the sender. If the offerer or answerer want the XR packet to always be encrypted, there is no way to signal that. Ditto for the unencrypted case. I think we need to put the first three sentences of the above-quoted paragraph into SDP security descriptions as an editorial change. I'm proposing this to the working group. I also propose not to include the last sentence. Instead, we could add a new signaling parameter, UNENCRYPTED_XR, which implies that all SRTCP messages are to be encrypted except for the XR packets, which will have their E bit clear, of course. This new parameter could be placed in an RFC 3611bis or in a revision of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to undergo another WG last call. What do you (all) think about this? Mark On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: > Alan > As Dave Oran has pointed out, the definition that you want is not > supported in the signaling, at present. The current definition of > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -07.txt treats SRTCP encryption as either on or off and does not > address the problem of setting the E bit in SRTCP packets. This is a > bug that we need to fix. > > MMUSIC has finished last call on > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have > reviewed it. We'll be making some changes at Jon Peterson's request > and post another version in about a week. This is an opportunity to > address the E bit, but the MMUSIC chairs or transport ADs may want > another WG last call. Off the top of my head, I would offer something > like the following. > > "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP > packets MUST have the E bit set to zero and MUST NOT be encrypted. > Otherwise, all SRTP packets MUST have the E bit set to one and MUST be > encrypted by default. Individual applications MAY override these > default behaviors in their specifications. In a session where SRTCP > packets are encrypted, therefore, applications that use RFC 3611 MAY > set the E bit to 0 for XR packets as recommended by RFC 3611." > > Mark > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: > >> >> >> Mark >> >> We tried to flag this in RFC3611 with the following text in the >> "security >> considerations" section >> >> Any encryption or filtering of XR report blocks entails a loss of >> monitoring information to third parties. For example, a network >> that >> establishes a tunnel to encrypt VoIP Report Blocks denies that >> information to the service providers traversed by the tunnel. The >> service providers cannot then monitor or respond to the quality of >> the VoIP calls that they carry, potentially creating problems for >> the >> network's users. As a default, XR packets should not be encrypted >> or >> filtered. >> >> Could we potentially interpret this as being the definition of what to >> selectively encrypt in the case of the RFC3611 specification? >> >> Regards >> >> Alan >> >> >> -----Original Message----- >> From: Mark Baugher [mailto:mbaugher@cisco.com] >> Sent: Wednesday, November 24, 2004 2:42 PM >> To: Alan Clark >> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R Oran; Michael >> A. >> Ramalho >> Subject: Re: [AVT] RFC 3711 and RTCP >> >> >> So, when the sender and receiver agree to encrypt SRTCP, this would >> mean >> only that some SRTCP messages would be encrypted and the sender would >> decide which ones to encrypt? My personal opinion is that this is not >> secure because it is unpredictable to the receiver, which may have a >> policy that all messages related to its session be encrypted. >> >> I can think of a few potential approaches to this problem. >> >> 1. Let individual SRTCP messages or a bundle of SRTCP messages >> be signaled to be unencrypted when SRTCP encryption is used. >> >> 2. Make a blanket policy that the sender determine what >> to selectively encrypt, as you suggest. >> >> 3. Define the policy of what to selectively encrypt in >> the particular specification. In other words, a document could >> re-define the signaling of SRTCP encryption according to its >> needs. The specification of foo, therefore, could define a new >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of >> ENCRYPTED_SRTCP. The foo document would define what gets >> encrypted and what does not get encrypted as per its needs. >> >> I commented on #2 already. I don't like #1 because of its signaling >> complexity. I like #3 because it limits the complexity to the >> specific needs of an application. #1 would be more efficient than >> #3 if lots of applications had their own specific needs for >> selective encryption of SRTCP message. But I don't think this is >> the case. >> >> Mark >> >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >> >>> >>> If the use of encryption in SRTCP is signalled by an explicit (E) bit >>> in the >>> SRTCP header then perhaps the sender could autonomously decide >>> whether >>> it >>> wants to encrypt? Presumably since the sender is in the best >>> position >>> to >>> decide if the data is sensitive then this would be ok - and the >>> receiver is >>> able to just look at the E bit and hence recognize that decryption is >>> needed. >>> >>> Alan >>> >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of >>> Mark Baugher >>> Sent: Wednesday, November 24, 2004 1:33 PM >>> To: David R Oran >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>> avt@ietf.org >>> Subject: Re: [AVT] RFC 3711 and RTCP >>> >>> >>> >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>> >>>> >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>> >>>>> >>>>> Michael >>>>> >>>>> I don't see why this would be a problem unless you included SDES >>>>> and >>>>> (SR or >>>>> RR or XR) in the same RTCP packet. SRTP (at least the protocol) is >>>>> apparently able to decided on a packet by packet basis whether to >>>>> encrypt >>>>> RTCP - hopefully SRTP implementations also permit this. >>>>> >>>> Sure, they can do this. But remember offer-answer. How does a >>>> receiver >>>> communicate such a granular policy to the transmitter? Right now if >>>> can say whether to auth or auth+encrypt RTP, and auth or >>>> auth+encrypt >>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR >>>> etc. >>> >>> Seems to me that this is a problem with SDP security descriptions. >>> That problem might be there because we forgot about the E bit. This >>> seems very messy for the reason you mention above - granularity. I >>> don't think that we want to negotiate the encryption policy for each >>> type SDP message, which is a problem with something like the E bit. >>> >>> Mark >>>> >>>> >>>>> Logically I'd send SDES on its own at the start of a call to >>>>> provide >>>>> some >>>>> user info, but would not send SR/RR/XR until at least 8-10 seconds >>>>> into the >>>>> call as I need some time to gather statistics to report. >>>> That's not exactly what the RTP specs say. RTCP timers don't have >>>> this >>>> kind of policy today. In fact, there are porposals on the table to >>>> use >>>> RTCP for early feedback to assess reception quality on some initial >>>> packets - e.g. the RTP-noop proposal. In any event that has no >>>> bearing >>>> on the present discussion. >>>> >>>>> After the >>>>> start-of-call exchange there would appear to be minimal need to >>>>> include >>>>> SDES. I'm sure we could construct some scenarios in which you "may" >>>>> need to >>>>> include SDES with SR/RR/XR however the vast majority of cases would >>>>> either >>>>> need only a single initial exchange or may not need SDES at all. >>>>> >>>> Any time you change SSRC you potentially need to send SDES. >>>> That said, I still don't see what bearing this has on the discussion >>>> about whether we need the complexity of encrypting some RTCP packets >>>> and not others for a single session. >>>> >>>> It's a tradeoff between extra complexity+less privacy versus >>>> allowing >>>> snoopers to gather RTCP stats. >>>> >>>> Dave. >>>> >>>>> Regards >>>>> >>>>> Alan >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>> Sent: Wednesday, November 24, 2004 9:39 AM >>>>> To: Alan Clark >>>>> Cc: Oren Peleg; avt@ietf.org >>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>> >>>>> >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>> Hi Oren >>>>>> >>>>>> Yes - encryption is intended to provide privacy however this >>>>>> relates >>>>>> primarily to the voice payloads and to information within RTCP >>>>>> that >>>>>> may be >>>>>> associated with individual users (e.g. SDES). >>>>>> >>>>>> SR, RR and XR contain only peformance statistics and there is no >>>>>> privacy >>>>>> consideration that I can think of related to this type of data. >>>>>> >>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>> don't >>>>> encrypt >>>>>> RTCP SR/RR/XR >>>>> >>>>> Hi Alan, >>>>> >>>>> I am wondering about implementations utilizing your advise >>>>> "optionally >>>>> encrypt >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>> >>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>> RTCP >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>> highly >>>>> related to each other. For example (quote out of RFC 3611): >>>>> >>>>> "XR packets supplement the existing RTCP packets, and may be >>>>> stacked >>>>> with >>>>> other RTCP packets to form compound RTCP packets [9, Section 6]." >>>>> >>>>> Thus, RFC3611 explicitly admits the possibility of (but does not >>>>> mandate) >>>>> the piggybacking all the RTCP-XR block types. >>>>> >>>>> RTCP implementations would have to know the SRTP encryption rules >>>>> to >>>>> make sure they don't perform piggybacking with SDES ... but could >>>>> allow >>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR >>>>> blocks. >>>>> >>>>> This RTCP/SRTP interaction/dependency seems to add a burden to both >>>>> RTCP and SRTP implementations ... let alone the expressiveness >>>>> required >>>>> to signal your advise in existing SDP/SRTP mechanisms. >>>>> >>>>> Are you aware of any implementations that have actually followed >>>>> your >>>>> advise above? I rather go into this one with our eyes open ... >>>>> developers >>>>> highly dislike this cross-functional entity dependency (RTCP & SRTP >>>>> along >>>>> with expressing it in SDP/SRTP mechanisms). >>>>> >>>>> Regards, >>>>> >>>>> Michael Ramalho >>>>> >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> Alan >>>>>> >>>>>> -----Original Message----- >>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM >>>>>> To: Alan Clark; avt@ietf.org >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>> >>>>>> Isnt encryption is to prevent monitoring from the first place? >>>>>> >>>>>> -----Original Message----- >>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf >>>>>> Of >>>>>> Alan Clark >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM >>>>>> To: avt@ietf.org >>>>>> Subject: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>>> From the flurry of discussion on RFC3711 it looks as if there is >>>>>> considerable interest in SRTP implementation. I'd like to add a >>>>>> request >>>>>> to >>>>>> SRTP implementors with regard to manageability. >>>>>> >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>> block) >>>>>> contain useful information for network monitoring, and are often >>>>>> used by >>>>>> probes and analyzers to support problem diagnosis. RFC3711 allows >>>>>> the >>>>>> selective encryption of RTCP payloads and hence I would strongly >>>>>> recomment >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>> payloads >>>>>> as >>>>>> this >>>>>> adversely impacts manageability. >>>>>> >>>>>> Regards >>>>>> >>>>>> Alan Clark >>>>>> Telchemy >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>>> ****************************************************************** >>>>>> ** >>>>>> * >>>>>> ****** >>>>> * >>>>>> ******************************** >>>>>> This email and any files transmitted with it are confidential >>>>>> material. >>>>>> They are intended solely for the use of the designated individual >>>>>> or >>>>>> entity >>>>>> to whom they are addressed. >>>>>> If the reader of this message is not the intended recipient, >>>>>> you are hereby notified that any dissemination,use, >>>>>> distribution or copying of this communication is strictly >>>>>> prohibited >>>>>> and >>>>> may >>>>>> be unlawful. >>>>>> >>>>>> If you have received this email in error please notify >>>>>> postmaster@audiocodes.com and permanently delete the e-mail and >>>>>> files. >>>>>> >>>>>> >>>>>> ****************************************************************** >>>>>> ** >>>>>> * >>>>>> ****** >>>>> * >>>>>> ******************************* >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>> David R. Oran >>>> Cisco Fellow >>>> Cisco Systems >>>> 7 Ladyslipper Lane >>>> Acton, MA 01720 USA >>>> Tel: +1 978 264 2048 >>>> Email: oran@cisco.com >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/avt >>>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >>> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 2 07:35:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08844 for ; Thu, 2 Dec 2004 07:35:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZqGb-0000l0-6S for mmusic-web-archive@ietf.org; Thu, 02 Dec 2004 07:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZpXI-0000jJ-W0; Thu, 02 Dec 2004 06:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZpP2-0003nk-EM; Thu, 02 Dec 2004 06:45:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04722; Thu, 2 Dec 2004 06:45:37 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZpUX-00089c-OX; Thu, 02 Dec 2004 06:51:22 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB2Bb085023632; Thu, 2 Dec 2004 06:37:00 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB2Bav85023592; Thu, 2 Dec 2004 06:36:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Thu, 2 Dec 2004 13:45:34 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTX8uJBpR0iZEA+R5KHvoJeoHZTHQAcJywA From: "Romascanu, Dan \(Dan\)" To: "Alan Clark" , "Mark Baugher" X-Spam-Score: 0.2 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Content-Transfer-Encoding: quoted-printable Cc: rmonmib@ietf.org, mmusic@ietf.org, avt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Content-Transfer-Encoding: quoted-printable I would be cautious in saying that in no circumstances the contents of = an XR payload would be remotely useful to an eavesdropper. We may = encounter some very security aware environments where even the fact that = a call happens between two IP phones, its duration, or QoS parameters = need to be kept confidential. For this reason, while working to provide = a strong recommendation for RTCP XR packets not to be encrypted, I do = not believe that we can make this a MUST requirements. As an = alternative, I suggest to use RAQMON extensions to report the RTCP XR = metrics to RAQMON collectors without the security risks that may be of = concern in some environments.=20 Regards, Dan > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > Sent: 01 December, 2004 2:08 PM > To: Mark Baugher > Cc: mmusic@ietf.org > Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > Mark >=20 > To provide some background to the list - RFC3611 states the=20 > following:- >=20 > "Any encryption or filtering of XR report blocks entails a loss of > monitoring information to third parties. For example, a=20 > network that > establishes a tunnel to encrypt VoIP Report Blocks denies that > information to the service providers traversed by the tunnel. The > service providers cannot then monitor or respond to the quality of > the VoIP calls that they carry, potentially creating=20 > problems for the > network's users. As a default, XR packets should not be=20 > encrypted or > filtered." >=20 > I can't conceive of any circumstance in which the contents of=20 > an XR payload > would be remotely useful to an eavesdropper and hence stating that XR > payloads should always be left unencrypted would be (at least=20 > in my opinion) > ok. If we wanted to make this even more specific we could narrow this > requirement down to only XR VoIP Metrics payloads to avoid=20 > the situation in > which some future XR payload may be problematic. >=20 > The availability of VoIP metrics payloads will be a huge=20 > issue for service > providers - as we move through 2005 RTCP XR will be a mainstay of VoIP > performance management and is already a mandatory requirement=20 > within certain > sectors of the industry. Making the VoIP metrics payload=20 > unencrypted by > default may seem a small issue today however it will have=20 > major consequences > to the industry as SRTP starts to roll out. >=20 > Regards >=20 > Alan >=20 >=20 >=20 > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Tuesday, November 30, 2004 6:45 PM > To: Alan Clark > Cc: mmusic@ietf.org > Subject: Re: [AVT] RFC 3711 and RTCP >=20 >=20 > Alan > I am copying MMUSIC (and not cross-posting to AVT) to=20 > further discuss > a possible change to SDP security descriptions, which has completed WG > last call. The change is needed for RFC 3611, and we also discovered > that > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -07.txt does not address the SRTCP E bit properly. I offered the > following text in a posting to AVT: > "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP > packets MUST have the E bit set to zero and MUST NOT be encrypted. > Otherwise, all SRTP packets MUST have the E bit set to one and MUST be > encrypted by default. Individual applications MAY override these > default behaviors in their specifications. In a session where SRTCP > packets are encrypted, therefore, applications that use RFC 3611 MAY > set the E bit to 0 for XR packets as recommended by RFC 3611." >=20 > One of my co-authors pointed out that the last sentence is=20 > more than an > editorial change. We also don't like the fact that an offerer or > answerer cannot explicitly signal when it wants the XR packet to be > encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the > default setting and RFC 3611 is also signaled, it is ambiguous as to > whether the SRTCP sender will encrypt the XR packet or not. It's > solely up to the sender. If the offerer or answerer want the=20 > XR packet > to always be encrypted, there is no way to signal that. Ditto for the > unencrypted case. >=20 > I think we need to put the first three sentences of the above-quoted > paragraph into SDP security descriptions as an editorial change. I'm > proposing this to the working group. I also propose not to=20 > include the > last sentence. Instead, we could add a new signaling parameter, > UNENCRYPTED_XR, which implies that all SRTCP messages are to be > encrypted except for the XR packets, which will have their E=20 > bit clear, > of course. >=20 > This new parameter could be placed in an RFC 3611bis or in a revision > of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to > undergo another WG last call. What do you (all) think about this? >=20 > Mark >=20 > On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: >=20 > > Alan > > As Dave Oran has pointed out, the definition that you want is not > > supported in the signaling, at present. The current definition of > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > > -07.txt treats SRTCP encryption as either on or off and does not > > address the problem of setting the E bit in SRTCP packets. =20 > This is a > > bug that we need to fix. > > > > MMUSIC has finished last call on > > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have > > reviewed it. We'll be making some changes at Jon Peterson's request > > and post another version in about a week. This is an opportunity to > > address the E bit, but the MMUSIC chairs or transport ADs may want > > another WG last call. Off the top of my head, I would=20 > offer something > > like the following. > > > > "As the default behavior when UNENCRYPTED_SRTCP is=20 > signaled, all SRTCP > > packets MUST have the E bit set to zero and MUST NOT be encrypted. > > Otherwise, all SRTP packets MUST have the E bit set to one=20 > and MUST be > > encrypted by default. Individual applications MAY override these > > default behaviors in their specifications. In a session where SRTCP > > packets are encrypted, therefore, applications that use RFC 3611 MAY > > set the E bit to 0 for XR packets as recommended by RFC 3611." > > > > Mark > > > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: > > > >> > >> > >> Mark > >> > >> We tried to flag this in RFC3611 with the following text in the > >> "security > >> considerations" section > >> > >> Any encryption or filtering of XR report blocks entails=20 > a loss of > >> monitoring information to third parties. For example, a network > >> that > >> establishes a tunnel to encrypt VoIP Report Blocks denies that > >> information to the service providers traversed by the=20 > tunnel. The > >> service providers cannot then monitor or respond to the=20 > quality of > >> the VoIP calls that they carry, potentially creating=20 > problems for > >> the > >> network's users. As a default, XR packets should not=20 > be encrypted > >> or > >> filtered. > >> > >> Could we potentially interpret this as being the=20 > definition of what to > >> selectively encrypt in the case of the RFC3611 specification? > >> > >> Regards > >> > >> Alan > >> > >> > >> -----Original Message----- > >> From: Mark Baugher [mailto:mbaugher@cisco.com] > >> Sent: Wednesday, November 24, 2004 2:42 PM > >> To: Alan Clark > >> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R=20 > Oran; Michael > >> A. > >> Ramalho > >> Subject: Re: [AVT] RFC 3711 and RTCP > >> > >> > >> So, when the sender and receiver agree to encrypt SRTCP, this would > >> mean > >> only that some SRTCP messages would be encrypted and the=20 > sender would > >> decide which ones to encrypt? My personal opinion is that=20 > this is not > >> secure because it is unpredictable to the receiver, which=20 > may have a > >> policy that all messages related to its session be encrypted. > >> > >> I can think of a few potential approaches to this problem. > >> > >> 1. Let individual SRTCP messages or a bundle of SRTCP messages > >> be signaled to be unencrypted when SRTCP encryption is used. > >> > >> 2. Make a blanket policy that the sender determine what > >> to selectively encrypt, as you suggest. > >> > >> 3. Define the policy of what to selectively encrypt in > >> the particular specification. In other words, a document could > >> re-define the signaling of SRTCP encryption according to its > >> needs. The specification of foo, therefore, could define a new > >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of > >> ENCRYPTED_SRTCP. The foo document would define what gets > >> encrypted and what does not get encrypted as per its needs. > >> > >> I commented on #2 already. I don't like #1 because of its=20 > signaling > >> complexity. I like #3 because it limits the complexity to the > >> specific needs of an application. #1 would be more efficient than > >> #3 if lots of applications had their own specific needs for > >> selective encryption of SRTCP message. But I don't think this is > >> the case. > >> > >> Mark > >> > >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: > >> > >>> > >>> If the use of encryption in SRTCP is signalled by an=20 > explicit (E) bit > >>> in the > >>> SRTCP header then perhaps the sender could autonomously decide > >>> whether > >>> it > >>> wants to encrypt? Presumably since the sender is in the best > >>> position > >>> to > >>> decide if the data is sensitive then this would be ok - and the > >>> receiver is > >>> able to just look at the E bit and hence recognize that=20 > decryption is > >>> needed. > >>> > >>> Alan > >>> > >>> -----Original Message----- > >>> From: avt-bounces@ietf.org=20 > [mailto:avt-bounces@ietf.org]On Behalf Of > >>> Mark Baugher > >>> Sent: Wednesday, November 24, 2004 1:33 PM > >>> To: David R Oran > >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; > >>> avt@ietf.org > >>> Subject: Re: [AVT] RFC 3711 and RTCP > >>> > >>> > >>> > >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: > >>> > >>>> > >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: > >>>> > >>>>> > >>>>> Michael > >>>>> > >>>>> I don't see why this would be a problem unless you included SDES > >>>>> and > >>>>> (SR or > >>>>> RR or XR) in the same RTCP packet. SRTP (at least the=20 > protocol) is > >>>>> apparently able to decided on a packet by packet basis=20 > whether to > >>>>> encrypt > >>>>> RTCP - hopefully SRTP implementations also permit this. > >>>>> > >>>> Sure, they can do this. But remember offer-answer. How does a > >>>> receiver > >>>> communicate such a granular policy to the transmitter?=20 > Right now if > >>>> can say whether to auth or auth+encrypt RTP, and auth or > >>>> auth+encrypt > >>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR > >>>> etc. > >>> > >>> Seems to me that this is a problem with SDP security descriptions. > >>> That problem might be there because we forgot about the E=20 > bit. This > >>> seems very messy for the reason you mention above -=20 > granularity. I > >>> don't think that we want to negotiate the encryption=20 > policy for each > >>> type SDP message, which is a problem with something like=20 > the E bit. > >>> > >>> Mark > >>>> > >>>> > >>>>> Logically I'd send SDES on its own at the start of a call to > >>>>> provide > >>>>> some > >>>>> user info, but would not send SR/RR/XR until at least=20 > 8-10 seconds > >>>>> into the > >>>>> call as I need some time to gather statistics to report. > >>>> That's not exactly what the RTP specs say. RTCP timers don't have > >>>> this > >>>> kind of policy today. In fact, there are porposals on=20 > the table to > >>>> use > >>>> RTCP for early feedback to assess reception quality on=20 > some initial > >>>> packets - e.g. the RTP-noop proposal. In any event that has no > >>>> bearing > >>>> on the present discussion. > >>>> > >>>>> After the > >>>>> start-of-call exchange there would appear to be minimal need to > >>>>> include > >>>>> SDES. I'm sure we could construct some scenarios in=20 > which you "may" > >>>>> need to > >>>>> include SDES with SR/RR/XR however the vast majority of=20 > cases would > >>>>> either > >>>>> need only a single initial exchange or may not need SDES at all. > >>>>> > >>>> Any time you change SSRC you potentially need to send SDES. > >>>> That said, I still don't see what bearing this has on=20 > the discussion > >>>> about whether we need the complexity of encrypting some=20 > RTCP packets > >>>> and not others for a single session. > >>>> > >>>> It's a tradeoff between extra complexity+less privacy versus > >>>> allowing > >>>> snoopers to gather RTCP stats. > >>>> > >>>> Dave. > >>>> > >>>>> Regards > >>>>> > >>>>> Alan > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] > >>>>> Sent: Wednesday, November 24, 2004 9:39 AM > >>>>> To: Alan Clark > >>>>> Cc: Oren Peleg; avt@ietf.org > >>>>> Subject: RE: [AVT] RFC 3711 and RTCP > >>>>> > >>>>> > >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: > >>>>>> Hi Oren > >>>>>> > >>>>>> Yes - encryption is intended to provide privacy however this > >>>>>> relates > >>>>>> primarily to the voice payloads and to information within RTCP > >>>>>> that > >>>>>> may be > >>>>>> associated with individual users (e.g. SDES). > >>>>>> > >>>>>> SR, RR and XR contain only peformance statistics and=20 > there is no > >>>>>> privacy > >>>>>> consideration that I can think of related to this type of data. > >>>>>> > >>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but > >>>>>> don't > >>>>> encrypt > >>>>>> RTCP SR/RR/XR > >>>>> > >>>>> Hi Alan, > >>>>> > >>>>> I am wondering about implementations utilizing your advise > >>>>> "optionally > >>>>> encrypt > >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". > >>>>> > >>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not > >>>>> RTCP > >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be > >>>>> highly > >>>>> related to each other. For example (quote out of RFC 3611): > >>>>> > >>>>> "XR packets supplement the existing RTCP packets, and may be > >>>>> stacked > >>>>> with > >>>>> other RTCP packets to form compound RTCP packets [9,=20 > Section 6]." > >>>>> > >>>>> Thus, RFC3611 explicitly admits the possibility of (but does not > >>>>> mandate) > >>>>> the piggybacking all the RTCP-XR block types. > >>>>> > >>>>> RTCP implementations would have to know the SRTP=20 > encryption rules > >>>>> to > >>>>> make sure they don't perform piggybacking with SDES ...=20 > but could > >>>>> allow > >>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR > >>>>> blocks. > >>>>> > >>>>> This RTCP/SRTP interaction/dependency seems to add a=20 > burden to both > >>>>> RTCP and SRTP implementations ... let alone the expressiveness > >>>>> required > >>>>> to signal your advise in existing SDP/SRTP mechanisms. > >>>>> > >>>>> Are you aware of any implementations that have actually followed > >>>>> your > >>>>> advise above? I rather go into this one with our eyes open ... > >>>>> developers > >>>>> highly dislike this cross-functional entity dependency=20 > (RTCP & SRTP > >>>>> along > >>>>> with expressing it in SDP/SRTP mechanisms). > >>>>> > >>>>> Regards, > >>>>> > >>>>> Michael Ramalho > >>>>> > >>>>> > >>>>> > >>>>>> Regards > >>>>>> > >>>>>> Alan > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] > >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM > >>>>>> To: Alan Clark; avt@ietf.org > >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP > >>>>>> > >>>>>> > >>>>>> > >>>>>> Isnt encryption is to prevent monitoring from the first place? > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: avt-bounces@ietf.org=20 > [mailto:avt-bounces@ietf.org] On Behalf > >>>>>> Of > >>>>>> Alan Clark > >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM > >>>>>> To: avt@ietf.org > >>>>>> Subject: [AVT] RFC 3711 and RTCP > >>>>>> > >>>>>> > >>>>>>> From the flurry of discussion on RFC3711 it looks as=20 > if there is > >>>>>> considerable interest in SRTP implementation. I'd=20 > like to add a > >>>>>> request > >>>>>> to > >>>>>> SRTP implementors with regard to manageability. > >>>>>> > >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report > >>>>>> block) > >>>>>> contain useful information for network monitoring, and=20 > are often > >>>>>> used by > >>>>>> probes and analyzers to support problem diagnosis. =20 > RFC3711 allows > >>>>>> the > >>>>>> selective encryption of RTCP payloads and hence I=20 > would strongly > >>>>>> recomment > >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR > >>>>>> payloads > >>>>>> as > >>>>>> this > >>>>>> adversely impacts manageability. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Alan Clark > >>>>>> Telchemy > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Audio/Video Transport Working Group > >>>>>> avt@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>>> > >>>>>>=20 > ****************************************************************** > >>>>>> ** > >>>>>> * > >>>>>> ****** > >>>>> * > >>>>>> ******************************** > >>>>>> This email and any files transmitted with it are confidential > >>>>>> material. > >>>>>> They are intended solely for the use of the designated=20 > individual > >>>>>> or > >>>>>> entity > >>>>>> to whom they are addressed. > >>>>>> If the reader of this message is not the intended recipient, > >>>>>> you are hereby notified that any dissemination,use, > >>>>>> distribution or copying of this communication is strictly > >>>>>> prohibited > >>>>>> and > >>>>> may > >>>>>> be unlawful. > >>>>>> > >>>>>> If you have received this email in error please notify > >>>>>> postmaster@audiocodes.com and permanently delete the e-mail and > >>>>>> files. > >>>>>> > >>>>>> > >>>>>>=20 > ****************************************************************** > >>>>>> ** > >>>>>> * > >>>>>> ****** > >>>>> * > >>>>>> ******************************* > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Audio/Video Transport Working Group > >>>>>> avt@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Audio/Video Transport Working Group > >>>>> avt@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>> > >>>> David R. Oran > >>>> Cisco Fellow > >>>> Cisco Systems > >>>> 7 Ladyslipper Lane > >>>> Acton, MA 01720 USA > >>>> Tel: +1 978 264 2048 > >>>> Email: oran@cisco.com > >>>> > >>>> > >>>> _______________________________________________ > >>>> Audio/Video Transport Working Group > >>>> avt@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/avt > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Audio/Video Transport Working Group > >>> avt@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/avt > >>> > >> > > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 2 07:41:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09925 for ; Thu, 2 Dec 2004 07:41:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZqMu-00011r-4t for mmusic-web-archive@ietf.org; Thu, 02 Dec 2004 07:47:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZqCk-0003VN-EN; Thu, 02 Dec 2004 07:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZpcH-0004Ps-7J for mmusic@megatron.ietf.org; Thu, 02 Dec 2004 06:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05677 for ; Thu, 2 Dec 2004 06:59:18 -0500 (EST) From: georg.mayer@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZphm-0008RK-EE for mmusic@ietf.org; Thu, 02 Dec 2004 07:05:03 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB2BxEv24668 for ; Thu, 2 Dec 2004 13:59:17 +0200 (EET) X-Scanned: Thu, 2 Dec 2004 13:58:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iB2Bwils019891 for ; Thu, 2 Dec 2004 13:58:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00ljcjIv; Thu, 02 Dec 2004 13:58:29 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB2BwSS29587 for ; Thu, 2 Dec 2004 13:58:28 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Dec 2004 13:58:27 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Dec 2004 13:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Dec 2004 13:58:04 +0200 Message-ID: <494EC06A45CAE241B0C49250CE93E4BC04F165@esebe054.ntc.nokia.com> Thread-Topic: RFC 3312: Setting of send and recv tags for send/receive only media stream Thread-Index: AcTYZi2O1oiMDI6FQAWuhObleMIizg== To: X-OriginalArrivalTime: 02 Dec 2004 11:58:02.0795 (UTC) FILETIME=[2D16CFB0:01C4D866] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RFC 3312: Setting of send and recv tags for send/receive only media stream X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Hello, I have a question on interpretation of the precondition RFC 3312. The questions is on the following paragraph in RFC 3312:=09 The values of the tags "send", "recv", "local" and "remote" = represent the point of view of the entity generating the SDP = description. In an offer, "send" is the direction offerer->answerer and = "local" is the offerer's access network. In an answer, "send" is the = direction answerer->offerer and "local" is the answerer's access = network.=20 How have the send/recv tags of preconditions to be set when a sendonly / = receiveonly media stream from A to B is to be established? My = understanding is as follows: INVITE (from A, who will be sending the stream) a=3Dcurr:qos local none a=3Dcurr:qos remote none a=3Ddes:qos mandatory local send a=3Ddes:qos none remote recv 183 (from B, who will be receiving the stream) a=3Dcurr:qos remote none a=3Dcurr:qos local none a=3Ddes:qos mandatory remote send a=3Ddes:qos mandatory local recv a=3Dconf:qos remote send Now the question was whether in the fourth line of the INVITE, it should = be a=3Ddes:qos none remote recv or a=3Ddes:qos none remote send And the same question would apply to the third line of the 183, should = it be=20 a=3Ddes:qos mandatory remote send or a=3Ddes:qos mandatory remote recv ----------------------------------- http://www.imsbook.com ------------------------------------ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 2 18:41:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15258 for ; Thu, 2 Dec 2004 18:41:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca0fZ-0002j6-Ti for mmusic-web-archive@ietf.org; Thu, 02 Dec 2004 18:47:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZwHw-00088v-AD; Thu, 02 Dec 2004 14:06:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZuMN-00015d-Nv; Thu, 02 Dec 2004 12:03:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09120; Thu, 2 Dec 2004 12:03:12 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZuRu-0001A3-11; Thu, 02 Dec 2004 12:09:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Dec 2004 09:07:38 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB2H2K2O024786; Thu, 2 Dec 2004 09:02:21 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn1-546.cisco.com [10.21.98.34]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB2H21Xv018796; Thu, 2 Dec 2004 09:02:01 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Thu, 2 Dec 2004 09:02:33 -0800 To: "Romascanu, Dan \(Dan\)" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102006922.172912"; x:"432200"; a:"rsa-sha1"; b:"nofws:20871"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"FKYAMQH+Yu9kofBZSxUSrsv+Ndpb8ztHL5uP38QaHjUXl0UucJ+nzZt4R8t0E" "+CvR9/C7sWatboAX0EK8Cno0yJz9Danqehum819o/9I1+bCKTxJis29QZnK6j" "56oSAxANlQwu6lSgYTMFchoG8Nr/tAkr2K6meAZJRQ/aVILT8="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Thu, 2 Dec 2004 09:02:33 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc Content-Transfer-Encoding: 7bit Cc: rmonmib@ietf.org, avt@ietf.org, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a Content-Transfer-Encoding: 7bit Dan I think use of the E bit needs to be explicitly signaled the SDP security descriptions. That way, an offerer or answerer can express whether it wants to have all SRTCP messages encrypted or allow some to be in the clear. I don't know if we need to call out the specific SRTCP messages that may be left in the clear or do make it "general purpose." A general-purpose approach would be to signal that ENCRYPTED_SRTP can be overridden for any packet for which the sender chooses to clear the E bit. The general-purpose mechanism might be suitable for going into draft-ietf-mmusic-sdescriptions-08.txt. If we want to explicitly signal that the E bit can be clear just for XR packets when UNENCRYPTED_SRTCP is set, then I think that belongs in RFC 3611bis. Mark On Dec 2, 2004, at 3:45 AM, Romascanu, Dan ((Dan)) wrote: > I would be cautious in saying that in no circumstances the contents of > an XR payload would be remotely useful to an eavesdropper. We may > encounter some very security aware environments where even the fact > that a call happens between two IP phones, its duration, or QoS > parameters need to be kept confidential. For this reason, while > working to provide a strong recommendation for RTCP XR packets not to > be encrypted, I do not believe that we can make this a MUST > requirements. As an alternative, I suggest to use RAQMON extensions > to report the RTCP XR metrics to RAQMON collectors without the > security risks that may be of concern in some environments. > > Regards, > > Dan > > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark >> Sent: 01 December, 2004 2:08 PM >> To: Mark Baugher >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >> >> >> Mark >> >> To provide some background to the list - RFC3611 states the >> following:- >> >> "Any encryption or filtering of XR report blocks entails a loss of >> monitoring information to third parties. For example, a >> network that >> establishes a tunnel to encrypt VoIP Report Blocks denies that >> information to the service providers traversed by the tunnel. The >> service providers cannot then monitor or respond to the quality of >> the VoIP calls that they carry, potentially creating >> problems for the >> network's users. As a default, XR packets should not be >> encrypted or >> filtered." >> >> I can't conceive of any circumstance in which the contents of >> an XR payload >> would be remotely useful to an eavesdropper and hence stating that XR >> payloads should always be left unencrypted would be (at least >> in my opinion) >> ok. If we wanted to make this even more specific we could narrow this >> requirement down to only XR VoIP Metrics payloads to avoid >> the situation in >> which some future XR payload may be problematic. >> >> The availability of VoIP metrics payloads will be a huge >> issue for service >> providers - as we move through 2005 RTCP XR will be a mainstay of VoIP >> performance management and is already a mandatory requirement >> within certain >> sectors of the industry. Making the VoIP metrics payload >> unencrypted by >> default may seem a small issue today however it will have >> major consequences >> to the industry as SRTP starts to roll out. >> >> Regards >> >> Alan >> >> >> >> -----Original Message----- >> From: Mark Baugher [mailto:mbaugher@cisco.com] >> Sent: Tuesday, November 30, 2004 6:45 PM >> To: Alan Clark >> Cc: mmusic@ietf.org >> Subject: Re: [AVT] RFC 3711 and RTCP >> >> >> Alan >> I am copying MMUSIC (and not cross-posting to AVT) to >> further discuss >> a possible change to SDP security descriptions, which has completed WG >> last call. The change is needed for RFC 3611, and we also discovered >> that >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >> -07.txt does not address the SRTCP E bit properly. I offered the >> following text in a posting to AVT: >> "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP >> packets MUST have the E bit set to zero and MUST NOT be encrypted. >> Otherwise, all SRTP packets MUST have the E bit set to one and MUST be >> encrypted by default. Individual applications MAY override these >> default behaviors in their specifications. In a session where SRTCP >> packets are encrypted, therefore, applications that use RFC 3611 MAY >> set the E bit to 0 for XR packets as recommended by RFC 3611." >> >> One of my co-authors pointed out that the last sentence is >> more than an >> editorial change. We also don't like the fact that an offerer or >> answerer cannot explicitly signal when it wants the XR packet to be >> encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the >> default setting and RFC 3611 is also signaled, it is ambiguous as to >> whether the SRTCP sender will encrypt the XR packet or not. It's >> solely up to the sender. If the offerer or answerer want the >> XR packet >> to always be encrypted, there is no way to signal that. Ditto for the >> unencrypted case. >> >> I think we need to put the first three sentences of the above-quoted >> paragraph into SDP security descriptions as an editorial change. I'm >> proposing this to the working group. I also propose not to >> include the >> last sentence. Instead, we could add a new signaling parameter, >> UNENCRYPTED_XR, which implies that all SRTCP messages are to be >> encrypted except for the XR packets, which will have their E >> bit clear, >> of course. >> >> This new parameter could be placed in an RFC 3611bis or in a revision >> of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to >> undergo another WG last call. What do you (all) think about this? >> >> Mark >> >> On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: >> >>> Alan >>> As Dave Oran has pointed out, the definition that you want is not >>> supported in the signaling, at present. The current definition of >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>> -07.txt treats SRTCP encryption as either on or off and does not >>> address the problem of setting the E bit in SRTCP packets. >> This is a >>> bug that we need to fix. >>> >>> MMUSIC has finished last call on >>> draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have >>> reviewed it. We'll be making some changes at Jon Peterson's request >>> and post another version in about a week. This is an opportunity to >>> address the E bit, but the MMUSIC chairs or transport ADs may want >>> another WG last call. Off the top of my head, I would >> offer something >>> like the following. >>> >>> "As the default behavior when UNENCRYPTED_SRTCP is >> signaled, all SRTCP >>> packets MUST have the E bit set to zero and MUST NOT be encrypted. >>> Otherwise, all SRTP packets MUST have the E bit set to one >> and MUST be >>> encrypted by default. Individual applications MAY override these >>> default behaviors in their specifications. In a session where SRTCP >>> packets are encrypted, therefore, applications that use RFC 3611 MAY >>> set the E bit to 0 for XR packets as recommended by RFC 3611." >>> >>> Mark >>> >>> On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: >>> >>>> >>>> >>>> Mark >>>> >>>> We tried to flag this in RFC3611 with the following text in the >>>> "security >>>> considerations" section >>>> >>>> Any encryption or filtering of XR report blocks entails >> a loss of >>>> monitoring information to third parties. For example, a network >>>> that >>>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>>> information to the service providers traversed by the >> tunnel. The >>>> service providers cannot then monitor or respond to the >> quality of >>>> the VoIP calls that they carry, potentially creating >> problems for >>>> the >>>> network's users. As a default, XR packets should not >> be encrypted >>>> or >>>> filtered. >>>> >>>> Could we potentially interpret this as being the >> definition of what to >>>> selectively encrypt in the case of the RFC3611 specification? >>>> >>>> Regards >>>> >>>> Alan >>>> >>>> >>>> -----Original Message----- >>>> From: Mark Baugher [mailto:mbaugher@cisco.com] >>>> Sent: Wednesday, November 24, 2004 2:42 PM >>>> To: Alan Clark >>>> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R >> Oran; Michael >>>> A. >>>> Ramalho >>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>> >>>> >>>> So, when the sender and receiver agree to encrypt SRTCP, this would >>>> mean >>>> only that some SRTCP messages would be encrypted and the >> sender would >>>> decide which ones to encrypt? My personal opinion is that >> this is not >>>> secure because it is unpredictable to the receiver, which >> may have a >>>> policy that all messages related to its session be encrypted. >>>> >>>> I can think of a few potential approaches to this problem. >>>> >>>> 1. Let individual SRTCP messages or a bundle of SRTCP messages >>>> be signaled to be unencrypted when SRTCP encryption is used. >>>> >>>> 2. Make a blanket policy that the sender determine what >>>> to selectively encrypt, as you suggest. >>>> >>>> 3. Define the policy of what to selectively encrypt in >>>> the particular specification. In other words, a document could >>>> re-define the signaling of SRTCP encryption according to its >>>> needs. The specification of foo, therefore, could define a new >>>> parameter such as foo_ENCRYPTED_SRTCP to be used in place of >>>> ENCRYPTED_SRTCP. The foo document would define what gets >>>> encrypted and what does not get encrypted as per its needs. >>>> >>>> I commented on #2 already. I don't like #1 because of its >> signaling >>>> complexity. I like #3 because it limits the complexity to the >>>> specific needs of an application. #1 would be more efficient than >>>> #3 if lots of applications had their own specific needs for >>>> selective encryption of SRTCP message. But I don't think this is >>>> the case. >>>> >>>> Mark >>>> >>>> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >>>> >>>>> >>>>> If the use of encryption in SRTCP is signalled by an >> explicit (E) bit >>>>> in the >>>>> SRTCP header then perhaps the sender could autonomously decide >>>>> whether >>>>> it >>>>> wants to encrypt? Presumably since the sender is in the best >>>>> position >>>>> to >>>>> decide if the data is sensitive then this would be ok - and the >>>>> receiver is >>>>> able to just look at the E bit and hence recognize that >> decryption is >>>>> needed. >>>>> >>>>> Alan >>>>> >>>>> -----Original Message----- >>>>> From: avt-bounces@ietf.org >> [mailto:avt-bounces@ietf.org]On Behalf Of >>>>> Mark Baugher >>>>> Sent: Wednesday, November 24, 2004 1:33 PM >>>>> To: David R Oran >>>>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>>>> avt@ietf.org >>>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>>> >>>>> >>>>> >>>>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>>>> >>>>>> >>>>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>>>> >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> I don't see why this would be a problem unless you included SDES >>>>>>> and >>>>>>> (SR or >>>>>>> RR or XR) in the same RTCP packet. SRTP (at least the >> protocol) is >>>>>>> apparently able to decided on a packet by packet basis >> whether to >>>>>>> encrypt >>>>>>> RTCP - hopefully SRTP implementations also permit this. >>>>>>> >>>>>> Sure, they can do this. But remember offer-answer. How does a >>>>>> receiver >>>>>> communicate such a granular policy to the transmitter? >> Right now if >>>>>> can say whether to auth or auth+encrypt RTP, and auth or >>>>>> auth+encrypt >>>>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR >>>>>> etc. >>>>> >>>>> Seems to me that this is a problem with SDP security descriptions. >>>>> That problem might be there because we forgot about the E >> bit. This >>>>> seems very messy for the reason you mention above - >> granularity. I >>>>> don't think that we want to negotiate the encryption >> policy for each >>>>> type SDP message, which is a problem with something like >> the E bit. >>>>> >>>>> Mark >>>>>> >>>>>> >>>>>>> Logically I'd send SDES on its own at the start of a call to >>>>>>> provide >>>>>>> some >>>>>>> user info, but would not send SR/RR/XR until at least >> 8-10 seconds >>>>>>> into the >>>>>>> call as I need some time to gather statistics to report. >>>>>> That's not exactly what the RTP specs say. RTCP timers don't have >>>>>> this >>>>>> kind of policy today. In fact, there are porposals on >> the table to >>>>>> use >>>>>> RTCP for early feedback to assess reception quality on >> some initial >>>>>> packets - e.g. the RTP-noop proposal. In any event that has no >>>>>> bearing >>>>>> on the present discussion. >>>>>> >>>>>>> After the >>>>>>> start-of-call exchange there would appear to be minimal need to >>>>>>> include >>>>>>> SDES. I'm sure we could construct some scenarios in >> which you "may" >>>>>>> need to >>>>>>> include SDES with SR/RR/XR however the vast majority of >> cases would >>>>>>> either >>>>>>> need only a single initial exchange or may not need SDES at all. >>>>>>> >>>>>> Any time you change SSRC you potentially need to send SDES. >>>>>> That said, I still don't see what bearing this has on >> the discussion >>>>>> about whether we need the complexity of encrypting some >> RTCP packets >>>>>> and not others for a single session. >>>>>> >>>>>> It's a tradeoff between extra complexity+less privacy versus >>>>>> allowing >>>>>> snoopers to gather RTCP stats. >>>>>> >>>>>> Dave. >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Alan >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>>>> Sent: Wednesday, November 24, 2004 9:39 AM >>>>>>> To: Alan Clark >>>>>>> Cc: Oren Peleg; avt@ietf.org >>>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>> >>>>>>> >>>>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>>>> Hi Oren >>>>>>>> >>>>>>>> Yes - encryption is intended to provide privacy however this >>>>>>>> relates >>>>>>>> primarily to the voice payloads and to information within RTCP >>>>>>>> that >>>>>>>> may be >>>>>>>> associated with individual users (e.g. SDES). >>>>>>>> >>>>>>>> SR, RR and XR contain only peformance statistics and >> there is no >>>>>>>> privacy >>>>>>>> consideration that I can think of related to this type of data. >>>>>>>> >>>>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>>>> don't >>>>>>> encrypt >>>>>>>> RTCP SR/RR/XR >>>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> I am wondering about implementations utilizing your advise >>>>>>> "optionally >>>>>>> encrypt >>>>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>>>> >>>>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>>>> RTCP >>>>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>>>> highly >>>>>>> related to each other. For example (quote out of RFC 3611): >>>>>>> >>>>>>> "XR packets supplement the existing RTCP packets, and may be >>>>>>> stacked >>>>>>> with >>>>>>> other RTCP packets to form compound RTCP packets [9, >> Section 6]." >>>>>>> >>>>>>> Thus, RFC3611 explicitly admits the possibility of (but does not >>>>>>> mandate) >>>>>>> the piggybacking all the RTCP-XR block types. >>>>>>> >>>>>>> RTCP implementations would have to know the SRTP >> encryption rules >>>>>>> to >>>>>>> make sure they don't perform piggybacking with SDES ... >> but could >>>>>>> allow >>>>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR >>>>>>> blocks. >>>>>>> >>>>>>> This RTCP/SRTP interaction/dependency seems to add a >> burden to both >>>>>>> RTCP and SRTP implementations ... let alone the expressiveness >>>>>>> required >>>>>>> to signal your advise in existing SDP/SRTP mechanisms. >>>>>>> >>>>>>> Are you aware of any implementations that have actually followed >>>>>>> your >>>>>>> advise above? I rather go into this one with our eyes open ... >>>>>>> developers >>>>>>> highly dislike this cross-functional entity dependency >> (RTCP & SRTP >>>>>>> along >>>>>>> with expressing it in SDP/SRTP mechanisms). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael Ramalho >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Alan >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>>>> Sent: Wednesday, November 24, 2004 7:50 AM >>>>>>>> To: Alan Clark; avt@ietf.org >>>>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Isnt encryption is to prevent monitoring from the first place? >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: avt-bounces@ietf.org >> [mailto:avt-bounces@ietf.org] On Behalf >>>>>>>> Of >>>>>>>> Alan Clark >>>>>>>> Sent: Tuesday, November 23, 2004 5:42 PM >>>>>>>> To: avt@ietf.org >>>>>>>> Subject: [AVT] RFC 3711 and RTCP >>>>>>>> >>>>>>>> >>>>>>>>> From the flurry of discussion on RFC3711 it looks as >> if there is >>>>>>>> considerable interest in SRTP implementation. I'd >> like to add a >>>>>>>> request >>>>>>>> to >>>>>>>> SRTP implementors with regard to manageability. >>>>>>>> >>>>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>>>> block) >>>>>>>> contain useful information for network monitoring, and >> are often >>>>>>>> used by >>>>>>>> probes and analyzers to support problem diagnosis. >> RFC3711 allows >>>>>>>> the >>>>>>>> selective encryption of RTCP payloads and hence I >> would strongly >>>>>>>> recomment >>>>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>>>> payloads >>>>>>>> as >>>>>>>> this >>>>>>>> adversely impacts manageability. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Alan Clark >>>>>>>> Telchemy >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Audio/Video Transport Working Group >>>>>>>> avt@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>>> >>>>>>>> >> ****************************************************************** >>>>>>>> ** >>>>>>>> * >>>>>>>> ****** >>>>>>> * >>>>>>>> ******************************** >>>>>>>> This email and any files transmitted with it are confidential >>>>>>>> material. >>>>>>>> They are intended solely for the use of the designated >> individual >>>>>>>> or >>>>>>>> entity >>>>>>>> to whom they are addressed. >>>>>>>> If the reader of this message is not the intended recipient, >>>>>>>> you are hereby notified that any dissemination,use, >>>>>>>> distribution or copying of this communication is strictly >>>>>>>> prohibited >>>>>>>> and >>>>>>> may >>>>>>>> be unlawful. >>>>>>>> >>>>>>>> If you have received this email in error please notify >>>>>>>> postmaster@audiocodes.com and permanently delete the e-mail and >>>>>>>> files. >>>>>>>> >>>>>>>> >>>>>>>> >> ****************************************************************** >>>>>>>> ** >>>>>>>> * >>>>>>>> ****** >>>>>>> * >>>>>>>> ******************************* >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Audio/Video Transport Working Group >>>>>>>> avt@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Audio/Video Transport Working Group >>>>>>> avt@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>> >>>>>> David R. Oran >>>>>> Cisco Fellow >>>>>> Cisco Systems >>>>>> 7 Ladyslipper Lane >>>>>> Acton, MA 01720 USA >>>>>> Tel: +1 978 264 2048 >>>>>> Email: oran@cisco.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 2 19:17:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18280 for ; Thu, 2 Dec 2004 19:17:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca1ET-0003eP-O1 for mmusic-web-archive@ietf.org; Thu, 02 Dec 2004 19:23:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzv9-00007i-Hn; Thu, 02 Dec 2004 17:59:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZv10-00008T-CH; Thu, 02 Dec 2004 12:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14382; Thu, 2 Dec 2004 12:45:10 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZv6V-0002mA-Vb; Thu, 02 Dec 2004 12:50:58 -0500 Received: from [64.238.103.215] (port=1036 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CZv0u-0003iL-FV; Thu, 02 Dec 2004 12:45:08 -0500 From: "Alan Clark" To: "Romascanu, Dan \(Dan\)" , "Mark Baugher" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Thu, 2 Dec 2004 12:45:07 -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.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 778b456acd32f555185589e04d062871 Content-Transfer-Encoding: 7bit Cc: rmonmib@ietf.org, mmusic@ietf.org, avt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: aec2475b197ed9c8908117d8fbf9ee2e Content-Transfer-Encoding: 7bit Dan I can understand your desire to create a RAQMON-centric reporting system however the industry needs to keep its options open. The RTCP XR based VoIP performance management framework allows metrics to be reported via the media path, signaling protocols or SNMP, and we need to give the implementor as much flexibility as possible. Reporting RTCP XR metrics to a RAQMON collector is one option that should be available however this would not address many practical scenarios. Service providers and network managers make extensive use of probes and analyzers to monitor key demarc points in the network and diagnose problems. Encrypting everything can severely limit the functionality of these mid-network systems and hence make it harder for the network manager to manage the network. If we had to trade the number of circumstances in which knowledge of packet loss/ discard rates etc. were a security concern vs the number of circumstances under which network managers needed improved tools to diagnose problems then I'd be surprised if the former was even a minute fraction of the latter. It is also distinctly possible that if issues such as the duration of a call was of concern then the IP endpoints would probably simply use an encrypted IP tunnel - otherwise a mid-stream observer could examine the RTP stream. Regards Alan -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 02, 2004 6:46 AM To: Alan Clark; Mark Baugher Cc: rmonmib@ietf.org; mmusic@ietf.org; avt@ietf.org Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP I would be cautious in saying that in no circumstances the contents of an XR payload would be remotely useful to an eavesdropper. We may encounter some very security aware environments where even the fact that a call happens between two IP phones, its duration, or QoS parameters need to be kept confidential. For this reason, while working to provide a strong recommendation for RTCP XR packets not to be encrypted, I do not believe that we can make this a MUST requirements. As an alternative, I suggest to use RAQMON extensions to report the RTCP XR metrics to RAQMON collectors without the security risks that may be of concern in some environments. Regards, Dan > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > Sent: 01 December, 2004 2:08 PM > To: Mark Baugher > Cc: mmusic@ietf.org > Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > Mark > > To provide some background to the list - RFC3611 states the > following:- > > "Any encryption or filtering of XR report blocks entails a loss of > monitoring information to third parties. For example, a > network that > establishes a tunnel to encrypt VoIP Report Blocks denies that > information to the service providers traversed by the tunnel. The > service providers cannot then monitor or respond to the quality of > the VoIP calls that they carry, potentially creating > problems for the > network's users. As a default, XR packets should not be > encrypted or > filtered." > > I can't conceive of any circumstance in which the contents of > an XR payload > would be remotely useful to an eavesdropper and hence stating that XR > payloads should always be left unencrypted would be (at least > in my opinion) > ok. If we wanted to make this even more specific we could narrow this > requirement down to only XR VoIP Metrics payloads to avoid > the situation in > which some future XR payload may be problematic. > > The availability of VoIP metrics payloads will be a huge > issue for service > providers - as we move through 2005 RTCP XR will be a mainstay of VoIP > performance management and is already a mandatory requirement > within certain > sectors of the industry. Making the VoIP metrics payload > unencrypted by > default may seem a small issue today however it will have > major consequences > to the industry as SRTP starts to roll out. > > Regards > > Alan > > > > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Tuesday, November 30, 2004 6:45 PM > To: Alan Clark > Cc: mmusic@ietf.org > Subject: Re: [AVT] RFC 3711 and RTCP > > > Alan > I am copying MMUSIC (and not cross-posting to AVT) to > further discuss > a possible change to SDP security descriptions, which has completed WG > last call. The change is needed for RFC 3611, and we also discovered > that > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -07.txt does not address the SRTCP E bit properly. I offered the > following text in a posting to AVT: > "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP > packets MUST have the E bit set to zero and MUST NOT be encrypted. > Otherwise, all SRTP packets MUST have the E bit set to one and MUST be > encrypted by default. Individual applications MAY override these > default behaviors in their specifications. In a session where SRTCP > packets are encrypted, therefore, applications that use RFC 3611 MAY > set the E bit to 0 for XR packets as recommended by RFC 3611." > > One of my co-authors pointed out that the last sentence is > more than an > editorial change. We also don't like the fact that an offerer or > answerer cannot explicitly signal when it wants the XR packet to be > encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the > default setting and RFC 3611 is also signaled, it is ambiguous as to > whether the SRTCP sender will encrypt the XR packet or not. It's > solely up to the sender. If the offerer or answerer want the > XR packet > to always be encrypted, there is no way to signal that. Ditto for the > unencrypted case. > > I think we need to put the first three sentences of the above-quoted > paragraph into SDP security descriptions as an editorial change. I'm > proposing this to the working group. I also propose not to > include the > last sentence. Instead, we could add a new signaling parameter, > UNENCRYPTED_XR, which implies that all SRTCP messages are to be > encrypted except for the XR packets, which will have their E > bit clear, > of course. > > This new parameter could be placed in an RFC 3611bis or in a revision > of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to > undergo another WG last call. What do you (all) think about this? > > Mark > > On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: > > > Alan > > As Dave Oran has pointed out, the definition that you want is not > > supported in the signaling, at present. The current definition of > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > > -07.txt treats SRTCP encryption as either on or off and does not > > address the problem of setting the E bit in SRTCP packets. > This is a > > bug that we need to fix. > > > > MMUSIC has finished last call on > > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have > > reviewed it. We'll be making some changes at Jon Peterson's request > > and post another version in about a week. This is an opportunity to > > address the E bit, but the MMUSIC chairs or transport ADs may want > > another WG last call. Off the top of my head, I would > offer something > > like the following. > > > > "As the default behavior when UNENCRYPTED_SRTCP is > signaled, all SRTCP > > packets MUST have the E bit set to zero and MUST NOT be encrypted. > > Otherwise, all SRTP packets MUST have the E bit set to one > and MUST be > > encrypted by default. Individual applications MAY override these > > default behaviors in their specifications. In a session where SRTCP > > packets are encrypted, therefore, applications that use RFC 3611 MAY > > set the E bit to 0 for XR packets as recommended by RFC 3611." > > > > Mark > > > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: > > > >> > >> > >> Mark > >> > >> We tried to flag this in RFC3611 with the following text in the > >> "security > >> considerations" section > >> > >> Any encryption or filtering of XR report blocks entails > a loss of > >> monitoring information to third parties. For example, a network > >> that > >> establishes a tunnel to encrypt VoIP Report Blocks denies that > >> information to the service providers traversed by the > tunnel. The > >> service providers cannot then monitor or respond to the > quality of > >> the VoIP calls that they carry, potentially creating > problems for > >> the > >> network's users. As a default, XR packets should not > be encrypted > >> or > >> filtered. > >> > >> Could we potentially interpret this as being the > definition of what to > >> selectively encrypt in the case of the RFC3611 specification? > >> > >> Regards > >> > >> Alan > >> > >> > >> -----Original Message----- > >> From: Mark Baugher [mailto:mbaugher@cisco.com] > >> Sent: Wednesday, November 24, 2004 2:42 PM > >> To: Alan Clark > >> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R > Oran; Michael > >> A. > >> Ramalho > >> Subject: Re: [AVT] RFC 3711 and RTCP > >> > >> > >> So, when the sender and receiver agree to encrypt SRTCP, this would > >> mean > >> only that some SRTCP messages would be encrypted and the > sender would > >> decide which ones to encrypt? My personal opinion is that > this is not > >> secure because it is unpredictable to the receiver, which > may have a > >> policy that all messages related to its session be encrypted. > >> > >> I can think of a few potential approaches to this problem. > >> > >> 1. Let individual SRTCP messages or a bundle of SRTCP messages > >> be signaled to be unencrypted when SRTCP encryption is used. > >> > >> 2. Make a blanket policy that the sender determine what > >> to selectively encrypt, as you suggest. > >> > >> 3. Define the policy of what to selectively encrypt in > >> the particular specification. In other words, a document could > >> re-define the signaling of SRTCP encryption according to its > >> needs. The specification of foo, therefore, could define a new > >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of > >> ENCRYPTED_SRTCP. The foo document would define what gets > >> encrypted and what does not get encrypted as per its needs. > >> > >> I commented on #2 already. I don't like #1 because of its > signaling > >> complexity. I like #3 because it limits the complexity to the > >> specific needs of an application. #1 would be more efficient than > >> #3 if lots of applications had their own specific needs for > >> selective encryption of SRTCP message. But I don't think this is > >> the case. > >> > >> Mark > >> > >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: > >> > >>> > >>> If the use of encryption in SRTCP is signalled by an > explicit (E) bit > >>> in the > >>> SRTCP header then perhaps the sender could autonomously decide > >>> whether > >>> it > >>> wants to encrypt? Presumably since the sender is in the best > >>> position > >>> to > >>> decide if the data is sensitive then this would be ok - and the > >>> receiver is > >>> able to just look at the E bit and hence recognize that > decryption is > >>> needed. > >>> > >>> Alan > >>> > >>> -----Original Message----- > >>> From: avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org]On Behalf Of > >>> Mark Baugher > >>> Sent: Wednesday, November 24, 2004 1:33 PM > >>> To: David R Oran > >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; > >>> avt@ietf.org > >>> Subject: Re: [AVT] RFC 3711 and RTCP > >>> > >>> > >>> > >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: > >>> > >>>> > >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: > >>>> > >>>>> > >>>>> Michael > >>>>> > >>>>> I don't see why this would be a problem unless you included SDES > >>>>> and > >>>>> (SR or > >>>>> RR or XR) in the same RTCP packet. SRTP (at least the > protocol) is > >>>>> apparently able to decided on a packet by packet basis > whether to > >>>>> encrypt > >>>>> RTCP - hopefully SRTP implementations also permit this. > >>>>> > >>>> Sure, they can do this. But remember offer-answer. How does a > >>>> receiver > >>>> communicate such a granular policy to the transmitter? > Right now if > >>>> can say whether to auth or auth+encrypt RTP, and auth or > >>>> auth+encrypt > >>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR > >>>> etc. > >>> > >>> Seems to me that this is a problem with SDP security descriptions. > >>> That problem might be there because we forgot about the E > bit. This > >>> seems very messy for the reason you mention above - > granularity. I > >>> don't think that we want to negotiate the encryption > policy for each > >>> type SDP message, which is a problem with something like > the E bit. > >>> > >>> Mark > >>>> > >>>> > >>>>> Logically I'd send SDES on its own at the start of a call to > >>>>> provide > >>>>> some > >>>>> user info, but would not send SR/RR/XR until at least > 8-10 seconds > >>>>> into the > >>>>> call as I need some time to gather statistics to report. > >>>> That's not exactly what the RTP specs say. RTCP timers don't have > >>>> this > >>>> kind of policy today. In fact, there are porposals on > the table to > >>>> use > >>>> RTCP for early feedback to assess reception quality on > some initial > >>>> packets - e.g. the RTP-noop proposal. In any event that has no > >>>> bearing > >>>> on the present discussion. > >>>> > >>>>> After the > >>>>> start-of-call exchange there would appear to be minimal need to > >>>>> include > >>>>> SDES. I'm sure we could construct some scenarios in > which you "may" > >>>>> need to > >>>>> include SDES with SR/RR/XR however the vast majority of > cases would > >>>>> either > >>>>> need only a single initial exchange or may not need SDES at all. > >>>>> > >>>> Any time you change SSRC you potentially need to send SDES. > >>>> That said, I still don't see what bearing this has on > the discussion > >>>> about whether we need the complexity of encrypting some > RTCP packets > >>>> and not others for a single session. > >>>> > >>>> It's a tradeoff between extra complexity+less privacy versus > >>>> allowing > >>>> snoopers to gather RTCP stats. > >>>> > >>>> Dave. > >>>> > >>>>> Regards > >>>>> > >>>>> Alan > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] > >>>>> Sent: Wednesday, November 24, 2004 9:39 AM > >>>>> To: Alan Clark > >>>>> Cc: Oren Peleg; avt@ietf.org > >>>>> Subject: RE: [AVT] RFC 3711 and RTCP > >>>>> > >>>>> > >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: > >>>>>> Hi Oren > >>>>>> > >>>>>> Yes - encryption is intended to provide privacy however this > >>>>>> relates > >>>>>> primarily to the voice payloads and to information within RTCP > >>>>>> that > >>>>>> may be > >>>>>> associated with individual users (e.g. SDES). > >>>>>> > >>>>>> SR, RR and XR contain only peformance statistics and > there is no > >>>>>> privacy > >>>>>> consideration that I can think of related to this type of data. > >>>>>> > >>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but > >>>>>> don't > >>>>> encrypt > >>>>>> RTCP SR/RR/XR > >>>>> > >>>>> Hi Alan, > >>>>> > >>>>> I am wondering about implementations utilizing your advise > >>>>> "optionally > >>>>> encrypt > >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". > >>>>> > >>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not > >>>>> RTCP > >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be > >>>>> highly > >>>>> related to each other. For example (quote out of RFC 3611): > >>>>> > >>>>> "XR packets supplement the existing RTCP packets, and may be > >>>>> stacked > >>>>> with > >>>>> other RTCP packets to form compound RTCP packets [9, > Section 6]." > >>>>> > >>>>> Thus, RFC3611 explicitly admits the possibility of (but does not > >>>>> mandate) > >>>>> the piggybacking all the RTCP-XR block types. > >>>>> > >>>>> RTCP implementations would have to know the SRTP > encryption rules > >>>>> to > >>>>> make sure they don't perform piggybacking with SDES ... > but could > >>>>> allow > >>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR > >>>>> blocks. > >>>>> > >>>>> This RTCP/SRTP interaction/dependency seems to add a > burden to both > >>>>> RTCP and SRTP implementations ... let alone the expressiveness > >>>>> required > >>>>> to signal your advise in existing SDP/SRTP mechanisms. > >>>>> > >>>>> Are you aware of any implementations that have actually followed > >>>>> your > >>>>> advise above? I rather go into this one with our eyes open ... > >>>>> developers > >>>>> highly dislike this cross-functional entity dependency > (RTCP & SRTP > >>>>> along > >>>>> with expressing it in SDP/SRTP mechanisms). > >>>>> > >>>>> Regards, > >>>>> > >>>>> Michael Ramalho > >>>>> > >>>>> > >>>>> > >>>>>> Regards > >>>>>> > >>>>>> Alan > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] > >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM > >>>>>> To: Alan Clark; avt@ietf.org > >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP > >>>>>> > >>>>>> > >>>>>> > >>>>>> Isnt encryption is to prevent monitoring from the first place? > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org] On Behalf > >>>>>> Of > >>>>>> Alan Clark > >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM > >>>>>> To: avt@ietf.org > >>>>>> Subject: [AVT] RFC 3711 and RTCP > >>>>>> > >>>>>> > >>>>>>> From the flurry of discussion on RFC3711 it looks as > if there is > >>>>>> considerable interest in SRTP implementation. I'd > like to add a > >>>>>> request > >>>>>> to > >>>>>> SRTP implementors with regard to manageability. > >>>>>> > >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report > >>>>>> block) > >>>>>> contain useful information for network monitoring, and > are often > >>>>>> used by > >>>>>> probes and analyzers to support problem diagnosis. > RFC3711 allows > >>>>>> the > >>>>>> selective encryption of RTCP payloads and hence I > would strongly > >>>>>> recomment > >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR > >>>>>> payloads > >>>>>> as > >>>>>> this > >>>>>> adversely impacts manageability. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Alan Clark > >>>>>> Telchemy > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Audio/Video Transport Working Group > >>>>>> avt@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>>> > >>>>>> > ****************************************************************** > >>>>>> ** > >>>>>> * > >>>>>> ****** > >>>>> * > >>>>>> ******************************** > >>>>>> This email and any files transmitted with it are confidential > >>>>>> material. > >>>>>> They are intended solely for the use of the designated > individual > >>>>>> or > >>>>>> entity > >>>>>> to whom they are addressed. > >>>>>> If the reader of this message is not the intended recipient, > >>>>>> you are hereby notified that any dissemination,use, > >>>>>> distribution or copying of this communication is strictly > >>>>>> prohibited > >>>>>> and > >>>>> may > >>>>>> be unlawful. > >>>>>> > >>>>>> If you have received this email in error please notify > >>>>>> postmaster@audiocodes.com and permanently delete the e-mail and > >>>>>> files. > >>>>>> > >>>>>> > >>>>>> > ****************************************************************** > >>>>>> ** > >>>>>> * > >>>>>> ****** > >>>>> * > >>>>>> ******************************* > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Audio/Video Transport Working Group > >>>>>> avt@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Audio/Video Transport Working Group > >>>>> avt@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/avt > >>>>> > >>>> David R. Oran > >>>> Cisco Fellow > >>>> Cisco Systems > >>>> 7 Ladyslipper Lane > >>>> Acton, MA 01720 USA > >>>> Tel: +1 978 264 2048 > >>>> Email: oran@cisco.com > >>>> > >>>> > >>>> _______________________________________________ > >>>> Audio/Video Transport Working Group > >>>> avt@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/avt > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Audio/Video Transport Working Group > >>> avt@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/avt > >>> > >> > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 2 21:16:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27488 for ; Thu, 2 Dec 2004 21:16:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca35K-00065B-AM for mmusic-web-archive@ietf.org; Thu, 02 Dec 2004 21:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0Pl-00046J-QT; Thu, 02 Dec 2004 18:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZx7u-0000IR-5F; Thu, 02 Dec 2004 15:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22359; Thu, 2 Dec 2004 15:00:28 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZxDT-0005Ux-Lf; Thu, 02 Dec 2004 15:06:16 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB2JwQZ4007206; Thu, 2 Dec 2004 14:58:26 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB2JukZ4004911; Thu, 2 Dec 2004 14:57:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Thu, 2 Dec 2004 21:56:53 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTYmFkvpFEyWw7kRhOYFl5G8vPeJwAD0i9g From: "Romascanu, Dan \(Dan\)" To: "Alan Clark" , "Mark Baugher" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc Content-Transfer-Encoding: quoted-printable Cc: rmonmib@ietf.org, mmusic@ietf.org, avt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 18100d5cbd6ebe12591b0282c337464d Content-Transfer-Encoding: quoted-printable Alan, I believe that we are not in disagreement from a technical perspective. = I am just suggesting that reporting RTCP XR metrics to a RAQMON = collector be one of the options that should be available=20 This is not about pushing a RAQMON-centric technology to the industry or = closing other options. This is about providing another way of = transporting RTCP XR reports for these situations where the RTCP XR = probes cannot be deployed . As the need for RTCP encryption will not run = away completely, at least in some environments, and even the information = carried by RTCP XR may be considered confidential in some deployments, = RAQMON reports carrying RTCP XR information can provide the missing = functionality.=20 RAQMON Reports will also support the case of the encrypted IP tunnels, = as well as any combination of media and signaling encryption. Regards, Dan > -----Original Message----- > From: Alan Clark [mailto:alan.d.clark@telchemy.com] > Sent: 02 December, 2004 7:45 PM > To: Romascanu, Dan (Dan); Mark Baugher > Cc: rmonmib@ietf.org; mmusic@ietf.org; avt@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > Dan >=20 > I can understand your desire to create a RAQMON-centric=20 > reporting system > however the industry needs to keep its options open. The=20 > RTCP XR based VoIP > performance management framework allows metrics to be=20 > reported via the media > path, signaling protocols or SNMP, and we need to give the=20 > implementor as > much flexibility as possible. Reporting RTCP XR metrics to a RAQMON > collector is one option that should be available however this=20 > would not > address many practical scenarios. >=20 > Service providers and network managers make extensive use of=20 > probes and > analyzers to monitor key demarc points in the network and=20 > diagnose problems. > Encrypting everything can severely limit the functionality of these > mid-network systems and hence make it harder for the network=20 > manager to > manage the network. >=20 > If we had to trade the number of circumstances in which=20 > knowledge of packet > loss/ discard rates etc. were a security concern vs the number of > circumstances under which network managers needed improved=20 > tools to diagnose > problems then I'd be surprised if the former was even a=20 > minute fraction of > the latter. > It is also distinctly possible that if issues such as the=20 > duration of a call > was of concern then the IP endpoints would probably simply=20 > use an encrypted > IP tunnel - otherwise a mid-stream observer could examine the=20 > RTP stream. >=20 > Regards >=20 > Alan >=20 >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of > Romascanu, Dan (Dan) > Sent: Thursday, December 02, 2004 6:46 AM > To: Alan Clark; Mark Baugher > Cc: rmonmib@ietf.org; mmusic@ietf.org; avt@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > I would be cautious in saying that in no circumstances the=20 > contents of an XR > payload would be remotely useful to an eavesdropper. We may=20 > encounter some > very security aware environments where even the fact that a=20 > call happens > between two IP phones, its duration, or QoS parameters need to be kept > confidential. For this reason, while working to provide a strong > recommendation for RTCP XR packets not to be encrypted, I do=20 > not believe > that we can make this a MUST requirements. As an alternative,=20 > I suggest to > use RAQMON extensions to report the RTCP XR metrics to=20 > RAQMON collectors > without the security risks that may be of concern in some=20 > environments. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > > Sent: 01 December, 2004 2:08 PM > > To: Mark Baugher > > Cc: mmusic@ietf.org > > Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > Mark > > > > To provide some background to the list - RFC3611 states the > > following:- > > > > "Any encryption or filtering of XR report blocks entails=20 > a loss of > > monitoring information to third parties. For example, a > > network that > > establishes a tunnel to encrypt VoIP Report Blocks denies that > > information to the service providers traversed by the=20 > tunnel. The > > service providers cannot then monitor or respond to the=20 > quality of > > the VoIP calls that they carry, potentially creating > > problems for the > > network's users. As a default, XR packets should not be > > encrypted or > > filtered." > > > > I can't conceive of any circumstance in which the contents of > > an XR payload > > would be remotely useful to an eavesdropper and hence=20 > stating that XR > > payloads should always be left unencrypted would be (at least > > in my opinion) > > ok. If we wanted to make this even more specific we could=20 > narrow this > > requirement down to only XR VoIP Metrics payloads to avoid > > the situation in > > which some future XR payload may be problematic. > > > > The availability of VoIP metrics payloads will be a huge > > issue for service > > providers - as we move through 2005 RTCP XR will be a=20 > mainstay of VoIP > > performance management and is already a mandatory requirement > > within certain > > sectors of the industry. Making the VoIP metrics payload > > unencrypted by > > default may seem a small issue today however it will have > > major consequences > > to the industry as SRTP starts to roll out. > > > > Regards > > > > Alan > > > > > > > > -----Original Message----- > > From: Mark Baugher [mailto:mbaugher@cisco.com] > > Sent: Tuesday, November 30, 2004 6:45 PM > > To: Alan Clark > > Cc: mmusic@ietf.org > > Subject: Re: [AVT] RFC 3711 and RTCP > > > > > > Alan > > I am copying MMUSIC (and not cross-posting to AVT) to > > further discuss > > a possible change to SDP security descriptions, which has=20 > completed WG > > last call. The change is needed for RFC 3611, and we also=20 > discovered > > that > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > > -07.txt does not address the SRTCP E bit properly. I offered the > > following text in a posting to AVT: > > "As the default behavior when UNENCRYPTED_SRTCP is=20 > signaled, all SRTCP > > packets MUST have the E bit set to zero and MUST NOT be encrypted. > > Otherwise, all SRTP packets MUST have the E bit set to one=20 > and MUST be > > encrypted by default. Individual applications MAY override these > > default behaviors in their specifications. In a session where SRTCP > > packets are encrypted, therefore, applications that use RFC 3611 MAY > > set the E bit to 0 for XR packets as recommended by RFC 3611." > > > > One of my co-authors pointed out that the last sentence is > > more than an > > editorial change. We also don't like the fact that an offerer or > > answerer cannot explicitly signal when it wants the XR packet to be > > encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the > > default setting and RFC 3611 is also signaled, it is ambiguous as to > > whether the SRTCP sender will encrypt the XR packet or not. It's > > solely up to the sender. If the offerer or answerer want the > > XR packet > > to always be encrypted, there is no way to signal that. =20 > Ditto for the > > unencrypted case. > > > > I think we need to put the first three sentences of the above-quoted > > paragraph into SDP security descriptions as an editorial=20 > change. I'm > > proposing this to the working group. I also propose not to > > include the > > last sentence. Instead, we could add a new signaling parameter, > > UNENCRYPTED_XR, which implies that all SRTCP messages are to be > > encrypted except for the XR packets, which will have their E > > bit clear, > > of course. > > > > This new parameter could be placed in an RFC 3611bis or in=20 > a revision > > of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to > > undergo another WG last call. What do you (all) think about this? > > > > Mark > > > > On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: > > > > > Alan > > > As Dave Oran has pointed out, the definition that you=20 > want is not > > > supported in the signaling, at present. The current definition of > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > > > -07.txt treats SRTCP encryption as either on or off and does not > > > address the problem of setting the E bit in SRTCP packets. > > This is a > > > bug that we need to fix. > > > > > > MMUSIC has finished last call on > > > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have > > > reviewed it. We'll be making some changes at Jon=20 > Peterson's request > > > and post another version in about a week. This is an=20 > opportunity to > > > address the E bit, but the MMUSIC chairs or transport ADs may want > > > another WG last call. Off the top of my head, I would > > offer something > > > like the following. > > > > > > "As the default behavior when UNENCRYPTED_SRTCP is > > signaled, all SRTCP > > > packets MUST have the E bit set to zero and MUST NOT be encrypted. > > > Otherwise, all SRTP packets MUST have the E bit set to one > > and MUST be > > > encrypted by default. Individual applications MAY override these > > > default behaviors in their specifications. In a session=20 > where SRTCP > > > packets are encrypted, therefore, applications that use=20 > RFC 3611 MAY > > > set the E bit to 0 for XR packets as recommended by RFC 3611." > > > > > > Mark > > > > > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: > > > > > >> > > >> > > >> Mark > > >> > > >> We tried to flag this in RFC3611 with the following text in the > > >> "security > > >> considerations" section > > >> > > >> Any encryption or filtering of XR report blocks entails > > a loss of > > >> monitoring information to third parties. For=20 > example, a network > > >> that > > >> establishes a tunnel to encrypt VoIP Report Blocks denies that > > >> information to the service providers traversed by the > > tunnel. The > > >> service providers cannot then monitor or respond to the > > quality of > > >> the VoIP calls that they carry, potentially creating > > problems for > > >> the > > >> network's users. As a default, XR packets should not > > be encrypted > > >> or > > >> filtered. > > >> > > >> Could we potentially interpret this as being the > > definition of what to > > >> selectively encrypt in the case of the RFC3611 specification? > > >> > > >> Regards > > >> > > >> Alan > > >> > > >> > > >> -----Original Message----- > > >> From: Mark Baugher [mailto:mbaugher@cisco.com] > > >> Sent: Wednesday, November 24, 2004 2:42 PM > > >> To: Alan Clark > > >> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R > > Oran; Michael > > >> A. > > >> Ramalho > > >> Subject: Re: [AVT] RFC 3711 and RTCP > > >> > > >> > > >> So, when the sender and receiver agree to encrypt SRTCP,=20 > this would > > >> mean > > >> only that some SRTCP messages would be encrypted and the > > sender would > > >> decide which ones to encrypt? My personal opinion is that > > this is not > > >> secure because it is unpredictable to the receiver, which > > may have a > > >> policy that all messages related to its session be encrypted. > > >> > > >> I can think of a few potential approaches to this problem. > > >> > > >> 1. Let individual SRTCP messages or a bundle of SRTCP messages > > >> be signaled to be unencrypted when SRTCP encryption is used. > > >> > > >> 2. Make a blanket policy that the sender determine what > > >> to selectively encrypt, as you suggest. > > >> > > >> 3. Define the policy of what to selectively encrypt in > > >> the particular specification. In other words, a document could > > >> re-define the signaling of SRTCP encryption according to its > > >> needs. The specification of foo, therefore, could define a new > > >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of > > >> ENCRYPTED_SRTCP. The foo document would define what gets > > >> encrypted and what does not get encrypted as per its needs. > > >> > > >> I commented on #2 already. I don't like #1 because of its > > signaling > > >> complexity. I like #3 because it limits the complexity to the > > >> specific needs of an application. #1 would be more=20 > efficient than > > >> #3 if lots of applications had their own specific needs for > > >> selective encryption of SRTCP message. But I don't think this is > > >> the case. > > >> > > >> Mark > > >> > > >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: > > >> > > >>> > > >>> If the use of encryption in SRTCP is signalled by an > > explicit (E) bit > > >>> in the > > >>> SRTCP header then perhaps the sender could autonomously decide > > >>> whether > > >>> it > > >>> wants to encrypt? Presumably since the sender is in the best > > >>> position > > >>> to > > >>> decide if the data is sensitive then this would be ok - and the > > >>> receiver is > > >>> able to just look at the E bit and hence recognize that > > decryption is > > >>> needed. > > >>> > > >>> Alan > > >>> > > >>> -----Original Message----- > > >>> From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org]On Behalf Of > > >>> Mark Baugher > > >>> Sent: Wednesday, November 24, 2004 1:33 PM > > >>> To: David R Oran > > >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; > > >>> avt@ietf.org > > >>> Subject: Re: [AVT] RFC 3711 and RTCP > > >>> > > >>> > > >>> > > >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: > > >>> > > >>>> > > >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: > > >>>> > > >>>>> > > >>>>> Michael > > >>>>> > > >>>>> I don't see why this would be a problem unless you=20 > included SDES > > >>>>> and > > >>>>> (SR or > > >>>>> RR or XR) in the same RTCP packet. SRTP (at least the > > protocol) is > > >>>>> apparently able to decided on a packet by packet basis > > whether to > > >>>>> encrypt > > >>>>> RTCP - hopefully SRTP implementations also permit this. > > >>>>> > > >>>> Sure, they can do this. But remember offer-answer. How does a > > >>>> receiver > > >>>> communicate such a granular policy to the transmitter? > > Right now if > > >>>> can say whether to auth or auth+encrypt RTP, and auth or > > >>>> auth+encrypt > > >>>> RTCP. There's no way to say auth+encrypt SDES but only=20 > auth SR/XR > > >>>> etc. > > >>> > > >>> Seems to me that this is a problem with SDP security=20 > descriptions. > > >>> That problem might be there because we forgot about the E > > bit. This > > >>> seems very messy for the reason you mention above - > > granularity. I > > >>> don't think that we want to negotiate the encryption > > policy for each > > >>> type SDP message, which is a problem with something like > > the E bit. > > >>> > > >>> Mark > > >>>> > > >>>> > > >>>>> Logically I'd send SDES on its own at the start of a call to > > >>>>> provide > > >>>>> some > > >>>>> user info, but would not send SR/RR/XR until at least > > 8-10 seconds > > >>>>> into the > > >>>>> call as I need some time to gather statistics to report. > > >>>> That's not exactly what the RTP specs say. RTCP timers=20 > don't have > > >>>> this > > >>>> kind of policy today. In fact, there are porposals on > > the table to > > >>>> use > > >>>> RTCP for early feedback to assess reception quality on > > some initial > > >>>> packets - e.g. the RTP-noop proposal. In any event that has no > > >>>> bearing > > >>>> on the present discussion. > > >>>> > > >>>>> After the > > >>>>> start-of-call exchange there would appear to be=20 > minimal need to > > >>>>> include > > >>>>> SDES. I'm sure we could construct some scenarios in > > which you "may" > > >>>>> need to > > >>>>> include SDES with SR/RR/XR however the vast majority of > > cases would > > >>>>> either > > >>>>> need only a single initial exchange or may not need=20 > SDES at all. > > >>>>> > > >>>> Any time you change SSRC you potentially need to send SDES. > > >>>> That said, I still don't see what bearing this has on > > the discussion > > >>>> about whether we need the complexity of encrypting some > > RTCP packets > > >>>> and not others for a single session. > > >>>> > > >>>> It's a tradeoff between extra complexity+less privacy versus > > >>>> allowing > > >>>> snoopers to gather RTCP stats. > > >>>> > > >>>> Dave. > > >>>> > > >>>>> Regards > > >>>>> > > >>>>> Alan > > >>>>> > > >>>>> > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] > > >>>>> Sent: Wednesday, November 24, 2004 9:39 AM > > >>>>> To: Alan Clark > > >>>>> Cc: Oren Peleg; avt@ietf.org > > >>>>> Subject: RE: [AVT] RFC 3711 and RTCP > > >>>>> > > >>>>> > > >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: > > >>>>>> Hi Oren > > >>>>>> > > >>>>>> Yes - encryption is intended to provide privacy however this > > >>>>>> relates > > >>>>>> primarily to the voice payloads and to information=20 > within RTCP > > >>>>>> that > > >>>>>> may be > > >>>>>> associated with individual users (e.g. SDES). > > >>>>>> > > >>>>>> SR, RR and XR contain only peformance statistics and > > there is no > > >>>>>> privacy > > >>>>>> consideration that I can think of related to this=20 > type of data. > > >>>>>> > > >>>>>> The message is - encrypt RTP, optionally encrypt=20 > RTCP SDES but > > >>>>>> don't > > >>>>> encrypt > > >>>>>> RTCP SR/RR/XR > > >>>>> > > >>>>> Hi Alan, > > >>>>> > > >>>>> I am wondering about implementations utilizing your advise > > >>>>> "optionally > > >>>>> encrypt > > >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". > > >>>>> > > >>>>> Is there an easy way to tell SRTP to encrypt RTCP=20 > SDES, but not > > >>>>> RTCP > > >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be > > >>>>> highly > > >>>>> related to each other. For example (quote out of RFC 3611): > > >>>>> > > >>>>> "XR packets supplement the existing RTCP packets, and may be > > >>>>> stacked > > >>>>> with > > >>>>> other RTCP packets to form compound RTCP packets [9, > > Section 6]." > > >>>>> > > >>>>> Thus, RFC3611 explicitly admits the possibility of=20 > (but does not > > >>>>> mandate) > > >>>>> the piggybacking all the RTCP-XR block types. > > >>>>> > > >>>>> RTCP implementations would have to know the SRTP > > encryption rules > > >>>>> to > > >>>>> make sure they don't perform piggybacking with SDES ... > > but could > > >>>>> allow > > >>>>> (the more bandwidth efficient) piggybacking on the=20 > other RTCP-XR > > >>>>> blocks. > > >>>>> > > >>>>> This RTCP/SRTP interaction/dependency seems to add a > > burden to both > > >>>>> RTCP and SRTP implementations ... let alone the expressiveness > > >>>>> required > > >>>>> to signal your advise in existing SDP/SRTP mechanisms. > > >>>>> > > >>>>> Are you aware of any implementations that have=20 > actually followed > > >>>>> your > > >>>>> advise above? I rather go into this one with our eyes open ... > > >>>>> developers > > >>>>> highly dislike this cross-functional entity dependency > > (RTCP & SRTP > > >>>>> along > > >>>>> with expressing it in SDP/SRTP mechanisms). > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Michael Ramalho > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Alan > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] > > >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM > > >>>>>> To: Alan Clark; avt@ietf.org > > >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Isnt encryption is to prevent monitoring from the=20 > first place? > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org] On Behalf > > >>>>>> Of > > >>>>>> Alan Clark > > >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM > > >>>>>> To: avt@ietf.org > > >>>>>> Subject: [AVT] RFC 3711 and RTCP > > >>>>>> > > >>>>>> > > >>>>>>> From the flurry of discussion on RFC3711 it looks as > > if there is > > >>>>>> considerable interest in SRTP implementation. I'd > > like to add a > > >>>>>> request > > >>>>>> to > > >>>>>> SRTP implementors with regard to manageability. > > >>>>>> > > >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP=20 > Metrics report > > >>>>>> block) > > >>>>>> contain useful information for network monitoring, and > > are often > > >>>>>> used by > > >>>>>> probes and analyzers to support problem diagnosis. > > RFC3711 allows > > >>>>>> the > > >>>>>> selective encryption of RTCP payloads and hence I > > would strongly > > >>>>>> recomment > > >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR > > >>>>>> payloads > > >>>>>> as > > >>>>>> this > > >>>>>> adversely impacts manageability. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Alan Clark > > >>>>>> Telchemy > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Audio/Video Transport Working Group > > >>>>>> avt@ietf.org > > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > > >>>>>> > > >>>>>> > > ****************************************************************** > > >>>>>> ** > > >>>>>> * > > >>>>>> ****** > > >>>>> * > > >>>>>> ******************************** > > >>>>>> This email and any files transmitted with it are confidential > > >>>>>> material. > > >>>>>> They are intended solely for the use of the designated > > individual > > >>>>>> or > > >>>>>> entity > > >>>>>> to whom they are addressed. > > >>>>>> If the reader of this message is not the intended recipient, > > >>>>>> you are hereby notified that any dissemination,use, > > >>>>>> distribution or copying of this communication is strictly > > >>>>>> prohibited > > >>>>>> and > > >>>>> may > > >>>>>> be unlawful. > > >>>>>> > > >>>>>> If you have received this email in error please notify > > >>>>>> postmaster@audiocodes.com and permanently delete the=20 > e-mail and > > >>>>>> files. > > >>>>>> > > >>>>>> > > >>>>>> > > ****************************************************************** > > >>>>>> ** > > >>>>>> * > > >>>>>> ****** > > >>>>> * > > >>>>>> ******************************* > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Audio/Video Transport Working Group > > >>>>>> avt@ietf.org > > >>>>>> https://www1.ietf.org/mailman/listinfo/avt > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Audio/Video Transport Working Group > > >>>>> avt@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/avt > > >>>>> > > >>>> David R. Oran > > >>>> Cisco Fellow > > >>>> Cisco Systems > > >>>> 7 Ladyslipper Lane > > >>>> Acton, MA 01720 USA > > >>>> Tel: +1 978 264 2048 > > >>>> Email: oran@cisco.com > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Audio/Video Transport Working Group > > >>>> avt@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/avt > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Audio/Video Transport Working Group > > >>> avt@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/avt > > >>> > > >> > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 3 01:19:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16068 for ; Fri, 3 Dec 2004 01:19:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6sU-00031X-SA for mmusic-web-archive@ietf.org; Fri, 03 Dec 2004 01:25:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3wz-0000W7-0z; Thu, 02 Dec 2004 22:17:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca2JE-0008OZ-My for mmusic@megatron.ietf.org; Thu, 02 Dec 2004 20:32:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24854 for ; Thu, 2 Dec 2004 20:32:31 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca2Or-0005C9-DO for mmusic@ietf.org; Thu, 02 Dec 2004 20:38:22 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Dec 2004 17:37:04 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB31ViSt016669; Thu, 2 Dec 2004 17:31:45 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn1-850.cisco.com [10.21.99.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB31VMmE022531; Thu, 2 Dec 2004 17:31:22 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1E0A18CA-44CB-11D9-8729-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Thu, 2 Dec 2004 17:31:55 -0800 To: Alan Clark , Dan ((Dan)) Romascanu X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102037482.379084"; x:"432200"; a:"rsa-sha1"; b:"nofws:1102"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"hUBoon5Ah3mZnoWdfumBAgHQz0YQK0eTgjxgvkMZhFHPfiAzN1WHpbEMrhSSM" "ZuH83Ucy5SGv0zkHjs9qReocBdXbzmS3Q+3KQSXqMD7A0VoolxqMztf1iTYah" "1jH5QufoCDzcw83sLxJGXCTh3WQpPe+fLp3oGynakW0Eoffko="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Thu, 2 Dec 2004 17:31:55 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Alan, Dan I don't know where the discussion is going. The point of all this is to allow RFC 3611 to use SRTP, which is not of direct interest to rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP security descriptions, which is not of direct interest to AVT. Because RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the clear when other SRTCP messages are encrypted, we have an ambiguity in the signaling. This ambiguity arises because SDP security descriptions doesn't address use of the SRTCP E bit, which XR needs packets need to use. At least two of the authors of SDP security descriptions think that we need to remove the ambiguity. So here are the choices that I see. 1. change RFC 3611 to describe how to do SDP security descriptions signaling 2. change draft-ietf-mmusic-sdescriptions to describe how to use the E bit. I would not be surprised if you favored #2. I like #1. But I am willing to add a new parameter to sdescriptions and then run it through WG last call. I'd like to resolve this and move forward. Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 3 08:16:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01972 for ; Fri, 3 Dec 2004 08:16:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaDNv-0002u9-AI for mmusic-web-archive@ietf.org; Fri, 03 Dec 2004 08:22:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaAfx-0005gS-K9; Fri, 03 Dec 2004 05:28:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca9Jy-0003vJ-G9 for mmusic@megatron.ietf.org; Fri, 03 Dec 2004 04:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13596 for ; Fri, 3 Dec 2004 04:01:45 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca9Pf-0006PT-3R for mmusic@ietf.org; Fri, 03 Dec 2004 04:07:40 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB38r585021553 for ; Fri, 3 Dec 2004 03:53:06 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB38r385021496 for ; Fri, 3 Dec 2004 03:53:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Fri, 3 Dec 2004 11:01:40 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTZABe1KkhkAF5+TQCz8ppXfVum/AAFYWtg From: "Romascanu, Dan \(Dan\)" To: "Mark Baugher" , "Alan Clark" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable I do not really have a strong preference. My inclination is to leave RFC = 3611 as it is and to change draft-ietf-mmusic-sdescriptions to describe = how to use the E bit. It looks like the right place to define SDP = security descriptions, and has chances to run faster through the = process.=20 Regards, Dan > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher > Sent: 03 December, 2004 3:32 AM > To: Alan Clark; Romascanu, Dan (Dan) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > Alan, Dan > I don't know where the discussion is going. The point of=20 > all this is=20 > to allow RFC 3611 to use SRTP, which is not of direct interest to=20 > rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP=20 > security descriptions, which is not of direct interest to=20 > AVT. Because=20 > RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the=20 > clear when=20 > other SRTCP messages are encrypted, we have an ambiguity in the=20 > signaling. This ambiguity arises because SDP security descriptions=20 > doesn't address use of the SRTCP E bit, which XR needs=20 > packets need to=20 > use. At least two of the authors of SDP security descriptions think=20 > that we need to remove the ambiguity. So here are the choices that I=20 > see. >=20 > 1. change RFC 3611 to describe how to do SDP security descriptions=20 > signaling > 2. change draft-ietf-mmusic-sdescriptions to describe how to=20 > use the E=20 > bit. >=20 > I would not be surprised if you favored #2. I like #1. But I am=20 > willing to add a new parameter to sdescriptions and then run=20 > it through=20 > WG last call. I'd like to resolve this and move forward. >=20 > Mark >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 3 12:50:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06802 for ; Fri, 3 Dec 2004 12:50:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaHfS-0003vE-Kb for mmusic-web-archive@ietf.org; Fri, 03 Dec 2004 12:56:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDR0-0001cF-Lp; Fri, 03 Dec 2004 08:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaCKs-0003J4-T0; Fri, 03 Dec 2004 07:14:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27901; Fri, 3 Dec 2004 07:14:52 -0500 (EST) Message-Id: <200412031214.HAA27901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Dec 2004 07:14:52 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-connection-precon-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-mmusic-connection-precon-01.txt Pages : 8 Date : 2004-12-2 This document defines the connection-establishment precondition type for the SIP preconditions framework. Connection-establishment preconditions are met when a transport connection (e.g., a TCP connection) is successfully established between two endpoints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connection-precon-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-connection-precon-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-connection-precon-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: <2004-12-2115444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-connection-precon-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-connection-precon-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-2115444.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Dec 3 15:01:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00151 for ; Fri, 3 Dec 2004 15:01:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJhr-0002lJ-BZ for mmusic-web-archive@ietf.org; Fri, 03 Dec 2004 15:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJDJ-0002VC-Sc; Fri, 03 Dec 2004 14:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaIe6-0000Kk-W6 for mmusic@megatron.ietf.org; Fri, 03 Dec 2004 13:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20770 for ; Fri, 3 Dec 2004 13:59:09 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIjs-0008N0-Ck for mmusic@ietf.org; Fri, 03 Dec 2004 14:05:10 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 03 Dec 2004 11:05:20 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB3IwWIT025843; Fri, 3 Dec 2004 10:58:33 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA24977; Fri, 3 Dec 2004 10:58:34 -0800 (PST) Message-Id: <4.3.2.7.2.20041203120630.0339a960@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Dec 2004 12:58:44 -0600 To: Gonzalo Camarillo From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: mmusic@ietf.org Subject: [MMUSIC] Connection-Precon-01 question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Gonzalo This is a follow up question along the same lines to what I sent on 11/8. I thought the idea of preconditions was that they need to be met prior to session establishment. I believe this is when the precondition state table is identical in both UAs. I do not believe your example in this ID shows this to be true prior to transmitting the 180. Shouldn't your UPDATE message have the a=curr line of: a=curr:conn e2e a=des:conn mandatory e2e sendrecv and not "none" as your examples has (maybe this should be "send" only since A has its radio up at this time)? Further, shouldn't the 200 OK to that UPDATE (or some other message) have the following A lines: a=curr:conn e2e sendrecv a=des:conn mandatory e2e sendrecv as this would show the precondition conn has been met in both directions? My confusion is that your precondition is looking for the conn attribute to meet the current condition of "e2e sendrecv", and your example does not have this prior to showing everything is met and to progress to the 180 (meaning preconditions have been met). All this said, I understand you are changing the state in the A line: a=setup attribute along the way. You just do not seem to be addressing the "a=curr" condition. Or am I missing something here? >X-BrightmailFiltered: true >X-Brightmail-Tracker: AAAAAA== >X-BrightmailFiltered: true >X-Brightmail-Tracker: AAAAAA== >X-Ironport-AV: i="3.87,122,1099296000"; > d="scan'208"; a="30556544:sNHT22722228" >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Fri, 03 Dec 2004 07:14:52 -0500 >Cc: mmusic@ietf.org >Subject: I-D ACTION:draft-ietf-mmusic-connection-precon-01.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-PMX-Version: 4.7.0.111621 >X-from-outside-Cisco: 128.107.234.204 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multiparty Multimedia Session Control >Working Group of the IETF. > > Title : Connection-Establishment Preconditions in the > Session > Initiation Protocol (SIP) > Author(s) : G. Camarillo > Filename : draft-ietf-mmusic-connection-precon-01.txt > Pages : 8 > Date : 2004-12-2 > >This document defines the connection-establishment precondition type > for the SIP preconditions framework. Connection-establishment > preconditions are met when a transport connection (e.g., a TCP > connection) is successfully established between two endpoints. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connection-precon-01.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-mmusic-connection-precon-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-connection-precon-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. >------------------------------------------------------------------------- >CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >------------------------------------------------------------------------- >In order to maintain computing infrastructure integrity, Cisco Systems >Enterprise Messaging Services and InfoSec teams have set a mail policy >disallowing executable attachments in email. > >This message contained an executable attachment type that is prohibited >by this policy. The attachment has been removed from this message and >copied to quarantine by our systems. It will be held in quarantine for >seven days in the event that the content needs to be retrieved. > >Please be aware many viruses attempt to look like legitimate email or >notifications from anti-virus systems. We will clearly mark a seperation >between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > >For further reference information about viruses and email antivirus >efforts within Cisco, please visit: > >http://wwwin.cisco.com/it/ems/services/antiviral > >If your concern isn't addressed by the information in this notification >or the above web page, you may open a support request: > >http://wwwin.cisco.com/support/ > >Select "Messaging", "Email-Related", "Mail Routing" > >Please include in the text of your case the following information: > >* Full headers of the message. Documentation on displaying the full >headers is available at this URL: > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > >* This unique quarantine identifier: iB3HpA0o026059 > >If the matter is urgent, you may follow up by calling one of the below >referenced numbers. Please make every effort to provide the above >requested information via the support web tool prior to calling as it >will greatly aid the resolution of your issue. > >Americas: >1 408 526 8888 > >Asiapac >+61 2 8446 8888 > >EMEA >+31 20 485 4888 > >Japan >+81 3 5549 6888 > >US (Toll Free) >1| 800| 888| 8187| (ext.68888) > >Thank you for your cooperation, > >Enterprise Messaging Services >Cisco Systems, Inc >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 4 14:52:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18891 for ; Sat, 4 Dec 2004 14:52:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cag3M-0007Io-R2 for mmusic-web-archive@ietf.org; Sat, 04 Dec 2004 14:58:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CafwU-0005z5-Nv; Sat, 04 Dec 2004 14:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CafoO-0004Rj-8L for mmusic@megatron.ietf.org; Sat, 04 Dec 2004 14:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18499 for ; Sat, 4 Dec 2004 14:43:18 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CafuK-0007A1-BB for mmusic@ietf.org; Sat, 04 Dec 2004 14:49:32 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Sat, 4 Dec 2004 11:42:39 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Dec 2004 11:42:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Sat, 4 Dec 2004 11:42:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Sat, 4 Dec 2004 11:42:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 4 Dec 2004 11:39:33 -0800 Message-ID: <9ED672B9D1A64C489291BE0FB822217D0851EF54@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: SDP security/privacy concerns (draft-ietf-mmusic-sdp-new-22.txt) thread-index: AcTaOPrQLbBaZIMZTxWq3cPEJSWrRw== From: "Anders Klemets" To: "IETF MMUSIC Working Group" X-OriginalArrivalTime: 04 Dec 2004 19:42:37.0914 (UTC) FILETIME=[68C7EBA0:01C4DA39] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: Colin Perkins Subject: [MMUSIC] SDP security/privacy concerns (draft-ietf-mmusic-sdp-new-22.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1777591403==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e This is a multi-part message in MIME format. --===============1777591403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DA39.68620A3A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DA39.68620A3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks to me like the SDP syntax for "o=3D" is forcing users to = divulge information that could be considered sensitive, or private. According to draft-ietf-mmusic-sdp-new-22.txt, the username field on the "o=3D" line is supposed to reveal the user's login identity. Divulging this information to strangers is not a good security practice. =20 The SDP spec allows the "username" field to be set to "-", but only if the originating host does not support the concept of user IDs. I think the spec should be changed to allow the "username" field to be set to "-" even when the host has a concept of user IDs. =20 Current text: =20 is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user ids. The MUST NOT contain spaces. Proposed new text: =20 is the user's login on the originating host.=20 The may be "-", or a random character string, as long as the tuple of , , , and=20 form a globally unique identifier for the session. The MUST NOT contain spaces. =20 There is a similar problem "unicast-address" parameter on the "o=3D" = line. For security reasons, some people may not want to divulge their IP address or domain name, especially if the host is behind a NAT. I think we can fix it in a similar way. =20 This what the text currently says: =20 is the address of the machine from which the session was created. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully-qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful. My proposal is to keep that text, but add this extra sentence at the end: =20 A randomly generated character string MAY be used as as long as the tuple of , , , and=20 form a globally unique identifier for the session. =20 =20 Comments? =20 Anders =20 ------_=_NextPart_001_01C4DA39.68620A3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It looks to me like the SDP syntax for = “o=3D” is forcing users to divulge information that could be considered sensitive, = or private.

According to draft-ietf-mmusic-sdp-new-22.txt, the = username field on the “o=3D” line is supposed to reveal the = user’s login identity.  Divulging this information to strangers is not a good = security practice.

 

The SDP spec allows the “username” field = to be set to “-“, but only if the originating host does not = support the concept of user IDs.  I think the spec should be changed to allow = the “username” field to be set to “-“ even when the host has a concept of = user IDs.

 

Current text:

 

   <username> is the user's =
login on the originating host, or it is =
"-"
      if the =
originating host does not support the concept of user =
ids.
      The =
<username> MUST NOT contain spaces.


Proposed new text:

 

   <username> is the user's =
login on the originating host. 
      The =
<username> may be "-", or a random character string, as =
long as
      the tuple of =
<username>, <sess-id>, <nettype>, <addrtype> and =

      <unicas=
t-address> form a globally unique identifier for the =
session.
      The =
<username> MUST NOT contain spaces.

 

There is a similar problem = “unicast-address” parameter on the “o=3D” line.  For security reasons, = some people may not want to divulge their IP address or domain name, especially if = the host is behind a NAT.  I think we can fix it in a similar = way.

 

This what the text currently = says:

 

   <unicast-address> is the =
address of the machine from which =
the
      session was =
created.  For an address type of IP4, this is =
either
      the =
fully-qualified domain name of the machine, or =
the
      dotted-decimal =
representation of the IP version 4 address of =
the
      machine.  =
For an address type of IP6, this is either =
the
      =
fully-qualified domain name of the machine, or the =
compressed
      textual =
representation of the IP version 6 address of the =
machine.
      For both IP4 =
and IP6, the fully-qualified domain name is the =
form
      that SHOULD be =
given unless this is unavailable, in which case =
the
      globally =
unique address MAY be substituted.  A local IP =
address
      MUST NOT be =
used in any context where the SDP description =
might
      leave the =
scope in which the address is meaningful.


My proposal is to keep that text, but add this extra sentence at the = end:

 

      A randomly =
generated character string MAY be used as =
<unicast-address>
      as long as the =
tuple of <username>, <sess-id>, <nettype>, =
<addrtype> and 
      <unicas=
t-address> form a globally unique identifier for the =
session.
 

 

Comments?

 

Anders

 

------_=_NextPart_001_01C4DA39.68620A3A-- --===============1777591403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1777591403==-- From mmusic-bounces@ietf.org Sun Dec 5 13:46:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28788 for ; Sun, 5 Dec 2004 13:46:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb1Um-0005I9-7M for mmusic-web-archive@ietf.org; Sun, 05 Dec 2004 13:52:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb1JV-0006l9-QR; Sun, 05 Dec 2004 13:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb1Ch-0005X0-VR for mmusic@megatron.ietf.org; Sun, 05 Dec 2004 13:33:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27833 for ; Sun, 5 Dec 2004 13:33:49 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb1Iu-0004yp-Ei for mmusic@ietf.org; Sun, 05 Dec 2004 13:40:16 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61731 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Cb1C3-0008M2-UT; Sun, 05 Dec 2004 18:33:12 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1A440D10-46EC-11D9-844E-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Sun, 5 Dec 2004 18:33:05 +0000 To: IETF MMUSIC Working Group X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Joerg Ott Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit This is to announce a working group last call on the SDP Media Label draft (draft-ietf-mmusic-sdp-media-label-00.txt). Please send any final comments on this draft to the list by 17th December 2004. If no substantive comments are raised by that time, we will request this document be published as a proposed standard RFC. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 5 14:00:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29492 for ; Sun, 5 Dec 2004 14:00:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb1ig-0005bH-82 for mmusic-web-archive@ietf.org; Sun, 05 Dec 2004 14:06:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb1Xq-0008LQ-0U; Sun, 05 Dec 2004 13:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb1PC-0007Rk-0r for mmusic@megatron.ietf.org; Sun, 05 Dec 2004 13:46:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28864 for ; Sun, 5 Dec 2004 13:46:45 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb1VO-0005IW-Ia for mmusic@ietf.org; Sun, 05 Dec 2004 13:53:11 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61814 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Cb1Og-0001fH-Nv; Sun, 05 Dec 2004 18:46:14 +0000 In-Reply-To: <9ED672B9D1A64C489291BE0FB822217D0851EF54@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <9ED672B9D1A64C489291BE0FB822217D0851EF54@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [MMUSIC] SDP security/privacy concerns (draft-ietf-mmusic-sdp-new-22.txt) Date: Sun, 5 Dec 2004 18:46:09 +0000 To: "Anders Klemets" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: IETF MMUSIC Working Group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Anders, On 4 Dec 2004, at 19:39, Anders Klemets wrote: > It looks to me like the SDP syntax for =93o=3D=94 is forcing users to=20= > divulge information that could be considered sensitive, or private. > > According to draft-ietf-mmusic-sdp-new-22.txt, the username field on=20= > the =93o=3D=94 line is supposed to reveal the user=92s login = identity.=A0=20 > Divulging this information to strangers is not a good security=20 > practice. > > The SDP spec allows the =93username=94 field to be set to =93-=93, but = only if=20 > the originating host does not support the concept of user IDs. =A0I=20 > think the spec should be changed to allow the =93username=94 field to = be=20 > set to =93-=93 even when the host has a concept of user IDs. Seems reasonable to me. ... > There is a similar problem =93unicast-address=94 parameter on the =93o=3D= =94=20 > line. =A0For security reasons, some people may not want to divulge = their=20 > IP address or domain name, especially if the host is behind a NAT.=A0 = I=20 > think we can fix it in a similar way. > > This what the text currently says: > =A0 > =A0=A0 is the address of the machine from which the > =A0=A0=A0=A0=A0 session was created.=A0 For an address type of IP4, = this is either > =A0=A0=A0=A0=A0 the fully-qualified domain name of the machine, or the > =A0=A0=A0=A0=A0 dotted-decimal representation of the IP version 4 = address of the > =A0=A0=A0=A0=A0 machine.=A0 For an address type of IP6, this is either = the > =A0=A0=A0=A0=A0 fully-qualified domain name of the machine, or the = compressed > =A0=A0=A0=A0=A0 textual representation of the IP version 6 address of = the=20 > machine. > =A0=A0=A0=A0=A0 For both IP4 and IP6, the fully-qualified domain name = is the form > =A0=A0=A0=A0=A0 that SHOULD be given unless this is unavailable, in = which case=20 > the > =A0=A0=A0=A0=A0 globally unique address MAY be substituted.=A0 A local = IP address > =A0=A0=A0=A0=A0 MUST NOT be used in any context where the SDP = description might > =A0=A0=A0=A0=A0 leave the scope in which the address is meaningful. > > > My proposal is to keep that text, but add this extra sentence at the=20= > end: > =A0 > =A0=A0=A0=A0=A0 A randomly generated character string MAY be used as=20= > > =A0=A0=A0=A0=A0 as long as the tuple of , , = ,=20 > and > =A0=A0=A0=A0=A0=A0 form a globally unique identifier = for the=20 > session. The must be consistent with the and=20 fields, so I don't think it can be a randomly generated=20 string. I wouldn't object to implementations that use 127.0.0.1 though,=20= provided the username was chosen to ensure uniqueness. Colin= _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 6 08:14:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12072 for ; Mon, 6 Dec 2004 08:14:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbInk-0004n2-L7 for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 08:21:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbIaT-0003vB-NW; Mon, 06 Dec 2004 08:07:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbINg-0008VX-C9 for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 07:54:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09128 for ; Mon, 6 Dec 2004 07:54:19 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbITs-0003qs-Ev for mmusic@ietf.org; Mon, 06 Dec 2004 08:00:55 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB6Cs8R2001709 for ; Mon, 6 Dec 2004 13:54:08 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 13:54:08 +0100 Received: from [147.214.34.68] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.68]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YDRG51X5; Mon, 6 Dec 2004 13:54:08 +0100 Message-ID: <41B45670.5040601@ericsson.com> Date: Mon, 06 Dec 2004 13:54:08 +0100 X-Sybari-Trust: 9c957621 87bd62f0 85070f4c 00000979 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF MMUSIC Working Group Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt References: <1A440D10-46EC-11D9-844E-000A957FC5F2@csperkins.org> In-Reply-To: <1A440D10-46EC-11D9-844E-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2004 12:54:08.0606 (UTC) FILETIME=[ACEBCFE0:01C4DB92] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Hi, I have reviewed the document and have some comments. I am sorry that I have not been active earlier and come this late: 1. Section 4: No ABNF definition of "token". I assume that you use that of SDP. However it needs to be either referenced or explicitly defined. 2. No reference to what BNF you are using. I guess a reference to RFC 2234 is all that is needed. Otherwise, there would however be some uncertainties about spacing. Is any white spaces allowed between "a=label:" and the pointer. In RFC 2234 BNF the syntax would say no. In some other BNF the answer may be yes. 3. Section 5. I am a bit worried about the offer/answer section. It is very unclear on the handling of this attribute. Can we really trust applications to define such behavior? From my work with Offer/Answer I sometimes find it difficult to get the right behavior out of SDP in offer/answer usage. If this behavior is left to the application then there is need for a much more explicit section that explains the different choices. Also I think using application defined behavior will result in quite divergent behavior. 4. Reference [4] is only informative. I do hope this quick comments make people believe they do not need to read the document in the WG last call. Cheers Magnus Colin Perkins wrote: > This is to announce a working group last call on the SDP Media Label > draft (draft-ietf-mmusic-sdp-media-label-00.txt). Please send any final > comments on this draft to the list by 17th December 2004. If no > substantive comments are raised by that time, we will request this > document be published as a proposed standard RFC. > > Colin > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 6 18:38:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08584 for ; Mon, 6 Dec 2004 18:38:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbSXh-0002d3-9M for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 18:45:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbSLF-0006Au-6y; Mon, 06 Dec 2004 18:32:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbSBa-00021l-Bb for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 18:22:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07579 for ; Mon, 6 Dec 2004 18:22:27 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbSHz-0002Jp-JL for mmusic@ietf.org; Mon, 06 Dec 2004 18:29:10 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63997 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CbSAr-0003kq-Kl; Mon, 06 Dec 2004 23:21:45 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9231931A-47DD-11D9-85A4-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Mon, 6 Dec 2004 23:21:35 +0000 To: "Romascanu, Dan \(Dan\)" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Mark Baugher , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit I'd also prefer this change to be made in sdescriptions (which needs another revision to address Jon Peterson's comments anyway, right?) Colin On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote: > I do not really have a strong preference. My inclination is to leave > RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to > describe how to use the E bit. It looks like the right place to define > SDP security descriptions, and has chances to run faster through the > process. > > Regards, > > Dan > > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher >> Sent: 03 December, 2004 3:32 AM >> To: Alan Clark; Romascanu, Dan (Dan) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >> >> >> Alan, Dan >> I don't know where the discussion is going. The point of >> all this is >> to allow RFC 3611 to use SRTP, which is not of direct interest to >> rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP >> security descriptions, which is not of direct interest to >> AVT. Because >> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the >> clear when >> other SRTCP messages are encrypted, we have an ambiguity in the >> signaling. This ambiguity arises because SDP security descriptions >> doesn't address use of the SRTCP E bit, which XR needs >> packets need to >> use. At least two of the authors of SDP security descriptions think >> that we need to remove the ambiguity. So here are the choices that I >> see. >> >> 1. change RFC 3611 to describe how to do SDP security descriptions >> signaling >> 2. change draft-ietf-mmusic-sdescriptions to describe how to >> use the E >> bit. >> >> I would not be surprised if you favored #2. I like #1. But I am >> willing to add a new parameter to sdescriptions and then run >> it through >> WG last call. I'd like to resolve this and move forward. >> >> Mark >> >> >> _______________________________________________ >> 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-bounces@ietf.org Mon Dec 6 18:44:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08867 for ; Mon, 6 Dec 2004 18:44:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbSdp-0002jR-GR for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 18:51:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbSTc-0008Dn-JU; Mon, 06 Dec 2004 18:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbSLz-0006GF-Sw for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 18:33:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08388 for ; Mon, 6 Dec 2004 18:33:12 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbSSR-0002YA-Px for mmusic@ietf.org; Mon, 06 Dec 2004 18:39:56 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Dec 2004 15:38:32 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB6NWXIT004498; Mon, 6 Dec 2004 15:32:33 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn1-1002.cisco.com [10.21.99.234]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB6NVhrN016837; Mon, 6 Dec 2004 15:31:43 -0800 In-Reply-To: <9231931A-47DD-11D9-85A4-000A957FC5F2@csperkins.org> References: <9231931A-47DD-11D9-85A4-000A957FC5F2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Mon, 6 Dec 2004 15:32:28 -0800 To: Colin Perkins X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102375903.383617"; x:"432200"; a:"rsa-sha1"; b:"nofws:3031"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KYPi2hzkwbH1ZM9bYbrHUk+pkgCBnVGSjCBzxHVqnQzzj73/gL6z9uAIE8oUC" "CeZMQq2gWSvODN12nsS+WK4QieAycUbr7T2FfcK+UYBStkiHLgnO7azmQIY3t" "iDdCSvTb+/2haWO4rh1kDjkyJruMSriVy7iyr+J6ew6Wmx8JY="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Mon, 6 Dec 2004 15:32:28 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Yes it does. There are two possible approaches. We have an existing parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is encrypted but the XR packets are to be left in the clear (and signaled using the E bit). That's my current default if no one speaks up with an alternative preference. I'd like to resolve this issue by around the middle of the week and generate a new version of sdescriptions. Mark On Dec 6, 2004, at 3:21 PM, Colin Perkins wrote: > I'd also prefer this change to be made in sdescriptions (which needs > another revision to address Jon Peterson's comments anyway, right?) > > Colin > > > > On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote: >> I do not really have a strong preference. My inclination is to leave >> RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to >> describe how to use the E bit. It looks like the right place to >> define SDP security descriptions, and has chances to run faster >> through the process. >> >> Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher >>> Sent: 03 December, 2004 3:32 AM >>> To: Alan Clark; Romascanu, Dan (Dan) >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>> >>> >>> Alan, Dan >>> I don't know where the discussion is going. The point of >>> all this is >>> to allow RFC 3611 to use SRTP, which is not of direct interest to >>> rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP >>> security descriptions, which is not of direct interest to >>> AVT. Because >>> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the >>> clear when >>> other SRTCP messages are encrypted, we have an ambiguity in the >>> signaling. This ambiguity arises because SDP security descriptions >>> doesn't address use of the SRTCP E bit, which XR needs >>> packets need to >>> use. At least two of the authors of SDP security descriptions think >>> that we need to remove the ambiguity. So here are the choices that I >>> see. >>> >>> 1. change RFC 3611 to describe how to do SDP security descriptions >>> signaling >>> 2. change draft-ietf-mmusic-sdescriptions to describe how to >>> use the E >>> bit. >>> >>> I would not be surprised if you favored #2. I like #1. But I am >>> willing to add a new parameter to sdescriptions and then run >>> it through >>> WG last call. I'd like to resolve this and move forward. >>> >>> Mark >>> >>> >>> _______________________________________________ >>> 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-bounces@ietf.org Mon Dec 6 19:32:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11286 for ; Mon, 6 Dec 2004 19:32:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbTNo-0003Y5-KN for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 19:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbTEU-0008Cd-8b; Mon, 06 Dec 2004 19:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbTCW-0007jq-Pl for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 19:27:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10972 for ; Mon, 6 Dec 2004 19:27:26 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbTIw-0003Rm-HU for mmusic@ietf.org; Mon, 06 Dec 2004 19:34:10 -0500 Received: from [64.238.103.215] (port=2736 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CbTCQ-0001b1-GR; Mon, 06 Dec 2004 19:27:26 -0500 From: "Alan Clark" To: "Mark Baugher" , "Colin Perkins" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Mon, 6 Dec 2004 19:27:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Mark I support your UNENCRYPTED_SRTCP_XR solution, and thanks for resolving the issue. Regards Alan Clark -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Monday, December 06, 2004 6:32 PM To: Colin Perkins Cc: Romascanu, Dan (Dan); mmusic@ietf.org; Alan Clark Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Yes it does. There are two possible approaches. We have an existing parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is encrypted but the XR packets are to be left in the clear (and signaled using the E bit). That's my current default if no one speaks up with an alternative preference. I'd like to resolve this issue by around the middle of the week and generate a new version of sdescriptions. Mark On Dec 6, 2004, at 3:21 PM, Colin Perkins wrote: > I'd also prefer this change to be made in sdescriptions (which needs > another revision to address Jon Peterson's comments anyway, right?) > > Colin > > > > On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote: >> I do not really have a strong preference. My inclination is to leave >> RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to >> describe how to use the E bit. It looks like the right place to >> define SDP security descriptions, and has chances to run faster >> through the process. >> >> Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher >>> Sent: 03 December, 2004 3:32 AM >>> To: Alan Clark; Romascanu, Dan (Dan) >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>> >>> >>> Alan, Dan >>> I don't know where the discussion is going. The point of >>> all this is >>> to allow RFC 3611 to use SRTP, which is not of direct interest to >>> rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP >>> security descriptions, which is not of direct interest to >>> AVT. Because >>> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the >>> clear when >>> other SRTCP messages are encrypted, we have an ambiguity in the >>> signaling. This ambiguity arises because SDP security descriptions >>> doesn't address use of the SRTCP E bit, which XR needs >>> packets need to >>> use. At least two of the authors of SDP security descriptions think >>> that we need to remove the ambiguity. So here are the choices that I >>> see. >>> >>> 1. change RFC 3611 to describe how to do SDP security descriptions >>> signaling >>> 2. change draft-ietf-mmusic-sdescriptions to describe how to >>> use the E >>> bit. >>> >>> I would not be surprised if you favored #2. I like #1. But I am >>> willing to add a new parameter to sdescriptions and then run >>> it through >>> WG last call. I'd like to resolve this and move forward. >>> >>> Mark >>> >>> >>> _______________________________________________ >>> 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-bounces@ietf.org Mon Dec 6 21:13:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19320 for ; Mon, 6 Dec 2004 21:13:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbUxD-0005se-4z for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 21:19:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbUoE-00024i-NK; Mon, 06 Dec 2004 21:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbUl7-0001O5-Iv for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 21:07:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18754 for ; Mon, 6 Dec 2004 21:07:19 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbUra-0005k9-QF for mmusic@ietf.org; Mon, 06 Dec 2004 21:14:03 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iB726d728965; Mon, 6 Dec 2004 21:06:40 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Dec 2004 21:06:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0122F1D8@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'mmusic@ietf.org'" Date: Mon, 6 Dec 2004 21:06:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: "'elisabetta.carrara@ericasson.com'" , "'Mats.naslund@ericsson.com'" , "'jari.arkko@ericsson.com'" , "'Karl.norrmann@ericsson.com'" Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0719611353==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 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. --===============0719611353== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC01.5F42123B" 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_01C4DC01.5F42123B Content-Type: text/plain Hi, I have a 2 comments on http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.txt. This first comment is for a clarification: - Section 3.1.2 explains that SIP 488 is used for rejecting a key management offer. 488 allows for the inclusion of an SDP indicating the capabilities of the answerer (the same way an SDP in a 200 OK sent in an OPTIONS request indicates capabilities). It would be desireable to explain how this works with kmgmt. I assume that this is what is meant by wording saying "Further details about the cause of failure MAY be described in an included message from the key management protocol." Perhaps a wording like the following would help: Further details about the media capabilities of the offerer MAY be in included in 488 according to normal RFC 3261 rules. Further details about the cause of the rejection of the key message itself MAY be described in the key message in the SDP in the 488, according to the rules of the key management protocol. The session is then ... ...or something along those lines. It would also be worthwile to describe how this relates to MIKEY in particular (i.e, that the MIKEY message itself in the key-mgmt may have the key management rejection reason). It would also be helpful to have an Example of a failure case for SIP 488/MIKEY. ----------------------- This next comment is concerning a potential issue with SIP forking. I'm not sure we can fix it in MMUSIC, but I'll state it anyways. - There is a somewhat unpleasant side-effect of using a SIP failure response for rejecting a key management message. - Suppose that there is a SIP forking proxy forking the offer (in the INVITE). Let's say the call is forked to A and B. A is a device for which no user is present at the time (say, an office phone). Suppose A rejects the call with 401 Unauthorized because it needs authorization. Suppose the user is at home (B), but rejects the offer with 488 (because it's using the key management protocol used for the corporation which is different than the one used at home). The forking proxy will see both the 401 an the 488, but can only forward one to the offerer. There is nothing saying which one should be forwarded beyong the error response that indicates that there could be retransmission (which applies to both codes in this case). Worst, in this particular example, if the proxy follows the rule section 6/RFC 3261, chances are it will pick 401. This means that you won't be able to call home because you'll never receive a 488. - This is a weakness of the forking procedures in SIP, and perhaps it should be addresses in the SIP working group. - The other alternative would be to not consider the rejection of the key as a rejection of the offer. Instead of sending a 488, you would accept the offer with an answer, and the key rejection would be included in the key message itself (which could then trigger another offer/answer). In other words, the offer/answer is sucessful, but the key exchanged is not. This would have the obvious advantage of the previous scenario working properly. However, if there is no suitable key management protocol, we could run into the reverse problem (when the user is at work (A) instead of (B). In this case, the proxy would forward the 200 with the answer with the key message, and drop the 401. There would be another offer/answer round which would then fail. The caller in this case would never get the 401. I'm not sure how to deal with this forking issue. ------_=_NextPart_001_01C4DC01.5F42123B Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-mmusic-kmgmt-ext-12.txt

Hi,

I have a 2 comments on
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-= kmgmt-ext-12.txt.


This first comment is for a clarification:

- Section 3.1.2 explains that SIP 488 is used for = rejecting a key management offer.
  488 allows for the inclusion of an SDP = indicating the capabilities of the
  answerer (the same way an SDP in a 200 OK = sent in an OPTIONS request indicates
  capabilities). It would be desireable to = explain how this works with
  kmgmt. I assume that this is what is meant by = wording saying "Further details
  about the cause of failure MAY be described = in an included message from the key
  management protocol." Perhaps a wording = like the following would help:

        Further = details about the media capabilities of the offerer MAY be in
        included = in 488 according to normal RFC 3261 rules. Further details about
        the cause = of the rejection of the key message itself MAY be described in
      the key message in = the SDP in the 488, according to the rules
        of the = key management protocol. The session is then ...

 ...or something along those lines.

 It would also be worthwile to describe how this = relates to MIKEY in
 particular (i.e, that the MIKEY message itself = in the key-mgmt may have
 the key management rejection reason). It would = also be helpful to have
 an Example of a failure case for SIP = 488/MIKEY.
 
-----------------------

This next comment is concerning a potential issue = with SIP forking. I'm
not sure we can fix it in MMUSIC, but I'll state it = anyways.

- There is a somewhat unpleasant side-effect of using = a SIP failure response
  for rejecting a key management = message.

- Suppose that there is a SIP forking proxy forking = the offer (in the INVITE).
  Let's say the call is forked to A and B. A is = a device for which no
  user is present at the time (say, an office = phone). Suppose A rejects the
  call with 401 Unauthorized because it needs = authorization. Suppose the user
  is at home (B), but rejects the offer with = 488 (because it's using the key
  management protocol used for the corporation = which is different than the one
  used at home). The forking proxy will see = both the 401 an the 488, but can only
  forward one to the offerer. There is nothing = saying which one should be forwarded
  beyong the error response that indicates that = there could be retransmission (which
  applies to both codes in this case). Worst, = in this particular example, if the proxy
  follows the rule section 6/RFC 3261, chances = are it will pick 401. This means
  that you won't be able to call home because = you'll never receive a 488.

- This is a weakness of the forking procedures in = SIP, and perhaps it should be
  addresses in the SIP working group.

- The other alternative would be to not consider the = rejection of the key as a
  rejection of the offer. Instead of sending a = 488, you would accept the
  offer with an answer, and the key rejection = would be included in the key message
  itself (which could then trigger another = offer/answer). In other words, the
  offer/answer is sucessful, but the key = exchanged is not. This would have the obvious
  advantage of the previous scenario working = properly. However, if there is no
  suitable key management protocol, we could = run into the reverse problem (when the
  user is at work (A) instead of (B). In this = case, the proxy would forward the
  200 with the answer with the key message, and = drop the 401. There would be another
  offer/answer round which would then fail. The = caller in this case would never get
  the 401.

I'm not sure how to deal with this forking = issue.

------_=_NextPart_001_01C4DC01.5F42123B-- --===============0719611353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0719611353==-- From mmusic-bounces@ietf.org Mon Dec 6 21:44:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21114 for ; Mon, 6 Dec 2004 21:44:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbVRz-0006V2-0f for mmusic-web-archive@ietf.org; Mon, 06 Dec 2004 21:51:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbVKP-0007es-RL; Mon, 06 Dec 2004 21:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbVG2-0006jp-EZ for mmusic@megatron.ietf.org; Mon, 06 Dec 2004 21:39:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20742 for ; Mon, 6 Dec 2004 21:39:16 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbVMW-0006Nj-2Z for mmusic@ietf.org; Mon, 06 Dec 2004 21:46:00 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2004 21:48:12 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.1.101] (rtp-vpn1-365.cisco.com [10.82.225.109]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB72ceqR013504; Mon, 6 Dec 2004 21:38:41 -0500 (EST) Message-ID: <41B517B0.4050104@cisco.com> Date: Mon, 06 Dec 2004 21:38:40 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP References: <9231931A-47DD-11D9-85A4-000A957FC5F2@csperkins.org> <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> In-Reply-To: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , Colin Perkins , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit There are two issues here: 1. Relationship between the SRTCP E flag and the UNENCRYPTED_SRTCP sdescriptions parameter. 2. The ability to selectively encrypt parts of your SRTCP. On the first issue, I agree the sdescriptions need to be clarified. On the second issue, I understand, from a pragmatic point of view, the desire to leave RTCP XR in the clear, but I have some general concerns with the idea of specifying a security negotiation protocol that leaves certain information in the clear for the sole purpose of having intermediaries snoop on it. Considering that we have already been through WG last call and AD review of sdescriptions, I would like to hear from both the WG chairs and the ADs, that they consider such a mechanism reasonable before we proceed here. Assuming that to be the case, we need to note that sdescriptions makes a distinction between negotiated and declarative session parameters (see Section 3.4). Is the suggestion here to make this new parameter negotiated (i.e. both sides have to agree on it, and it applies in both directions), or declarative (each side merely indicates what he will do with packets sent by him) ? Since UNENCRYPTED_SRTCP is a negotiated parameter, I assume UNENCRYPTED_SRTCP_XR would also be negotiated. Similarly, given the name of the parameter, I assume absence of it means that all of SRTCP will be encrypted (unless signaled otherwise). If so, this means that we will only leave SRTCP_XR in the clear if both sides explicitly negotiate support for that, which sounds like a reasonable suggestion to me. -- Flemming Mark Baugher wrote: > Yes it does. There are two possible approaches. We have an existing > parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the > SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR > packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is > encrypted but the XR packets are to be left in the clear (and signaled > using the E bit). That's my current default if no one speaks up with > an alternative preference. > > I'd like to resolve this issue by around the middle of the week and > generate a new version of sdescriptions. > > Mark > On Dec 6, 2004, at 3:21 PM, Colin Perkins wrote: > >> I'd also prefer this change to be made in sdescriptions (which needs >> another revision to address Jon Peterson's comments anyway, right?) >> >> Colin >> >> >> >> On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote: >> >>> I do not really have a strong preference. My inclination is to leave >>> RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to >>> describe how to use the E bit. It looks like the right place to >>> define SDP security descriptions, and has chances to run faster >>> through the process. >>> >>> Regards, >>> >>> Dan >>> >>> >>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org >>>> [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher >>>> Sent: 03 December, 2004 3:32 AM >>>> To: Alan Clark; Romascanu, Dan (Dan) >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>>> >>>> >>>> Alan, Dan >>>> I don't know where the discussion is going. The point of >>>> all this is >>>> to allow RFC 3611 to use SRTP, which is not of direct interest to >>>> rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP >>>> security descriptions, which is not of direct interest to >>>> AVT. Because >>>> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the >>>> clear when >>>> other SRTCP messages are encrypted, we have an ambiguity in the >>>> signaling. This ambiguity arises because SDP security descriptions >>>> doesn't address use of the SRTCP E bit, which XR needs >>>> packets need to >>>> use. At least two of the authors of SDP security descriptions think >>>> that we need to remove the ambiguity. So here are the choices that I >>>> see. >>>> >>>> 1. change RFC 3611 to describe how to do SDP security descriptions >>>> signaling >>>> 2. change draft-ietf-mmusic-sdescriptions to describe how to >>>> use the E >>>> bit. >>>> >>>> I would not be surprised if you favored #2. I like #1. But I am >>>> willing to add a new parameter to sdescriptions and then run >>>> it through >>>> WG last call. I'd like to resolve this and move forward. >>>> >>>> Mark >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 07:09:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17669 for ; Tue, 7 Dec 2004 07:09:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbeGe-00011E-Kh for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 07:16:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbe8j-0006Wv-Im; Tue, 07 Dec 2004 07:08:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbe4s-00061f-PH for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 07:04:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17246 for ; Tue, 7 Dec 2004 07:04:20 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbeBQ-0000uM-9p for mmusic@ietf.org; Tue, 07 Dec 2004 07:11:09 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB7C4Jh5002391 for ; Tue, 7 Dec 2004 13:04:20 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 13:04:19 +0100 Received: from [147.214.34.68] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.68]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YLNKMBLC; Tue, 7 Dec 2004 13:04:19 +0100 Message-ID: <41B59C43.4020401@ericsson.com> Date: Tue, 07 Dec 2004 13:04:19 +0100 X-Sybari-Trust: 83a66355 96d33411 0d3e0a2e 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> In-Reply-To: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2004 12:04:19.0768 (UTC) FILETIME=[E1D91380:01C4DC54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi Mark, Mark Baugher wrote: > Yes it does. There are two possible approaches. We have an existing > parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the > SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR > packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is > encrypted but the XR packets are to be left in the clear (and signaled > using the E bit). That's my current default if no one speaks up with > an alternative preference. > I think one should consider that there actually may be need to negotiate what should be left unencrypted, or the other way around. Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" and then another negotiated attribute listing the RTCP packet types that should be protected or the other way around. One can also consider if the normal case is based on senders local policy. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 10:22:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12866 for ; Tue, 7 Dec 2004 10:22:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhH8-0006M7-Fm for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 10:29:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbh24-0002EA-GH; Tue, 07 Dec 2004 10:13:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbgvW-0000YX-7w for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 10:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10748 for ; Tue, 7 Dec 2004 10:06:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbh26-0005xZ-Ad for mmusic@ietf.org; Tue, 07 Dec 2004 10:13:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2004 07:06:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB7F6FIT017150; Tue, 7 Dec 2004 07:06:15 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn1-736.cisco.com [10.21.98.224]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB7F5SGM021155; Tue, 7 Dec 2004 07:05:28 -0800 In-Reply-To: <41B517B0.4050104@cisco.com> References: <9231931A-47DD-11D9-85A4-000A957FC5F2@csperkins.org> <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B517B0.4050104@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B16743B-4861-11D9-BD9F-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 7 Dec 2004 07:06:16 -0800 To: Flemming Andreasen X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102431928.337547"; x:"432200"; a:"rsa-sha1"; b:"nofws:5426"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"qS1jgRTsIG6JI/TK4mXSX0svGuDHoq/ZS80Q3AYjjM1+rUU5OsFYQiW5CmQAk" "ku0YqMGamqB/sL0QvLIfmonW/pB9eRHBke0r6T73PJ+ZhUEHzafLszQTKk+qx" "i1254zP0HEpqlbn9HEEf+DLckXozPpJsEWXzw/h8O1eSGA+4Q="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Tue, 7 Dec 2004 07:06:16 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit On Dec 6, 2004, at 6:38 PM, Flemming Andreasen wrote: > There are two issues here: > 1. Relationship between the SRTCP E flag and the UNENCRYPTED_SRTCP > sdescriptions parameter. > 2. The ability to selectively encrypt parts of your SRTCP. > > On the first issue, I agree the sdescriptions need to be clarified. > > On the second issue, I understand, from a pragmatic point of view, the > desire to leave RTCP XR in the clear, but I have some general concerns > with the idea of specifying a security negotiation protocol that > leaves certain information in the clear for the sole purpose of having > intermediaries snoop on it. They are free to negotiate whether or not all SRTCP messages are unencrypted so there is no security hole in allowing offerers and answerers to negotiate whether or not to leave one type of SRTCP message in the clear. > Considering that we have already been through WG last call and AD > review of sdescriptions, I would like to hear from both the WG chairs > and the ADs, that they consider such a mechanism reasonable before we > proceed here. > > Assuming that to be the case, we need to note that sdescriptions makes > a distinction between negotiated and declarative session parameters > (see Section 3.4). Is the suggestion here to make this new parameter > negotiated (i.e. both sides have to agree on it, and it applies in > both directions), or declarative (each side merely indicates what he > will do with packets sent by him) ? Since UNENCRYPTED_SRTCP is a > negotiated parameter, I assume UNENCRYPTED_SRTCP_XR would also be > negotiated. Similarly, given the name of the parameter, I assume > absence of it means that all of SRTCP will be encrypted (unless > signaled otherwise). Yes. > If so, this means that we will only leave SRTCP_XR in the clear if > both sides explicitly negotiate support for that, which sounds like a > reasonable suggestion to me. Ok. Mark > -- Flemming > > > Mark Baugher wrote: > >> Yes it does. There are two possible approaches. We have an existing >> parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the >> SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR >> packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is >> encrypted but the XR packets are to be left in the clear (and >> signaled using the E bit). That's my current default if no one >> speaks up with an alternative preference. >> >> I'd like to resolve this issue by around the middle of the week and >> generate a new version of sdescriptions. >> >> Mark >> On Dec 6, 2004, at 3:21 PM, Colin Perkins wrote: >> >>> I'd also prefer this change to be made in sdescriptions (which needs >>> another revision to address Jon Peterson's comments anyway, right?) >>> >>> Colin >>> >>> >>> >>> On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote: >>> >>>> I do not really have a strong preference. My inclination is to >>>> leave RFC 3611 as it is and to change >>>> draft-ietf-mmusic-sdescriptions to describe how to use the E bit. >>>> It looks like the right place to define SDP security descriptions, >>>> and has chances to run faster through the process. >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org >>>>> [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher >>>>> Sent: 03 December, 2004 3:32 AM >>>>> To: Alan Clark; Romascanu, Dan (Dan) >>>>> Cc: mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>>>> >>>>> >>>>> Alan, Dan >>>>> I don't know where the discussion is going. The point of >>>>> all this is >>>>> to allow RFC 3611 to use SRTP, which is not of direct interest to >>>>> rmonmib. There is a problem signaling SRTP for RFC 3611 using SDP >>>>> security descriptions, which is not of direct interest to >>>>> AVT. Because >>>>> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the >>>>> clear when >>>>> other SRTCP messages are encrypted, we have an ambiguity in the >>>>> signaling. This ambiguity arises because SDP security descriptions >>>>> doesn't address use of the SRTCP E bit, which XR needs >>>>> packets need to >>>>> use. At least two of the authors of SDP security descriptions >>>>> think >>>>> that we need to remove the ambiguity. So here are the choices >>>>> that I >>>>> see. >>>>> >>>>> 1. change RFC 3611 to describe how to do SDP security descriptions >>>>> signaling >>>>> 2. change draft-ietf-mmusic-sdescriptions to describe how to >>>>> use the E >>>>> bit. >>>>> >>>>> I would not be surprised if you favored #2. I like #1. But I am >>>>> willing to add a new parameter to sdescriptions and then run >>>>> it through >>>>> WG last call. I'd like to resolve this and move forward. >>>>> >>>>> Mark >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 10:47:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15590 for ; Tue, 7 Dec 2004 10:47:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbhf2-0006t4-Q9 for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 10:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhMS-0007mb-PV; Tue, 07 Dec 2004 10:34:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhC4-0005IR-Vu for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 10:24:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13013 for ; Tue, 7 Dec 2004 10:23:59 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhId-0006Nr-Il for mmusic@ietf.org; Tue, 07 Dec 2004 10:30:49 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2004 10:23:28 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.1.101] (rtp-vpn1-365.cisco.com [10.82.225.109]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB7FNPA6023126; Tue, 7 Dec 2004 10:23:25 -0500 (EST) Message-ID: <41B5CAED.8000200@cisco.com> Date: Tue, 07 Dec 2004 10:23:25 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> In-Reply-To: <41B59C43.4020401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Mark Baugher , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Magnus Westerlund wrote: > Hi Mark, > > Mark Baugher wrote: > >> Yes it does. There are two possible approaches. We have an existing >> parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the >> SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR >> packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is >> encrypted but the XR packets are to be left in the clear (and signaled >> using the E bit). That's my current default if no one speaks up with >> an alternative preference. >> > > I think one should consider that there actually may be need to > negotiate what should be left unencrypted, or the other way around. > Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" > and then another negotiated attribute listing the RTCP packet types > that should be protected or the other way around. One can also > consider if the normal case is based on senders local policy. > Hmm, I think we are getting on a slippery slope here with an extended scope, which is part of my initial concern with the whole idea of partially encrypted streams for the benefit of intermediate snoopers. What about the RTP stream ? Should we allow different treatment of different RTP packets, e.g. based on payload type, etc. ? Taking a step back, what are the motivations behind all of this added complexity and is this really the right time to expand the scope this way ? -- Flemming > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 12:25:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26728 for ; Tue, 7 Dec 2004 12:25:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbjCh-0000vW-1r for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 12:32:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbira-0005Ux-Rs; Tue, 07 Dec 2004 12:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbiax-0007zA-RT for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 11:53:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23277 for ; Tue, 7 Dec 2004 11:53:45 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbihY-00009k-7x for mmusic@ietf.org; Tue, 07 Dec 2004 12:00:37 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:50314) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CbiaR-0007z2-Ec; Tue, 07 Dec 2004 16:53:15 +0000 In-Reply-To: <41B5CAED.8000200@cisco.com> References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> <41B5CAED.8000200@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77AB3B58-4870-11D9-9AFB-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 7 Dec 2004 16:53:06 +0000 To: Flemming Andreasen X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , Mark Baugher , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On 7 Dec 2004, at 15:23, Flemming Andreasen wrote: > Magnus Westerlund wrote: >> Mark Baugher wrote: >>> Yes it does. There are two possible approaches. We have an existing >>> parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the >>> SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR >>> packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is >>> encrypted but the XR packets are to be left in the clear (and >>> signaled >>> using the E bit). That's my current default if no one speaks up with >>> an alternative preference. >> >> I think one should consider that there actually may be need to >> negotiate what should be left unencrypted, or the other way around. >> Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" >> and then another negotiated attribute listing the RTCP packet types >> that should be protected or the other way around. One can also >> consider if the normal case is based on senders local policy. >> > Hmm, I think we are getting on a slippery slope here with an extended > scope, which is part of my initial concern with the whole idea of > partially encrypted streams for the benefit of intermediate snoopers. > What about the RTP stream ? Should we allow different treatment of > different RTP packets, e.g. based on payload type, etc. ? Taking a > step back, what are the motivations behind all of this added > complexity and is this really the right time to expand the scope this > way ? All good points. How difficult would it be to write this up as a separate draft? That would allow the "sdescriptions" work to progress quickly, and allow us time to analyse the requirements for partial encryption, write a considered specification of the various parameters, and enumerate the new security considerations that might arise. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 18:57:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16651 for ; Tue, 7 Dec 2004 18:57:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbpJR-0004ss-8Q for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 19:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbowp-00053R-TD; Tue, 07 Dec 2004 18:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbode-0006BF-Pb; Tue, 07 Dec 2004 18:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13861; Tue, 7 Dec 2004 18:20:55 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbokJ-0004Az-6i; Tue, 07 Dec 2004 18:27:51 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB7NKrhB013262 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Dec 2004 17:20:55 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Simple WG , mmusic@ietf.org From: Ben Campbell Date: Tue, 7 Dec 2004 17:20:47 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MSRP: SDP usage concern X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit I sent the attached to the SIMPLE list last week. I am reposting it to both the SIMPLE and MMUSIC lists, as the discussion is of interest to both groups. If you already responded to this on the SIMPLE list or in private, it would be helpful if you can re-post your response to this thread, so everyone sees the whole discussion. Thanks! Ben. ------------------------------------------------------------------------ ---------------------------------------- In the DC meeting, we discussed that MSRP's SDP usage should be reviewed in MMUSIC, or at least by people who are more expert in SDP. Colin Perkins and Joerg Ott looked at this, and suggested a change. (Many thanks to them for taking the time, and I hope they will jump in and correct me if I mischaracterize anything.) The upshot of the proposal is that the fact that MSRP ignores the address in the sdp c-line, and the port and proto fields in the m-line. Instead, MSRP gets all of this from the first URL in the path a-line attribute. This deviates from the traditional usage in SDP, and causes confusion. The proposed change is that the destination URL be broken into the appropriate parts and encoded into the c-line and m-line. For example (leaving out lines that don't change) c=IN IP4 alice.example.com m=message 9 msrp * a=path:msrp://a.example.com:7394/2s93i;tcp would become: c=IN IP4 a.example.com m=message 7394 msrp/tcp * a=session:2s93i The change would only be made for the destination URL. URLs for any relays would be expressed the same way they are now. The advantage of this approach is that it more closely follows the spirit of SDP. This will be easier to understand for people who already know SDP. Existing SDP code could be reused more effectively. The disadvantage of the proposed change is, it means the way an MSRP client determines the destination URL would be different depending on whether the URL represented the final destination or a relay. Instead of the current approach of simply copying the path attribute value into the To-Path header in MSRP messages, a client would copy the path header value if exists, reconstitute the destination URL from the m and c lines, and append the destination URL to the path header value. So, what do people think? (I note that we actually did something similar to this before we added the "path" attribute. ) Thanks! Ben. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 19:39:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21715 for ; Tue, 7 Dec 2004 19:39:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbpye-0005uZ-S1 for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 19:46:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbpp4-0004ei-0x; Tue, 07 Dec 2004 19:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbphx-00036c-Nw for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 19:29:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20375 for ; Tue, 7 Dec 2004 19:29:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbpod-0005ej-1Z for mmusic@ietf.org; Tue, 07 Dec 2004 19:36:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2004 16:33:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB80SrAJ017152; Tue, 7 Dec 2004 16:28:53 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn5-788.cisco.com [10.21.91.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB80Rxhe026174; Tue, 7 Dec 2004 16:27:59 -0800 In-Reply-To: <41B59C43.4020401@ericsson.com> References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98181672-4874-11D9-97A6-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 7 Dec 2004 09:22:38 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102465680.127555"; x:"432200"; a:"rsa-sha1"; b:"nofws:2767"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Xln1zq1vyPIRi7599eEn3p+dEMpkR9Ix0fQ0k5I0oJ3Y4YtgY6xMHch49Apz+" "G/9u72aN/FOZGBOiBZ0fYFvyh8a7DQXFYXWekH8XZdQKDNAGBNBvHHYcq2JLZ" "jiFCcpPVoRRTdHsdu4oFi4lNCpMhEXA+2ErgKghv1pLqAI/9Q="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Tue, 7 Dec 2004 09:22:38 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.6 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit hi Magnus, On Dec 7, 2004, at 4:04 AM, Magnus Westerlund wrote: > Hi Mark, > > Mark Baugher wrote: >> Yes it does. There are two possible approaches. We have an existing >> parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the >> SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR >> packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is >> encrypted but the XR packets are to be left in the clear (and signaled >> using the E bit). That's my current default if no one speaks up with >> an alternative preference. > > I think one should consider that there actually may be need to > negotiate what should be left unencrypted, or the other way around. > Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" > and then another negotiated attribute listing the RTCP packet types > that should be protected or the other way around. One can also > consider if the normal case is based on senders local policy. I don't think there are any security concerns in doing what you suggest apart from complexity. It is more secure to allow a particular SRTCP packet to be in the clear rather than having to keep all of them in the clear for the sake of monitoring one or a subset of the SRTCP. This is the point of the E bit, I suppose. The problem I have with negotiating which packet types would be encrypted or not is the complexity and the concomitant effort needed to test the protocol, which doubles the SRTCP test cases since each case needs to be run with each SRTCP message in the clear and encrypted using E bit settings. It's actually much worse since we're dealing with subsets. The signaling complexity is also huge: For all practical purposes, implementations never test all possible subsets of SRTCP packets in a PARTIALENCRYPTED_SRTCP negotiation. Given this level of complexity and the challenges of testing, the overall security of the implementations will be much weaker than if we kept it simple. We would need to have a real strong motivation to take on this burden. So far, we have had one group ask to have one message optionally left in the clear when SRTCP is encrypted. That's XR. I think this is manageable. Mark > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 19:50:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22850 for ; Tue, 7 Dec 2004 19:50:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbq91-00067t-Na for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 19:57:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbq0W-0007io-0D; Tue, 07 Dec 2004 19:48:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbpwQ-0006wo-4F for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 19:44:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22278 for ; Tue, 7 Dec 2004 19:44:22 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbq35-00060e-MQ for mmusic@ietf.org; Tue, 07 Dec 2004 19:51:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2004 16:48:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB80hnAJ024413; Tue, 7 Dec 2004 16:43:50 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn5-788.cisco.com [10.21.91.20]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB80gtFr026288; Tue, 7 Dec 2004 16:42:55 -0800 In-Reply-To: <77AB3B58-4870-11D9-9AFB-000A957FC5F2@csperkins.org> References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> <41B5CAED.8000200@cisco.com> <77AB3B58-4870-11D9-9AFB-000A957FC5F2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <380024A2-48B2-11D9-8183-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 7 Dec 2004 16:43:46 -0800 To: Colin Perkins X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102466576.126650"; x:"432200"; a:"rsa-sha1"; b:"nofws:2487"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ZNxxoFiZH3CAB4ONz3yekZMTPvGTrJzQWPADKdd2H0toAKrDzFGss0JsYa7+4" "r4+RpdBzR1TQ+t8JIumk9EKt2o6KqRHwc9hkVE06glFF9oYWyelYJqsJbS9lH" "RfcxAYSEfONO1wq7dQhhMPokb820Y8boEY+L7Aw8uZgLL38oc="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Tue, 7 Dec 2004 16:43:46 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Magnus Westerlund , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Colin Do we know of any other applications besides RFC 3611 that might need to selectively encrypt SRTCP packets? I am okay with putting this requirement aside pending a separate document. But before someone goes to the trouble of writing the new draft, it might be good to consider if it's needed or not. Mark On Dec 7, 2004, at 8:53 AM, Colin Perkins wrote: > On 7 Dec 2004, at 15:23, Flemming Andreasen wrote: >> Magnus Westerlund wrote: >>> Mark Baugher wrote: >>>> Yes it does. There are two possible approaches. We have an >>>> existing >>>> parameter called UNENCRYPTED_SRTCP, but the default is to encrypt >>>> the >>>> SRTCP. We could add a parameter specific to RFC 3611 or SRTCP XR >>>> packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is >>>> encrypted but the XR packets are to be left in the clear (and >>>> signaled >>>> using the E bit). That's my current default if no one speaks up >>>> with >>>> an alternative preference. >>> >>> I think one should consider that there actually may be need to >>> negotiate what should be left unencrypted, or the other way around. >>> Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" >>> and then another negotiated attribute listing the RTCP packet types >>> that should be protected or the other way around. One can also >>> consider if the normal case is based on senders local policy. >>> >> Hmm, I think we are getting on a slippery slope here with an extended >> scope, which is part of my initial concern with the whole idea of >> partially encrypted streams for the benefit of intermediate snoopers. >> What about the RTP stream ? Should we allow different treatment of >> different RTP packets, e.g. based on payload type, etc. ? Taking a >> step back, what are the motivations behind all of this added >> complexity and is this really the right time to expand the scope this >> way ? > > All good points. How difficult would it be to write this up as a > separate draft? That would allow the "sdescriptions" work to progress > quickly, and allow us time to analyse the requirements for partial > encryption, write a considered specification of the various > parameters, and enumerate the new security considerations that might > arise. > > Colin > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 23:20:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11440 for ; Tue, 7 Dec 2004 23:20:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbtPq-0002NG-Ur for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 23:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbtF7-0003of-Au; Tue, 07 Dec 2004 23:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbtCR-0002oL-BG for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 23:13:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10963 for ; Tue, 7 Dec 2004 23:13:08 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbtJ7-0002Cb-Lh for mmusic@ietf.org; Tue, 07 Dec 2004 23:20:07 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2004 21:17:53 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB84CaAJ027446 for ; Tue, 7 Dec 2004 20:12:37 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com [10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGE62215; Tue, 7 Dec 2004 20:12:35 -0800 (PST) Message-ID: <41B67F33.2030203@cisco.com> Date: Tue, 07 Dec 2004 23:12:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE issue: RTP specificity of the candidate attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Folks, I got some private comments on the ICE-03 spec, and in the process of going through them, a few of them were significant enough that they require group discussion. The issue that was raised here is that the SDP candidate attribute is currently very RTP specific. This would make it necessary to define new SDP attributes for other transport protocols that wish to use the ICE framework. It also means that its hard to handle cases like RFC 2733, where there is an IP/port conveyed in an fmtp line. The suggestion is to change the syntax of the candidate attribute so that its not RTP specific. It would do this by specifying a potential candidate for a particular IP/port that is indicated explicitly. Thus: candidate-attribute = "candidate" ":" id SP qvalue SP user-frag SP password SP unicast-address SP port candidate-addr SP candidate-port So, for example: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar c=IN IP4 1.2.3.4 a=recvonly m=audio 49170 RTP/AVP 0 a=candidate 1 0.4 adsasda 9as8dasd 1.2.3.4 49170 10.0.1.1 8700 a=candidate 1 0.4 asf9fdf8 00d-ffas 1.2.3.4 49171 10.0.1.1 8765 In this example, it means that the RTP IP/port of 1.2.3.4:49170 has an alternate of 10.0.1.1:8700, and the RTCP IP/port of 1.2.3.4:49171 has an alternate of 10.0.1.1:8765. The pros/cons of this proposal as I see them are: Pros - makes ICE more RTP independent - works better with RFC 2733 and other protocols which might convey IP addresses in SDP in other places besides the c/m lines Cons - increases SDP message size for the normal RTP case, since you always need to include to a=candidate lines for each media stream (one for RTP, one for RTCP) - yet another non-backwards compatible change in the grammar with the previous draft (not clear it matters) I'm inclined to make the change. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 7 23:43:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13545 for ; Tue, 7 Dec 2004 23:43:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbtmw-0002vA-3R for mmusic-web-archive@ietf.org; Tue, 07 Dec 2004 23:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbtcj-0002hX-Ep; Tue, 07 Dec 2004 23:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbtVf-0001Dd-7O for mmusic@megatron.ietf.org; Tue, 07 Dec 2004 23:33:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12643 for ; Tue, 7 Dec 2004 23:33:00 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbtcL-0002fa-PA for mmusic@ietf.org; Tue, 07 Dec 2004 23:39:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Dec 2004 20:35:04 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB84WQD9025322 for ; Tue, 7 Dec 2004 20:32:27 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com [10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGE62671; Tue, 7 Dec 2004 20:32:27 -0800 (PST) Message-ID: <41B683DB.9050105@cisco.com> Date: Tue, 07 Dec 2004 23:32:27 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE issue: obfuscating candidate addresses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit In ICE-03, the IP addresses in the a=candidate attribute are "in the clear". If the SDP is not protected (for example using SIP over TLS or S/MIME), a "helpful" NAT which sees the SDP may try to rewrite the IP addresses it sees in the payload. The STUN revision (draft-ietf-behave-rfc3489bis) addressed this by including an obfuscated version of the address in the STUN response, so these "helpful" nats couldn't rewrite them. I got a private comment suggesting that we do the same for ICE, to prevent the same problem. Its less severe here, since SIP over TLS will eliminate the problem (you can't run STUN BindingRequests over TCP). However, for UDP it is a similar problem. So, the proposal would be to encode the IP address/port in the SDP by xor'ing it with the lower bits of the username field. The pros/cons of this approach are: PROS - avoids incorrect ICE operation when "helpful" nats try to rewrite IP addresses they see in packets CONS - debugging harder since IP/port are not directly readable - result of xor needs to be base64 encoded (or something similar) since the xor operation may not produce valid SDP characters - slightly larger SDP messages due to base64 encoding I'm somewhat on the fence here since the right answer is really "use TLS". The costs are relatively low, but this type of NAT is not that common, so the risk is low as well. I'm probably inclined to not make the change, and just document the issue. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 8 11:25:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11241 for ; Wed, 8 Dec 2004 11:25:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4k5-0001Mk-H8 for mmusic-web-archive@ietf.org; Wed, 08 Dec 2004 11:32:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4Wo-0001ck-54; Wed, 08 Dec 2004 11:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4H0-0005N3-RI for mmusic@megatron.ietf.org; Wed, 08 Dec 2004 11:02:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09047 for ; Wed, 8 Dec 2004 11:02:36 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4Nl-0000ii-Lj for mmusic@ietf.org; Wed, 08 Dec 2004 11:09:40 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 Dec 2004 11:08:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.1.101] (rtp-vpn1-365.cisco.com [10.82.225.109]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB8G22Yr000144; Wed, 8 Dec 2004 11:02:02 -0500 (EST) Message-ID: <41B72579.6070804@cisco.com> Date: Wed, 08 Dec 2004 11:02:01 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE issue: RTP specificity of the candidate attribute References: <41B67F33.2030203@cisco.com> In-Reply-To: <41B67F33.2030203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Since ICE is not RTP-specific, we should make it general. Also, the 2733 case shows that lack of generality may even be a problem for RTP streams. Comparing the -03 attribute definition with the proposal here, the overall size increase is not that great (nowhere near a doubling). While you could squeeze out a few bytes with some optimizations in the definition, I doubt it is worth it. In other words, I agree with the proposed change. Btw, your example shows the same "id" value for the two candidates - is this intentional (implying some kind of grouping) ? -- Flemming Jonathan Rosenberg wrote: > Folks, > > I got some private comments on the ICE-03 spec, and in the process of > going through them, a few of them were significant enough that they > require group discussion. > > The issue that was raised here is that the SDP candidate attribute is > currently very RTP specific. This would make it necessary to define > new SDP attributes for other transport protocols that wish to use the > ICE framework. It also means that its hard to handle cases like RFC > 2733, where there is an IP/port conveyed in an fmtp line. > > The suggestion is to change the syntax of the candidate attribute so > that its not RTP specific. It would do this by specifying a potential > candidate for a particular IP/port that is indicated explicitly. Thus: > > candidate-attribute = "candidate" ":" id SP qvalue SP > user-frag SP password SP > unicast-address SP port > candidate-addr SP candidate-port > > > So, for example: > v=0 > o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 > s=SDP Seminar > c=IN IP4 1.2.3.4 > a=recvonly > m=audio 49170 RTP/AVP 0 > a=candidate 1 0.4 adsasda 9as8dasd 1.2.3.4 49170 10.0.1.1 8700 > a=candidate 1 0.4 asf9fdf8 00d-ffas 1.2.3.4 49171 10.0.1.1 8765 > > In this example, it means that the RTP IP/port of 1.2.3.4:49170 has an > alternate of 10.0.1.1:8700, and the RTCP IP/port of 1.2.3.4:49171 has > an alternate of 10.0.1.1:8765. > > > The pros/cons of this proposal as I see them are: > > Pros > - makes ICE more RTP independent > - works better with RFC 2733 and other protocols which might convey > IP addresses in SDP in other places besides the c/m lines > > Cons > - increases SDP message size for the normal RTP case, since you > always need to include to a=candidate lines for each media stream (one > for RTP, one for RTCP) > - yet another non-backwards compatible change in the grammar with > the previous draft (not clear it matters) > > > I'm inclined to make the change. Comments? > > -Jonathan R. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 8 11:31:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12051 for ; Wed, 8 Dec 2004 11:31:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4pK-0001Vu-M7 for mmusic-web-archive@ietf.org; Wed, 08 Dec 2004 11:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4XX-0001jo-Js; Wed, 08 Dec 2004 11:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4MF-0006qw-VI for mmusic@megatron.ietf.org; Wed, 08 Dec 2004 11:08:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09437 for ; Wed, 8 Dec 2004 11:08:01 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4T2-0000pY-Tc for mmusic@ietf.org; Wed, 08 Dec 2004 11:15:06 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2004 11:07:32 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.1.101] (rtp-vpn1-365.cisco.com [10.82.225.109]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB8G7TYr002753; Wed, 8 Dec 2004 11:07:30 -0500 (EST) Message-ID: <41B726C1.7060507@cisco.com> Date: Wed, 08 Dec 2004 11:07:29 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE issue: obfuscating candidate addresses References: <41B683DB.9050105@cisco.com> In-Reply-To: <41B683DB.9050105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit I'm on the fence too, but UDP without S/MIME is out there, and if the problem warrants a solution in STUN, it begs the question of why it wouldn't warrant a similar solution here. I'm open either way. -- Flemming Jonathan Rosenberg wrote: > In ICE-03, the IP addresses in the a=candidate attribute are "in the > clear". If the SDP is not protected (for example using SIP over TLS or > S/MIME), a "helpful" NAT which sees the SDP may try to rewrite the IP > addresses it sees in the payload. The STUN revision > (draft-ietf-behave-rfc3489bis) addressed this by including an > obfuscated version of the address in the STUN response, so these > "helpful" nats couldn't rewrite them. > > I got a private comment suggesting that we do the same for ICE, to > prevent the same problem. Its less severe here, since SIP over TLS > will eliminate the problem (you can't run STUN BindingRequests over > TCP). However, for UDP it is a similar problem. > > So, the proposal would be to encode the IP address/port in the SDP by > xor'ing it with the lower bits of the username field. > > The pros/cons of this approach are: > > PROS > > - avoids incorrect ICE operation when "helpful" nats try to rewrite > IP addresses they see in packets > > CONS > > - debugging harder since IP/port are not directly readable > - result of xor needs to be base64 encoded (or something similar) > since the xor operation may not produce valid SDP characters > - slightly larger SDP messages due to base64 encoding > > > I'm somewhat on the fence here since the right answer is really "use > TLS". The costs are relatively low, but this type of NAT is not that > common, so the risk is low as well. I'm probably inclined to not make > the change, and just document the issue. > > Comments? > > -Jonathan R. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 8 12:11:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15099 for ; Wed, 8 Dec 2004 12:11:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5S4-0002QX-PX for mmusic-web-archive@ietf.org; Wed, 08 Dec 2004 12:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc56t-0002Fg-00; Wed, 08 Dec 2004 11:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc51z-0000jf-Vk for mmusic@megatron.ietf.org; Wed, 08 Dec 2004 11:51:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13297 for ; Wed, 8 Dec 2004 11:51:09 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc58n-0001wi-Sf for mmusic@ietf.org; Wed, 08 Dec 2004 11:58:14 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB8GpAO6004822 for ; Wed, 8 Dec 2004 17:51:10 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 17:51:09 +0100 Received: from [147.214.34.68] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.68]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YDRHJ38S; Wed, 8 Dec 2004 17:51:09 +0100 Message-ID: <41B730FD.7060709@ericsson.com> Date: Wed, 08 Dec 2004 17:51:09 +0100 X-Sybari-Trust: 0248e21c 87bd62f0 34f6d43b 00000979 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE issue: RTP specificity of the candidate attribute References: <41B67F33.2030203@cisco.com> In-Reply-To: <41B67F33.2030203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2004 16:51:09.0263 (UTC) FILETIME=[1DEB5DF0:01C4DD46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hi Jonathan, I think this is the right direction. I do however wonder if it is the right solution. Your current solution indicates multiple lines that are part of the same address candidate. I think using a ABNF that kept each candidate on a single line might be better. As all address for the same candidate is needed, due to the protocols need, like both RTP and RTCP addresses for RTP. The question here is if one should use explicit binding as you propose, or rely on the order defined by the protocol when specifying address. However it might be easier to do the binding explicitly. My proposal for ABNF for a single line solution would be: candidate-attribute = "candidate" ":" id SP qvalue SP user-frag SP password 1*(SP address-spec) address-spec = (unicast-address "/" port ";" candidate-addr "/" candidate-port ) Jonathan Rosenberg wrote: > Folks, > > I got some private comments on the ICE-03 spec, and in the process of > going through them, a few of them were significant enough that they > require group discussion. > > The issue that was raised here is that the SDP candidate attribute is > currently very RTP specific. This would make it necessary to define new > SDP attributes for other transport protocols that wish to use the ICE > framework. It also means that its hard to handle cases like RFC 2733, > where there is an IP/port conveyed in an fmtp line. > I would like to point out that I at least are trying to deprecate that type of usage, due to its unsuitability in SDP. As we have deployed a number of SDP extension, that applies to the media session, specifying another session inside FMTP lines looses all these extensions. Thus my personal opinion is that it is easier to remove the few special cases like RFC 2733 than to get the other mechanisms to work for the special cases. That is why I have argued in the ULP context to change the binding between original data and FEC data. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 8 12:28:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16333 for ; Wed, 8 Dec 2004 12:28:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5ib-0002oh-U5 for mmusic-web-archive@ietf.org; Wed, 08 Dec 2004 12:35:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5Mz-0006Fz-Uj; Wed, 08 Dec 2004 12:12:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc59W-0002e5-Hv for mmusic@megatron.ietf.org; Wed, 08 Dec 2004 11:58:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14137 for ; Wed, 8 Dec 2004 11:58:56 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5G9-0002AJ-K1 for mmusic@ietf.org; Wed, 08 Dec 2004 12:06:01 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB8Gwjh5009349 for ; Wed, 8 Dec 2004 17:58:45 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 17:58:45 +0100 Received: from [147.214.34.68] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.68]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XVCWP21K; Wed, 8 Dec 2004 17:58:45 +0100 Message-ID: <41B732C5.1090801@ericsson.com> Date: Wed, 08 Dec 2004 17:58:45 +0100 X-Sybari-Trust: 21ac98bd a5e9b67f 4bff7f0f 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE issue: obfuscating candidate addresses References: <41B683DB.9050105@cisco.com> In-Reply-To: <41B683DB.9050105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2004 16:58:45.0768 (UTC) FILETIME=[2E048080:01C4DD47] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi Jonathan, A few questions: - Are these NATs that are helpfull common? - How can these helpful NATs work at all. Even if I only replace bytes that matches the private source IP address of an outgoing packet. There must be significant risk that the packet contains that pattern in something that is not and adress. Do they only do this is certain identfiable protcols? - Finnally if they only replace addresses related to the private adresses, would an replacement actually have any ill-effect on ICE? It would foul up the default address, however with a explicit syntax, only the default and binding adress woudl be replaced, not the candidate? Unless the candidate is the private source adress, which anyway becomes unvalid by the passing through the NAT. So please consider a bit more if this really is useful. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 8 15:48:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02762 for ; Wed, 8 Dec 2004 15:48:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8qu-0007Bq-FU for mmusic-web-archive@ietf.org; Wed, 08 Dec 2004 15:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8a0-0001FW-4k; Wed, 08 Dec 2004 15:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8TM-0006XI-7B; Wed, 08 Dec 2004 15:31:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01629; Wed, 8 Dec 2004 15:31:38 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8aB-0006tA-7n; Wed, 08 Dec 2004 15:38:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 13:36:30 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB8KV4Pv002868; Wed, 8 Dec 2004 12:31:04 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn1-223.cisco.com [10.21.96.223]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB8KU5On001124; Wed, 8 Dec 2004 12:30:05 -0800 In-Reply-To: <4.3.2.7.2.20041208134458.02880aa0@mira-sjc5-e.cisco.com> References: <4.3.2.7.2.20041208134458.02880aa0@mira-sjc5-e.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <119F387A-4958-11D9-8183-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Wed, 8 Dec 2004 12:30:58 -0800 To: "Michael A. Ramalho" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102537807.865418"; x:"432200"; a:"rsa-sha1"; b:"nofws:24769"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RsDtDPKbGs8PEp5GvvW1SAqiP7scCMvdNXKdky73PgIXsCwQwfOuKSsYXA54n" "2f1FZE8mUGWqm1RCJ/WVIgRJplCRL+KbnuHqYuikU2KK8H+FTCRAhxuHkfSha" "78SirdJB15tBXIaRhPDJADHTriWBpJDTpD9CLwNgwEmRM0qkk="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Wed, 8 Dec 2004 12:30:58 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.2 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Content-Transfer-Encoding: 7bit Cc: rmonmib@ietf.org, "Romascanu, Dan \(Dan\)" , mmusic@ietf.org, avt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Content-Transfer-Encoding: 7bit Michael Here's my take on the security of all of this: Endpoints can choose to negotiate UNENCRYPTED_SRTCP or refuse such an offer, but the goal is to not force use of UNENCRYPTED_SRTCP when only the XR packet needs to be in the clear. If we enabled the E bit for XR packets, that would not prevent an endpoint from rejecting the offer or any offer in which the SRTCP is not encrypted. If one does not want to expose information in the XR packets, then reject UNENCRYPTED_SRTCP or any offer that allows use of the E bit (in the future). I don't see any security problem apart from having no recourse except to offer UNENCRYPTED_SRTCP when all that is desired is to leave one SRTCP packet type in the clear. Besides that, all sequence numbers are always in the clear in SRTP. Mark On Dec 8, 2004, at 11:01 AM, Michael A. Ramalho wrote: > At 09:02 AM 12/2/2004 -0800, Mark Baugher wrote: >> Dan >> I think use of the E bit needs to be explicitly signaled the SDP >> security descriptions. That way, an offerer or answerer can express >> whether it wants to have all SRTCP messages encrypted or allow some >> to be in the clear. I don't know if we need to call out the specific >> SRTCP messages that may be left in the clear or do make it "general >> purpose." > > Mark, > > I was looking into this last week. I think it would be unwise to leave > UNencrypted any RTCP block type that has RTP Sequence Numbers > in it (as they would be in the clear). > > For example, the Loss RLE block (a RTCP-XR block) has information > on the base RTP sequence numbers the Loss RLE block reports on. > There are many such RTCP-XR block types (but the VoIP Metrics > Block is not one of these :-)). > > This would expose a "guess-able range" for *part of* the packet index > used in SRTP (as I remember it, the SRTP packet index uses the > RTP sequence number for low order portion of the packet index). > I think this would be a no-no for the cryptographic experts. > >> A general-purpose approach would be to signal that ENCRYPTED_SRTP can >> be overridden for any packet for which the sender chooses to clear >> the E bit. The general-purpose mechanism might be suitable for going >> into draft-ietf-mmusic-sdescriptions-08.txt. If we want to >> explicitly signal that the E bit can be clear just for XR packets >> when UNENCRYPTED_SRTCP is set, then I think that belongs in RFC >> 3611bis. > > If my assertion/guess above is correct, then I'd only recommend the > option to leave in the clear only those RTCP-XR packets that do not > expose information sensitive to the SRTP context. This would be a > trivial > exercise (to look at the blocks and decide which ones you do not want > sent in the clear) but does complicate the permutations/combinations of > what would need to be signaled in SDP. > > And then, since RTPC blocks may be piggybacked, one must take > care not to have*potentially unencrptable* blocks piggybacked with > other "normally encrypted" blocks. I still don't like the potential > interaction > between the "encryption" and "RTCP" layers here. > > Michael Ramalho > > >> Mark >> On Dec 2, 2004, at 3:45 AM, Romascanu, Dan ((Dan)) wrote: >> >>> I would be cautious in saying that in no circumstances the contents >>> of an XR payload would be remotely useful to an eavesdropper. We may >>> encounter some very security aware environments where even the fact >>> that a call happens between two IP phones, its duration, or QoS >>> parameters need to be kept confidential. For this reason, while >>> working to provide a strong recommendation for RTCP XR packets not >>> to be encrypted, I do not believe that we can make this a MUST >>> requirements. As an alternative, I suggest to use RAQMON extensions >>> to report the RTCP XR metrics to RAQMON collectors without the >>> security risks that may be of concern in some environments. >>> >>> Regards, >>> >>> Dan >>> >>> >>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org >>>> [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark >>>> Sent: 01 December, 2004 2:08 PM >>>> To: Mark Baugher >>>> Cc: mmusic@ietf.org >>>> Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>>> >>>> >>>> Mark >>>> >>>> To provide some background to the list - RFC3611 states the >>>> following:- >>>> >>>> "Any encryption or filtering of XR report blocks entails a loss >>>> of >>>> monitoring information to third parties. For example, a >>>> network that >>>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>>> information to the service providers traversed by the tunnel. >>>> The >>>> service providers cannot then monitor or respond to the quality >>>> of >>>> the VoIP calls that they carry, potentially creating >>>> problems for the >>>> network's users. As a default, XR packets should not be >>>> encrypted or >>>> filtered." >>>> >>>> I can't conceive of any circumstance in which the contents of >>>> an XR payload >>>> would be remotely useful to an eavesdropper and hence stating that >>>> XR >>>> payloads should always be left unencrypted would be (at least >>>> in my opinion) >>>> ok. If we wanted to make this even more specific we could narrow >>>> this >>>> requirement down to only XR VoIP Metrics payloads to avoid >>>> the situation in >>>> which some future XR payload may be problematic. >>>> >>>> The availability of VoIP metrics payloads will be a huge >>>> issue for service >>>> providers - as we move through 2005 RTCP XR will be a mainstay of >>>> VoIP >>>> performance management and is already a mandatory requirement >>>> within certain >>>> sectors of the industry. Making the VoIP metrics payload >>>> unencrypted by >>>> default may seem a small issue today however it will have >>>> major consequences >>>> to the industry as SRTP starts to roll out. >>>> >>>> Regards >>>> >>>> Alan >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Mark Baugher [mailto:mbaugher@cisco.com] >>>> Sent: Tuesday, November 30, 2004 6:45 PM >>>> To: Alan Clark >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>> >>>> >>>> Alan >>>> I am copying MMUSIC (and not cross-posting to AVT) to >>>> further discuss >>>> a possible change to SDP security descriptions, which has completed >>>> WG >>>> last call. The change is needed for RFC 3611, and we also >>>> discovered >>>> that >>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>>> -07.txt does not address the SRTCP E bit properly. I offered the >>>> following text in a posting to AVT: >>>> "As the default behavior when UNENCRYPTED_SRTCP is signaled, all >>>> SRTCP >>>> packets MUST have the E bit set to zero and MUST NOT be encrypted. >>>> Otherwise, all SRTP packets MUST have the E bit set to one and MUST >>>> be >>>> encrypted by default. Individual applications MAY override these >>>> default behaviors in their specifications. In a session where SRTCP >>>> packets are encrypted, therefore, applications that use RFC 3611 MAY >>>> set the E bit to 0 for XR packets as recommended by RFC 3611." >>>> >>>> One of my co-authors pointed out that the last sentence is >>>> more than an >>>> editorial change. We also don't like the fact that an offerer or >>>> answerer cannot explicitly signal when it wants the XR packet to be >>>> encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the >>>> default setting and RFC 3611 is also signaled, it is ambiguous as to >>>> whether the SRTCP sender will encrypt the XR packet or not. It's >>>> solely up to the sender. If the offerer or answerer want the >>>> XR packet >>>> to always be encrypted, there is no way to signal that. Ditto for >>>> the >>>> unencrypted case. >>>> >>>> I think we need to put the first three sentences of the above-quoted >>>> paragraph into SDP security descriptions as an editorial change. >>>> I'm >>>> proposing this to the working group. I also propose not to >>>> include the >>>> last sentence. Instead, we could add a new signaling parameter, >>>> UNENCRYPTED_XR, which implies that all SRTCP messages are to be >>>> encrypted except for the XR packets, which will have their E >>>> bit clear, >>>> of course. >>>> >>>> This new parameter could be placed in an RFC 3611bis or in a >>>> revision >>>> of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to >>>> undergo another WG last call. What do you (all) think about this? >>>> >>>> Mark >>>> >>>> On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: >>>> >>>>> Alan >>>>> As Dave Oran has pointed out, the definition that you want is not >>>>> supported in the signaling, at present. The current definition of >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>>>> -07.txt treats SRTCP encryption as either on or off and does not >>>>> address the problem of setting the E bit in SRTCP packets. >>>> This is a >>>>> bug that we need to fix. >>>>> >>>>> MMUSIC has finished last call on >>>>> draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have >>>>> reviewed it. We'll be making some changes at Jon Peterson's >>>>> request >>>>> and post another version in about a week. This is an opportunity >>>>> to >>>>> address the E bit, but the MMUSIC chairs or transport ADs may want >>>>> another WG last call. Off the top of my head, I would >>>> offer something >>>>> like the following. >>>>> >>>>> "As the default behavior when UNENCRYPTED_SRTCP is >>>> signaled, all SRTCP >>>>> packets MUST have the E bit set to zero and MUST NOT be encrypted. >>>>> Otherwise, all SRTP packets MUST have the E bit set to one >>>> and MUST be >>>>> encrypted by default. Individual applications MAY override these >>>>> default behaviors in their specifications. In a session where >>>>> SRTCP >>>>> packets are encrypted, therefore, applications that use RFC 3611 >>>>> MAY >>>>> set the E bit to 0 for XR packets as recommended by RFC 3611." >>>>> >>>>> Mark >>>>> >>>>> On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: >>>>> >>>>>> >>>>>> >>>>>> Mark >>>>>> >>>>>> We tried to flag this in RFC3611 with the following text in the >>>>>> "security >>>>>> considerations" section >>>>>> >>>>>> Any encryption or filtering of XR report blocks entails >>>> a loss of >>>>>> monitoring information to third parties. For example, a >>>>>> network >>>>>> that >>>>>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>>>>> information to the service providers traversed by the >>>> tunnel. The >>>>>> service providers cannot then monitor or respond to the >>>> quality of >>>>>> the VoIP calls that they carry, potentially creating >>>> problems for >>>>>> the >>>>>> network's users. As a default, XR packets should not >>>> be encrypted >>>>>> or >>>>>> filtered. >>>>>> >>>>>> Could we potentially interpret this as being the >>>> definition of what to >>>>>> selectively encrypt in the case of the RFC3611 specification? >>>>>> >>>>>> Regards >>>>>> >>>>>> Alan >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mark Baugher [mailto:mbaugher@cisco.com] >>>>>> Sent: Wednesday, November 24, 2004 2:42 PM >>>>>> To: Alan Clark >>>>>> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R >>>> Oran; Michael >>>>>> A. >>>>>> Ramalho >>>>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>> So, when the sender and receiver agree to encrypt SRTCP, this >>>>>> would >>>>>> mean >>>>>> only that some SRTCP messages would be encrypted and the >>>> sender would >>>>>> decide which ones to encrypt? My personal opinion is that >>>> this is not >>>>>> secure because it is unpredictable to the receiver, which >>>> may have a >>>>>> policy that all messages related to its session be encrypted. >>>>>> >>>>>> I can think of a few potential approaches to this problem. >>>>>> >>>>>> 1. Let individual SRTCP messages or a bundle of SRTCP messages >>>>>> be signaled to be unencrypted when SRTCP encryption is used. >>>>>> >>>>>> 2. Make a blanket policy that the sender determine what >>>>>> to selectively encrypt, as you suggest. >>>>>> >>>>>> 3. Define the policy of what to selectively encrypt in >>>>>> the particular specification. In other words, a document could >>>>>> re-define the signaling of SRTCP encryption according to its >>>>>> needs. The specification of foo, therefore, could define a new >>>>>> parameter such as foo_ENCRYPTED_SRTCP to be used in place of >>>>>> ENCRYPTED_SRTCP. The foo document would define what gets >>>>>> encrypted and what does not get encrypted as per its needs. >>>>>> >>>>>> I commented on #2 already. I don't like #1 because of its >>>> signaling >>>>>> complexity. I like #3 because it limits the complexity to the >>>>>> specific needs of an application. #1 would be more efficient than >>>>>> #3 if lots of applications had their own specific needs for >>>>>> selective encryption of SRTCP message. But I don't think this is >>>>>> the case. >>>>>> >>>>>> Mark >>>>>> >>>>>> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >>>>>> >>>>>>> >>>>>>> If the use of encryption in SRTCP is signalled by an >>>> explicit (E) bit >>>>>>> in the >>>>>>> SRTCP header then perhaps the sender could autonomously decide >>>>>>> whether >>>>>>> it >>>>>>> wants to encrypt? Presumably since the sender is in the best >>>>>>> position >>>>>>> to >>>>>>> decide if the data is sensitive then this would be ok - and the >>>>>>> receiver is >>>>>>> able to just look at the E bit and hence recognize that >>>> decryption is >>>>>>> needed. >>>>>>> >>>>>>> Alan >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: avt-bounces@ietf.org >>>> [mailto:avt-bounces@ietf.org]On Behalf Of >>>>>>> Mark Baugher >>>>>>> Sent: Wednesday, November 24, 2004 1:33 PM >>>>>>> To: David R Oran >>>>>>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>>>>>> avt@ietf.org >>>>>>> Subject: Re: [AVT] RFC 3711 and RTCP >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>>>>>> >>>>>>>> >>>>>>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> I don't see why this would be a problem unless you included >>>>>>>>> SDES >>>>>>>>> and >>>>>>>>> (SR or >>>>>>>>> RR or XR) in the same RTCP packet. SRTP (at least the >>>> protocol) is >>>>>>>>> apparently able to decided on a packet by packet basis >>>> whether to >>>>>>>>> encrypt >>>>>>>>> RTCP - hopefully SRTP implementations also permit this. >>>>>>>> Sure, they can do this. But remember offer-answer. How does a >>>>>>>> receiver >>>>>>>> communicate such a granular policy to the transmitter? >>>> Right now if >>>>>>>> can say whether to auth or auth+encrypt RTP, and auth or >>>>>>>> auth+encrypt >>>>>>>> RTCP. There's no way to say auth+encrypt SDES but only auth >>>>>>>> SR/XR >>>>>>>> etc. >>>>>>> >>>>>>> Seems to me that this is a problem with SDP security >>>>>>> descriptions. >>>>>>> That problem might be there because we forgot about the E >>>> bit. This >>>>>>> seems very messy for the reason you mention above - >>>> granularity. I >>>>>>> don't think that we want to negotiate the encryption >>>> policy for each >>>>>>> type SDP message, which is a problem with something like >>>> the E bit. >>>>>>> >>>>>>> Mark >>>>>>>> >>>>>>>> >>>>>>>>> Logically I'd send SDES on its own at the start of a call to >>>>>>>>> provide >>>>>>>>> some >>>>>>>>> user info, but would not send SR/RR/XR until at least >>>> 8-10 seconds >>>>>>>>> into the >>>>>>>>> call as I need some time to gather statistics to report. >>>>>>>> That's not exactly what the RTP specs say. RTCP timers don't >>>>>>>> have >>>>>>>> this >>>>>>>> kind of policy today. In fact, there are porposals on >>>> the table to >>>>>>>> use >>>>>>>> RTCP for early feedback to assess reception quality on >>>> some initial >>>>>>>> packets - e.g. the RTP-noop proposal. In any event that has no >>>>>>>> bearing >>>>>>>> on the present discussion. >>>>>>>> >>>>>>>>> After the >>>>>>>>> start-of-call exchange there would appear to be minimal need to >>>>>>>>> include >>>>>>>>> SDES. I'm sure we could construct some scenarios in >>>> which you "may" >>>>>>>>> need to >>>>>>>>> include SDES with SR/RR/XR however the vast majority of >>>> cases would >>>>>>>>> either >>>>>>>>> need only a single initial exchange or may not need SDES at >>>>>>>>> all. >>>>>>>> Any time you change SSRC you potentially need to send SDES. >>>>>>>> That said, I still don't see what bearing this has on >>>> the discussion >>>>>>>> about whether we need the complexity of encrypting some >>>> RTCP packets >>>>>>>> and not others for a single session. >>>>>>>> >>>>>>>> It's a tradeoff between extra complexity+less privacy versus >>>>>>>> allowing >>>>>>>> snoopers to gather RTCP stats. >>>>>>>> >>>>>>>> Dave. >>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Alan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>>>>>> Sent: Wednesday, November 24, 2004 9:39 AM >>>>>>>>> To: Alan Clark >>>>>>>>> Cc: Oren Peleg; avt@ietf.org >>>>>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>>>> >>>>>>>>> >>>>>>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>>>>>> Hi Oren >>>>>>>>>> >>>>>>>>>> Yes - encryption is intended to provide privacy however this >>>>>>>>>> relates >>>>>>>>>> primarily to the voice payloads and to information within RTCP >>>>>>>>>> that >>>>>>>>>> may be >>>>>>>>>> associated with individual users (e.g. SDES). >>>>>>>>>> >>>>>>>>>> SR, RR and XR contain only peformance statistics and >>>> there is no >>>>>>>>>> privacy >>>>>>>>>> consideration that I can think of related to this type of >>>>>>>>>> data. >>>>>>>>>> >>>>>>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>>>>>> don't >>>>>>>>> encrypt >>>>>>>>>> RTCP SR/RR/XR >>>>>>>>> >>>>>>>>> Hi Alan, >>>>>>>>> >>>>>>>>> I am wondering about implementations utilizing your advise >>>>>>>>> "optionally >>>>>>>>> encrypt >>>>>>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>>>>>> >>>>>>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>>>>>> RTCP >>>>>>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>>>>>> highly >>>>>>>>> related to each other. For example (quote out of RFC 3611): >>>>>>>>> >>>>>>>>> "XR packets supplement the existing RTCP packets, and may be >>>>>>>>> stacked >>>>>>>>> with >>>>>>>>> other RTCP packets to form compound RTCP packets [9, >>>> Section 6]." >>>>>>>>> >>>>>>>>> Thus, RFC3611 explicitly admits the possibility of (but does >>>>>>>>> not >>>>>>>>> mandate) >>>>>>>>> the piggybacking all the RTCP-XR block types. >>>>>>>>> >>>>>>>>> RTCP implementations would have to know the SRTP >>>> encryption rules >>>>>>>>> to >>>>>>>>> make sure they don't perform piggybacking with SDES ... >>>> but could >>>>>>>>> allow >>>>>>>>> (the more bandwidth efficient) piggybacking on the other >>>>>>>>> RTCP-XR >>>>>>>>> blocks. >>>>>>>>> >>>>>>>>> This RTCP/SRTP interaction/dependency seems to add a >>>> burden to both >>>>>>>>> RTCP and SRTP implementations ... let alone the expressiveness >>>>>>>>> required >>>>>>>>> to signal your advise in existing SDP/SRTP mechanisms. >>>>>>>>> >>>>>>>>> Are you aware of any implementations that have actually >>>>>>>>> followed >>>>>>>>> your >>>>>>>>> advise above? I rather go into this one with our eyes open ... >>>>>>>>> developers >>>>>>>>> highly dislike this cross-functional entity dependency >>>> (RTCP & SRTP >>>>>>>>> along >>>>>>>>> with expressing it in SDP/SRTP mechanisms). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Michael Ramalho >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Alan >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>>>>>> Sent: Wednesday, November 24, 2004 7:50 AM >>>>>>>>>> To: Alan Clark; avt@ietf.org >>>>>>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Isnt encryption is to prevent monitoring from the first place? >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: avt-bounces@ietf.org >>>> [mailto:avt-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>> Alan Clark >>>>>>>>>> Sent: Tuesday, November 23, 2004 5:42 PM >>>>>>>>>> To: avt@ietf.org >>>>>>>>>> Subject: [AVT] RFC 3711 and RTCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> From the flurry of discussion on RFC3711 it looks as >>>> if there is >>>>>>>>>> considerable interest in SRTP implementation. I'd >>>> like to add a >>>>>>>>>> request >>>>>>>>>> to >>>>>>>>>> SRTP implementors with regard to manageability. >>>>>>>>>> >>>>>>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>>>>>> block) >>>>>>>>>> contain useful information for network monitoring, and >>>> are often >>>>>>>>>> used by >>>>>>>>>> probes and analyzers to support problem diagnosis. >>>> RFC3711 allows >>>>>>>>>> the >>>>>>>>>> selective encryption of RTCP payloads and hence I >>>> would strongly >>>>>>>>>> recomment >>>>>>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>>>>>> payloads >>>>>>>>>> as >>>>>>>>>> this >>>>>>>>>> adversely impacts manageability. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Alan Clark >>>>>>>>>> Telchemy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Audio/Video Transport Working Group >>>>>>>>>> avt@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>>>>> >>>> ****************************************************************** >>>>>>>>>> ** >>>>>>>>>> * >>>>>>>>>> ****** >>>>>>>>> * >>>>>>>>>> ******************************** >>>>>>>>>> This email and any files transmitted with it are confidential >>>>>>>>>> material. >>>>>>>>>> They are intended solely for the use of the designated >>>> individual >>>>>>>>>> or >>>>>>>>>> entity >>>>>>>>>> to whom they are addressed. >>>>>>>>>> If the reader of this message is not the intended recipient, >>>>>>>>>> you are hereby notified that any dissemination,use, >>>>>>>>>> distribution or copying of this communication is strictly >>>>>>>>>> prohibited >>>>>>>>>> and >>>>>>>>> may >>>>>>>>>> be unlawful. >>>>>>>>>> >>>>>>>>>> If you have received this email in error please notify >>>>>>>>>> postmaster@audiocodes.com and permanently delete the e-mail >>>>>>>>>> and >>>>>>>>>> files. >>>>>>>>>> >>>>>>>>>> >>>> ****************************************************************** >>>>>>>>>> ** >>>>>>>>>> * >>>>>>>>>> ****** >>>>>>>>> * >>>>>>>>>> ******************************* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Audio/Video Transport Working Group >>>>>>>>>> avt@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Audio/Video Transport Working Group >>>>>>>>> avt@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>>> David R. Oran >>>>>>>> Cisco Fellow >>>>>>>> Cisco Systems >>>>>>>> 7 Ladyslipper Lane >>>>>>>> Acton, MA 01720 USA >>>>>>>> Tel: +1 978 264 2048 >>>>>>>> Email: oran@cisco.com >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Audio/Video Transport Working Group >>>>>>>> avt@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Audio/Video Transport Working Group >>>>>>> avt@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 9 04:03:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03722 for ; Thu, 9 Dec 2004 04:03:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcKKL-0008Me-8r for mmusic-web-archive@ietf.org; Thu, 09 Dec 2004 04:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcK71-0005mG-O7; Thu, 09 Dec 2004 03:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc74s-0006Bt-OF; Wed, 08 Dec 2004 14:02:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24230; Wed, 8 Dec 2004 14:02:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc7Bd-000564-9y; Wed, 08 Dec 2004 14:09:22 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 08 Dec 2004 14:08:21 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mramalho-w2k.cisco.com (dhcp-64-100-135-181.cisco.com [64.100.135.181]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB8I1cA7017672; Wed, 8 Dec 2004 13:01:38 -0500 (EST) Message-Id: <4.3.2.7.2.20041208134458.02880aa0@mira-sjc5-e.cisco.com> X-Sender: mramalho@mira-sjc5-e.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Dec 2004 14:01:37 -0500 To: Mark Baugher From: "Michael A. Ramalho" Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e X-Mailman-Approved-At: Thu, 09 Dec 2004 03:57:22 -0500 Cc: rmonmib@ietf.org, "Romascanu, Dan \(Dan\)" , avt@ietf.org, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 0f3de74e534ea82d41273d2b8504db1c At 09:02 AM 12/2/2004 -0800, Mark Baugher wrote: >Dan > I think use of the E bit needs to be explicitly signaled the SDP > security descriptions. That way, an offerer or answerer can express > whether it wants to have all SRTCP messages encrypted or allow some to be > in the clear. I don't know if we need to call out the specific SRTCP > messages that may be left in the clear or do make it "general purpose." Mark, I was looking into this last week. I think it would be unwise to leave UNencrypted any RTCP block type that has RTP Sequence Numbers in it (as they would be in the clear). For example, the Loss RLE block (a RTCP-XR block) has information on the base RTP sequence numbers the Loss RLE block reports on. There are many such RTCP-XR block types (but the VoIP Metrics Block is not one of these :-)). This would expose a "guess-able range" for *part of* the packet index used in SRTP (as I remember it, the SRTP packet index uses the RTP sequence number for low order portion of the packet index). I think this would be a no-no for the cryptographic experts. >A general-purpose approach would be to signal that ENCRYPTED_SRTP can be >overridden for any packet for which the sender chooses to clear the E >bit. The general-purpose mechanism might be suitable for going into >draft-ietf-mmusic-sdescriptions-08.txt. If we want to explicitly signal >that the E bit can be clear just for XR packets when UNENCRYPTED_SRTCP is >set, then I think that belongs in RFC 3611bis. If my assertion/guess above is correct, then I'd only recommend the option to leave in the clear only those RTCP-XR packets that do not expose information sensitive to the SRTP context. This would be a trivial exercise (to look at the blocks and decide which ones you do not want sent in the clear) but does complicate the permutations/combinations of what would need to be signaled in SDP. And then, since RTPC blocks may be piggybacked, one must take care not to have*potentially unencrptable* blocks piggybacked with other "normally encrypted" blocks. I still don't like the potential interaction between the "encryption" and "RTCP" layers here. Michael Ramalho >Mark >On Dec 2, 2004, at 3:45 AM, Romascanu, Dan ((Dan)) wrote: > >>I would be cautious in saying that in no circumstances the contents of an >>XR payload would be remotely useful to an eavesdropper. We may encounter >>some very security aware environments where even the fact that a call >>happens between two IP phones, its duration, or QoS parameters need to be >>kept confidential. For this reason, while working to provide a strong >>recommendation for RTCP XR packets not to be encrypted, I do not believe >>that we can make this a MUST requirements. As an alternative, I suggest >>to use RAQMON extensions to report the RTCP XR metrics to RAQMON >>collectors without the security risks that may be of concern in some >>environments. >> >>Regards, >> >>Dan >> >> >> >>>-----Original Message----- >>>From: mmusic-bounces@ietf.org >>>[mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark >>>Sent: 01 December, 2004 2:08 PM >>>To: Mark Baugher >>>Cc: mmusic@ietf.org >>>Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >>> >>> >>>Mark >>> >>>To provide some background to the list - RFC3611 states the >>>following:- >>> >>> "Any encryption or filtering of XR report blocks entails a loss of >>> monitoring information to third parties. For example, a >>>network that >>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>> information to the service providers traversed by the tunnel. The >>> service providers cannot then monitor or respond to the quality of >>> the VoIP calls that they carry, potentially creating >>>problems for the >>> network's users. As a default, XR packets should not be >>>encrypted or >>> filtered." >>> >>>I can't conceive of any circumstance in which the contents of >>>an XR payload >>>would be remotely useful to an eavesdropper and hence stating that XR >>>payloads should always be left unencrypted would be (at least >>>in my opinion) >>>ok. If we wanted to make this even more specific we could narrow this >>>requirement down to only XR VoIP Metrics payloads to avoid >>>the situation in >>>which some future XR payload may be problematic. >>> >>>The availability of VoIP metrics payloads will be a huge >>>issue for service >>>providers - as we move through 2005 RTCP XR will be a mainstay of VoIP >>>performance management and is already a mandatory requirement >>>within certain >>>sectors of the industry. Making the VoIP metrics payload >>>unencrypted by >>>default may seem a small issue today however it will have >>>major consequences >>>to the industry as SRTP starts to roll out. >>> >>>Regards >>> >>>Alan >>> >>> >>> >>>-----Original Message----- >>>From: Mark Baugher [mailto:mbaugher@cisco.com] >>>Sent: Tuesday, November 30, 2004 6:45 PM >>>To: Alan Clark >>>Cc: mmusic@ietf.org >>>Subject: Re: [AVT] RFC 3711 and RTCP >>> >>> >>>Alan >>> I am copying MMUSIC (and not cross-posting to AVT) to >>>further discuss >>>a possible change to SDP security descriptions, which has completed WG >>>last call. The change is needed for RFC 3611, and we also discovered >>>that >>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>>-07.txt does not address the SRTCP E bit properly. I offered the >>>following text in a posting to AVT: >>>"As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP >>>packets MUST have the E bit set to zero and MUST NOT be encrypted. >>>Otherwise, all SRTP packets MUST have the E bit set to one and MUST be >>>encrypted by default. Individual applications MAY override these >>>default behaviors in their specifications. In a session where SRTCP >>>packets are encrypted, therefore, applications that use RFC 3611 MAY >>>set the E bit to 0 for XR packets as recommended by RFC 3611." >>> >>>One of my co-authors pointed out that the last sentence is >>>more than an >>>editorial change. We also don't like the fact that an offerer or >>>answerer cannot explicitly signal when it wants the XR packet to be >>>encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the >>>default setting and RFC 3611 is also signaled, it is ambiguous as to >>>whether the SRTCP sender will encrypt the XR packet or not. It's >>>solely up to the sender. If the offerer or answerer want the >>>XR packet >>>to always be encrypted, there is no way to signal that. Ditto for the >>>unencrypted case. >>> >>>I think we need to put the first three sentences of the above-quoted >>>paragraph into SDP security descriptions as an editorial change. I'm >>>proposing this to the working group. I also propose not to >>>include the >>>last sentence. Instead, we could add a new signaling parameter, >>>UNENCRYPTED_XR, which implies that all SRTCP messages are to be >>>encrypted except for the XR packets, which will have their E >>>bit clear, >>>of course. >>> >>>This new parameter could be placed in an RFC 3611bis or in a revision >>>of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to >>>undergo another WG last call. What do you (all) think about this? >>> >>>Mark >>> >>>On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: >>> >>>>Alan >>>> As Dave Oran has pointed out, the definition that you want is not >>>>supported in the signaling, at present. The current definition of >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>>>-07.txt treats SRTCP encryption as either on or off and does not >>>>address the problem of setting the E bit in SRTCP packets. >>>This is a >>>>bug that we need to fix. >>>> >>>> MMUSIC has finished last call on >>>>draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have >>>>reviewed it. We'll be making some changes at Jon Peterson's request >>>>and post another version in about a week. This is an opportunity to >>>>address the E bit, but the MMUSIC chairs or transport ADs may want >>>>another WG last call. Off the top of my head, I would >>>offer something >>>>like the following. >>>> >>>>"As the default behavior when UNENCRYPTED_SRTCP is >>>signaled, all SRTCP >>>>packets MUST have the E bit set to zero and MUST NOT be encrypted. >>>>Otherwise, all SRTP packets MUST have the E bit set to one >>>and MUST be >>>>encrypted by default. Individual applications MAY override these >>>>default behaviors in their specifications. In a session where SRTCP >>>>packets are encrypted, therefore, applications that use RFC 3611 MAY >>>>set the E bit to 0 for XR packets as recommended by RFC 3611." >>>> >>>>Mark >>>> >>>>On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: >>>> >>>>> >>>>> >>>>>Mark >>>>> >>>>>We tried to flag this in RFC3611 with the following text in the >>>>>"security >>>>>considerations" section >>>>> >>>>> Any encryption or filtering of XR report blocks entails >>>a loss of >>>>> monitoring information to third parties. For example, a network >>>>>that >>>>> establishes a tunnel to encrypt VoIP Report Blocks denies that >>>>> information to the service providers traversed by the >>>tunnel. The >>>>> service providers cannot then monitor or respond to the >>>quality of >>>>> the VoIP calls that they carry, potentially creating >>>problems for >>>>>the >>>>> network's users. As a default, XR packets should not >>>be encrypted >>>>>or >>>>> filtered. >>>>> >>>>>Could we potentially interpret this as being the >>>definition of what to >>>>>selectively encrypt in the case of the RFC3611 specification? >>>>> >>>>>Regards >>>>> >>>>>Alan >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Mark Baugher [mailto:mbaugher@cisco.com] >>>>>Sent: Wednesday, November 24, 2004 2:42 PM >>>>>To: Alan Clark >>>>>Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R >>>Oran; Michael >>>>>A. >>>>>Ramalho >>>>>Subject: Re: [AVT] RFC 3711 and RTCP >>>>> >>>>> >>>>>So, when the sender and receiver agree to encrypt SRTCP, this would >>>>>mean >>>>>only that some SRTCP messages would be encrypted and the >>>sender would >>>>>decide which ones to encrypt? My personal opinion is that >>>this is not >>>>>secure because it is unpredictable to the receiver, which >>>may have a >>>>>policy that all messages related to its session be encrypted. >>>>> >>>>>I can think of a few potential approaches to this problem. >>>>> >>>>>1. Let individual SRTCP messages or a bundle of SRTCP messages >>>>>be signaled to be unencrypted when SRTCP encryption is used. >>>>> >>>>>2. Make a blanket policy that the sender determine what >>>>>to selectively encrypt, as you suggest. >>>>> >>>>>3. Define the policy of what to selectively encrypt in >>>>>the particular specification. In other words, a document could >>>>>re-define the signaling of SRTCP encryption according to its >>>>>needs. The specification of foo, therefore, could define a new >>>>>parameter such as foo_ENCRYPTED_SRTCP to be used in place of >>>>>ENCRYPTED_SRTCP. The foo document would define what gets >>>>>encrypted and what does not get encrypted as per its needs. >>>>> >>>>>I commented on #2 already. I don't like #1 because of its >>>signaling >>>>>complexity. I like #3 because it limits the complexity to the >>>>>specific needs of an application. #1 would be more efficient than >>>>>#3 if lots of applications had their own specific needs for >>>>>selective encryption of SRTCP message. But I don't think this is >>>>>the case. >>>>> >>>>>Mark >>>>> >>>>>On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >>>>> >>>>>> >>>>>>If the use of encryption in SRTCP is signalled by an >>>explicit (E) bit >>>>>>in the >>>>>>SRTCP header then perhaps the sender could autonomously decide >>>>>>whether >>>>>>it >>>>>>wants to encrypt? Presumably since the sender is in the best >>>>>>position >>>>>>to >>>>>>decide if the data is sensitive then this would be ok - and the >>>>>>receiver is >>>>>>able to just look at the E bit and hence recognize that >>>decryption is >>>>>>needed. >>>>>> >>>>>>Alan >>>>>> >>>>>>-----Original Message----- >>>>>>From: avt-bounces@ietf.org >>>[mailto:avt-bounces@ietf.org]On Behalf Of >>>>>>Mark Baugher >>>>>>Sent: Wednesday, November 24, 2004 1:33 PM >>>>>>To: David R Oran >>>>>>Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>>>>>avt@ietf.org >>>>>>Subject: Re: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>> >>>>>>On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>>>>> >>>>>>> >>>>>>>On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>>>>> >>>>>>>> >>>>>>>>Michael >>>>>>>> >>>>>>>>I don't see why this would be a problem unless you included SDES >>>>>>>>and >>>>>>>>(SR or >>>>>>>>RR or XR) in the same RTCP packet. SRTP (at least the >>>protocol) is >>>>>>>>apparently able to decided on a packet by packet basis >>>whether to >>>>>>>>encrypt >>>>>>>>RTCP - hopefully SRTP implementations also permit this. >>>>>>>Sure, they can do this. But remember offer-answer. How does a >>>>>>>receiver >>>>>>>communicate such a granular policy to the transmitter? >>>Right now if >>>>>>>can say whether to auth or auth+encrypt RTP, and auth or >>>>>>>auth+encrypt >>>>>>>RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR >>>>>>>etc. >>>>>> >>>>>>Seems to me that this is a problem with SDP security descriptions. >>>>>>That problem might be there because we forgot about the E >>>bit. This >>>>>>seems very messy for the reason you mention above - >>>granularity. I >>>>>>don't think that we want to negotiate the encryption >>>policy for each >>>>>>type SDP message, which is a problem with something like >>>the E bit. >>>>>> >>>>>>Mark >>>>>>> >>>>>>> >>>>>>>>Logically I'd send SDES on its own at the start of a call to >>>>>>>>provide >>>>>>>>some >>>>>>>>user info, but would not send SR/RR/XR until at least >>>8-10 seconds >>>>>>>>into the >>>>>>>>call as I need some time to gather statistics to report. >>>>>>>That's not exactly what the RTP specs say. RTCP timers don't have >>>>>>>this >>>>>>>kind of policy today. In fact, there are porposals on >>>the table to >>>>>>>use >>>>>>>RTCP for early feedback to assess reception quality on >>>some initial >>>>>>>packets - e.g. the RTP-noop proposal. In any event that has no >>>>>>>bearing >>>>>>>on the present discussion. >>>>>>> >>>>>>>>After the >>>>>>>>start-of-call exchange there would appear to be minimal need to >>>>>>>>include >>>>>>>>SDES. I'm sure we could construct some scenarios in >>>which you "may" >>>>>>>>need to >>>>>>>>include SDES with SR/RR/XR however the vast majority of >>>cases would >>>>>>>>either >>>>>>>>need only a single initial exchange or may not need SDES at all. >>>>>>>Any time you change SSRC you potentially need to send SDES. >>>>>>>That said, I still don't see what bearing this has on >>>the discussion >>>>>>>about whether we need the complexity of encrypting some >>>RTCP packets >>>>>>>and not others for a single session. >>>>>>> >>>>>>>It's a tradeoff between extra complexity+less privacy versus >>>>>>>allowing >>>>>>>snoopers to gather RTCP stats. >>>>>>> >>>>>>>Dave. >>>>>>> >>>>>>>>Regards >>>>>>>> >>>>>>>>Alan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>>>>>Sent: Wednesday, November 24, 2004 9:39 AM >>>>>>>>To: Alan Clark >>>>>>>>Cc: Oren Peleg; avt@ietf.org >>>>>>>>Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>>> >>>>>>>> >>>>>>>>At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>>>>>Hi Oren >>>>>>>>> >>>>>>>>>Yes - encryption is intended to provide privacy however this >>>>>>>>>relates >>>>>>>>>primarily to the voice payloads and to information within RTCP >>>>>>>>>that >>>>>>>>>may be >>>>>>>>>associated with individual users (e.g. SDES). >>>>>>>>> >>>>>>>>>SR, RR and XR contain only peformance statistics and >>>there is no >>>>>>>>>privacy >>>>>>>>>consideration that I can think of related to this type of data. >>>>>>>>> >>>>>>>>>The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>>>>>don't >>>>>>>>encrypt >>>>>>>>>RTCP SR/RR/XR >>>>>>>> >>>>>>>>Hi Alan, >>>>>>>> >>>>>>>>I am wondering about implementations utilizing your advise >>>>>>>>"optionally >>>>>>>>encrypt >>>>>>>>RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>>>>> >>>>>>>>Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>>>>>RTCP >>>>>>>>SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>>>>>highly >>>>>>>>related to each other. For example (quote out of RFC 3611): >>>>>>>> >>>>>>>>"XR packets supplement the existing RTCP packets, and may be >>>>>>>>stacked >>>>>>>>with >>>>>>>>other RTCP packets to form compound RTCP packets [9, >>>Section 6]." >>>>>>>> >>>>>>>>Thus, RFC3611 explicitly admits the possibility of (but does not >>>>>>>>mandate) >>>>>>>>the piggybacking all the RTCP-XR block types. >>>>>>>> >>>>>>>>RTCP implementations would have to know the SRTP >>>encryption rules >>>>>>>>to >>>>>>>>make sure they don't perform piggybacking with SDES ... >>>but could >>>>>>>>allow >>>>>>>>(the more bandwidth efficient) piggybacking on the other RTCP-XR >>>>>>>>blocks. >>>>>>>> >>>>>>>>This RTCP/SRTP interaction/dependency seems to add a >>>burden to both >>>>>>>>RTCP and SRTP implementations ... let alone the expressiveness >>>>>>>>required >>>>>>>>to signal your advise in existing SDP/SRTP mechanisms. >>>>>>>> >>>>>>>>Are you aware of any implementations that have actually followed >>>>>>>>your >>>>>>>>advise above? I rather go into this one with our eyes open ... >>>>>>>>developers >>>>>>>>highly dislike this cross-functional entity dependency >>>(RTCP & SRTP >>>>>>>>along >>>>>>>>with expressing it in SDP/SRTP mechanisms). >>>>>>>> >>>>>>>>Regards, >>>>>>>> >>>>>>>>Michael Ramalho >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Regards >>>>>>>>> >>>>>>>>>Alan >>>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>>>>>Sent: Wednesday, November 24, 2004 7:50 AM >>>>>>>>>To: Alan Clark; avt@ietf.org >>>>>>>>>Subject: RE: [AVT] RFC 3711 and RTCP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>Isnt encryption is to prevent monitoring from the first place? >>>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: avt-bounces@ietf.org >>>[mailto:avt-bounces@ietf.org] On Behalf >>>>>>>>>Of >>>>>>>>>Alan Clark >>>>>>>>>Sent: Tuesday, November 23, 2004 5:42 PM >>>>>>>>>To: avt@ietf.org >>>>>>>>>Subject: [AVT] RFC 3711 and RTCP >>>>>>>>> >>>>>>>>> >>>>>>>>>> From the flurry of discussion on RFC3711 it looks as >>>if there is >>>>>>>>>considerable interest in SRTP implementation. I'd >>>like to add a >>>>>>>>>request >>>>>>>>>to >>>>>>>>>SRTP implementors with regard to manageability. >>>>>>>>> >>>>>>>>>RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>>>>>block) >>>>>>>>>contain useful information for network monitoring, and >>>are often >>>>>>>>>used by >>>>>>>>>probes and analyzers to support problem diagnosis. >>>RFC3711 allows >>>>>>>>>the >>>>>>>>>selective encryption of RTCP payloads and hence I >>>would strongly >>>>>>>>>recomment >>>>>>>>>that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>>>>>payloads >>>>>>>>>as >>>>>>>>>this >>>>>>>>>adversely impacts manageability. >>>>>>>>> >>>>>>>>>Regards >>>>>>>>> >>>>>>>>>Alan Clark >>>>>>>>>Telchemy >>>>>>>>> >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Audio/Video Transport Working Group >>>>>>>>>avt@ietf.org >>>>>>>>>https://www1.ietf.org/mailman/listinfo/avt >>>>>>>>> >>>****************************************************************** >>>>>>>>>** >>>>>>>>>* >>>>>>>>>****** >>>>>>>>* >>>>>>>>>******************************** >>>>>>>>>This email and any files transmitted with it are confidential >>>>>>>>>material. >>>>>>>>>They are intended solely for the use of the designated >>>individual >>>>>>>>>or >>>>>>>>>entity >>>>>>>>>to whom they are addressed. >>>>>>>>>If the reader of this message is not the intended recipient, >>>>>>>>>you are hereby notified that any dissemination,use, >>>>>>>>>distribution or copying of this communication is strictly >>>>>>>>>prohibited >>>>>>>>>and >>>>>>>>may >>>>>>>>>be unlawful. >>>>>>>>> >>>>>>>>>If you have received this email in error please notify >>>>>>>>>postmaster@audiocodes.com and permanently delete the e-mail and >>>>>>>>>files. >>>>>>>>> >>>>>>>>> >>>****************************************************************** >>>>>>>>>** >>>>>>>>>* >>>>>>>>>****** >>>>>>>>* >>>>>>>>>******************************* >>>>>>>>> >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Audio/Video Transport Working Group >>>>>>>>>avt@ietf.org >>>>>>>>>https://www1.ietf.org/mailman/listinfo/avt >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Audio/Video Transport Working Group >>>>>>>>avt@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/avt >>>>>>>David R. Oran >>>>>>>Cisco Fellow >>>>>>>Cisco Systems >>>>>>>7 Ladyslipper Lane >>>>>>>Acton, MA 01720 USA >>>>>>>Tel: +1 978 264 2048 >>>>>>>Email: oran@cisco.com >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Audio/Video Transport Working Group >>>>>>>avt@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Audio/Video Transport Working Group >>>>>>avt@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/avt >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 9 06:13:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12866 for ; Thu, 9 Dec 2004 06:13:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMLj-0002ZH-D3 for mmusic-web-archive@ietf.org; Thu, 09 Dec 2004 06:20:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcM76-0001f7-1m; Thu, 09 Dec 2004 06:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcM4G-0000qu-NM for mmusic@megatron.ietf.org; Thu, 09 Dec 2004 06:02:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12182 for ; Thu, 9 Dec 2004 06:02:38 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMBE-0002MN-BK for mmusic@ietf.org; Thu, 09 Dec 2004 06:09:53 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB9B2cvD026373; Thu, 9 Dec 2004 12:02:38 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 12:02:36 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 12:02:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt Date: Thu, 9 Dec 2004 12:02:36 +0100 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD6559AC19@esealmw106.eemea.ericsson.se> Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt Thread-Index: AcTcAnQpg2D62qpFS0m+zOWKCOPenwB24YhA From: "Elisabetta Carrara \(KI/EAB\)" To: "Francois Audet" , X-OriginalArrivalTime: 09 Dec 2004 11:02:36.0771 (UTC) FILETIME=[97841330:01C4DDDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: "Jari Arkko \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Hi Francois, thanks for your comments. See in-line. >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >On Behalf Of Francois Audet >Sent: den 7 december 2004 03:07 >To: 'mmusic@ietf.org' >Cc: 'elisabetta.carrara@ericasson.com'; Mats N=E4slund (KI/EAB);=20 >Jari Arkko (JO/LMF); 'Karl.norrmann@ericsson.com' >Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-12.txt > > >Hi,=20 >I have a 2 comments on=20 >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt- >ext-12.txt.=20 > > >This first comment is for a clarification:=20 >- Section 3.1.2 explains that SIP 488 is used for rejecting a=20 >key management offer.=20 > 488 allows for the inclusion of an SDP indicating the=20 >capabilities of the answerer (the same way an SDP in a 200 OK=20 >sent in an OPTIONS request indicates capabilities). It would be=20 >desireable to explain how this works with kmgmt. I assume that=20 >this is what is meant by wording saying "Further details about=20 >the cause of failure MAY be described in an included message=20 >from the key management protocol." Perhaps a wording like the=20 >following would help:=20 >Further details about the media capabilities of the offerer=20 >MAY be in included in 488 according to normal RFC 3261 rules.=20 >Further details about the cause of the rejection of the key=20 >message itself MAY be described in the key message in the SDP=20 >in the 488, according to the rules of the key management=20 >protocol. The session is then ...=20 >...or something along those lines.=20 >It would also be worthwile to describe how this relates to=20 >MIKEY in particular (i.e, that the MIKEY message itself in=20 >the key-mgmt may have the key management rejection reason).=20 >It would also be helpful to have an Example of a failure case=20 >for SIP 488/MIKEY.=20 Ok.=20 The draft has undergone the AD's review and has been=20 recently resubmitted to IESG. Hence, since what you suggest=20 is wording for better clarification, we will try to take=20 the chance and add this during IESG review process.=20 >=20 >-----------------------=20 >This next comment is concerning a potential issue with SIP=20 >forking. I'm not sure we can fix it in MMUSIC, but I'll state=20 >it anyways.=20 >- There is a somewhat unpleasant side-effect of using a SIP=20 >failure response for rejecting a key management message.=20 >- Suppose that there is a SIP forking proxy forking the offer=20 >(in the INVITE). Let's say the call is forked to A and B. A=20 >is a device for which no user is present at the time (say, an=20 >office phone). Suppose A rejects the call with 401 Unauthorized=20 >because it needs authorization. Suppose the user is at home (B),=20 >but rejects the offer with 488 (because it's using the key=20 >management protocol used for the corporation which is different=20 >than the one used at home). The forking proxy will see both the=20 >401 an the 488, but can only forward one to the offerer.=20 >There is nothing saying which one should be forwarded beyong=20 >the error response that indicates that there could be=20 >retransmission (which applies to both codes in this case).=20 >Worst, in this particular example, if the proxy follows the=20 >rule section 6/RFC 3261, chances are it will pick 401. This=20 >means that you won't be able to call home because you'll never=20 >receive a 488.=20 >- This is a weakness of the forking procedures in SIP, and=20 >perhaps it should be addresses in the SIP working group. yes, that seems the appropriate place. Cheers /E _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 9 12:31:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12654 for ; Thu, 9 Dec 2004 12:31:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSFH-00022G-1H for mmusic-web-archive@ietf.org; Thu, 09 Dec 2004 12:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS1s-00042z-0s; Thu, 09 Dec 2004 12:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRfz-0003Px-Q2 for mmusic@megatron.ietf.org; Thu, 09 Dec 2004 12:02:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10487 for ; Thu, 9 Dec 2004 12:01:57 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRmz-0001QK-Jd for mmusic@ietf.org; Thu, 09 Dec 2004 12:09:14 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id iB9H1VCA021711; Thu, 9 Dec 2004 18:01:37 +0100 (MET) Message-ID: <41B884EA.6040404@tzi.uni-bremen.de> Date: Thu, 09 Dec 2004 18:01:30 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: multipart/mixed; boundary="------------030001050801000605050507" X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Cc: Colin Perkins Subject: [MMUSIC] Draft MMUSIC minutes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded This is a multi-part message in MIME format. --------------030001050801000605050507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, attached are the draft minutes of the MMUSIC meeting in DC. Please review them and send any comments to the list. Thanks, Joerg --------------030001050801000605050507 Content-Type: text/plain; name="61-mmusic-minutes-01.txt" Content-Disposition: inline; filename="61-mmusic-minutes-01.txt" Content-Transfer-Encoding: 7bit Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes 61st IETF meeting, Washington DC, November 2004 Reported by Colin Perkins The MMUSIC working group met once at the 61st IETF in Washington DC. The meeting was attended by some 80 participants. Subjects under discussion included application sharing, ICE, Internet Media Guides, SDP and various SDP extensions (for media loopback, BFCP, labels and connection establishment, security and connectivity preconditions). Introduction and Status Update The meeting started with an introduction and status update from the chairs. The working group has had one RFC published since the last meeting (RFC 3890 on the Session Bandwidth Modifier) and has several drafts are under IESG review: the IMG requirements and framework, SDP source filter extensions and SDP connection oriented media extensions. The draft on Alternative Network Address Types Semantics (ANAT) for the SDP Grouping Framework has been updated in response to IESG comments and is back under review. The SDP key management and security descriptions drafts are being updated in response to review comments from the IESG. Several drafts have been discussed on the mailing list, but are not on the agenda for the meeting. Remote camera control will be discussed in AVT (draft-even-avt-h224-00.txt). RTSP (draft-ietf-mmusic-rfc2326bis-08.txt) and the ANNOUNCE extension (draft-ietf-mmusic-rtsp-announce-00.txt) are in progress, but delayed due to lack of review and editing manpower -- help was solicited. The main connection-oriented media specification (draft-ietf-mmusic-sdp-comedia-09.txt) is under IESG review, the TLS extension to comedia (draft-ietf-mmusic-comedia-tls-02.txt) is under development. Symmetric RTP (draft-wing-mmusic-symmetric-rtprtcp-01.txt) is clearly useful, but the chairs suggested it would be better suited to the AVT working group. The draft on tight membership support in SDP (draft-ekim-mmusic-sdp-membership-01.txt) conflicts with work in XCON, and should be discussed there. The Internet Media Guide (IMG) requirements and framework are complete and under review by the IESG. We have a milestone to revise our charter to accomodate future work in this area. Work to be considered includes: IMG ANNOUNCE via FLUTE, IMG QUERY/RESOLVE via HTTP, IMG SUBSCRIBE/NOTIFY via SIP, and possibly IMG MIME types and URI/URL formats. The chairs, area director, and parties interested in IMGs will work to develop new milestones are charter text to cover this work, and bring it back to the working group for review. ICE: A Methodology for NAT Traversal Jonathan Rosenberg presented ICE (draft-ietf-mmusic-ice-03.txt) outlining the changes since the previous version and discussing open issues. Major changes include: - In the ABNF, rename the "alt" attribute to "candidate" to avoid a conflict with 3GPP specs, remove the remnents of "derived-from", and change the "username" attribute to "user-frag" to more closely reflect its semantics. - The ICE XML schema has been updated to support both IPv4 and IPv6 (the implementation of ICE using ANAT supports this already, this change brings the schema in line with reality). - Added implementation hints on masking allocation latency. - Updated discussion of use of TURN as an address allocation protocol, making it "SHOULD" strength rather than "MUST" strength, to reflect concerns expressed previously. Added text to explain why TURN is a good thing to implement for address allocation. Noted that other allocation protocol can be used. - Clarified that username and password are different for each transport address. - Discussed the misrouting scenario raised by Pete Cordell, where STUN keep-alives can be sent to a third party that isn't expecting them. This is a fundamental issue with the non-uniqueness of IP addresses across NAT-realms, not something that can be solved in ICE. - Removed mid-session checks. STUN now runs until a media packet is received, then you revert to sending only media packets (and using media-specific means, rather than STUN, as a keep-alive). Enforces a clear separation between the STUN server and the media tool. Added a section on application-layer keep-alives. - Add discussion on how to choose a default address. - Now use one local transport address for each usable address. This gives a one-to-one mapping between the local address/port pair and the address that goes in SDP, simplifying the protocol and fixing some bugs, but at the cost of opening more sockets. - Rewrote the description of re-invite handling. Cullen Jennings noted an issue with this, since reverting to an old address can fail if the NAT binding for that address has timed out. There may be a need to redo the negotiation with a new username and password. - TURN has been promoted to a normative reference, however Cullen Jennings is worried that TURN is late and a normative reference may delay ICE. It was agreed to revert this to a reference to "some media relay protocol" using TURN as an example of a protocol with the required properties, to avoid this potential delay. Considerable discussion ensued, covering a number of these issues. - Made RTCP information optional in SDP, since many devices don't implement RTCP. Magnus Westerlund suggested it is necessary to set the RTCP bandwidth parameter to zero, in addition to avoiding the ICE check, to inform the other end-point that RTCP isn't used. Jonathan agreed that setting the RTCP bandwidth to zero would be a good thing, but that implementations didn't do it. Rohan Mahy noted that we can say "if you don't do RTCP, you MUST do this with the signalling". After much discussion, the consensus seemed to be to make inclusion of the RTCP address/port optional, but mandate that implementations MUST include a "b=" field of zero if RTCP is not used. - Rewrote the security and IANA considerations, and made a number of editorial fixes. There are a number of open issues relating to mid-session checks, use of STUN vs. STUN-over-RTP, forcing symmetry, and local-to-derived mapping. Mid-session STUN checks serve the purpose of keeping alive NAT bindings, detecting interface and NAT failures, and probing for bandwidth. If they are included, we need to specify frequency of transmission, a definition of failure and protection against flapping. There are two choices for a mid-session keepalive: STUN based and application based. STUN based mid- session checks have the advantage of being codec/transport independent, but require applications to demultiplex STUN and media data, make it hard to specify timers and only provide a partial failure detection/recovery solution. Application based mid-session checks provide a clean handoff between STUN and the media, separating problems and limiting the scope of ICE, and move timers and failure detection to the application. Jonathan proposed to keep with the solution in the current, with STUN being used for the initial keepalive check, and application specific solutions being used after the initial check. He noted that his slide saying "Recommentation: keep stun keepalives" is wrong. Joerg Ott and Dave Oran agreed with Jonathan. The next open issue was the use of STUN vs. STUN-over-RTP for initial connectivity checks (i.e. the 1st RTP packet's payload data is a STUN packet). The disadvantages of using STUN over RTP are that it's ugly, the request/response nature of STUN isn't well matched with RTP semantics, the RTP timestamp would jump since the STUN packets aren't really media, it doesn't work with SRTP, and it makes ICE specific to RTP. The only advantage is that is avoids a STUN/RTP demultiplex -- although that comes at the cost of embedding STUN into RTP. Dave Oran agreed with all these, provided this is done for RTCP. For RTCP, the issues are not as bad since RTCP APP packets can be used. Magnus Westerlund noted that there are other protocols and making ICE RTP specific is a mistake. The consensus of the room was that STUN-over-RTP is a mistake, especially since we now have a clean handoff between STUN and the media. Regarding forced symmetry, the problem is that the current algorithm can result in you sending on a different port than that on which you receive media. This doesn't work if one is depending on application-level keep alives. The suggested fix is MUST send on the port on which you last received a valid RTP packet. Magnus Westerlund noted that there's a potential for flapping, but Jonathan countered that the protocol will settle to a stable state, and there are further rules to ensure one SHOULD use the highest priority address on which you got a STUN request. Regarding local to derived mapping, previous versions of the draft allowed a single socket to be used for it's local address, and as a source of STUN and TURN requests used to determine derived addresses. This caused confusion with username-to-address mapping for the STUN and TURN requests, made it hard to determine when to stop the STUN server, and made it difficult to assess which address was used. The latest version of the draft uses distinct ports for the local address, and to run STUN and TURN to derive addresses. This avoids all the multiplexing issues, but at the expense of additional local port usage. Jonathan is worried about the port footprint, and is considering going back to the multiplexing solution (one local address for each derived address), and defining appropriate timeouts for each protocol. Rohan Mahy noted that the folks that have port issues will likely be those who have problem multiplexing, so this may not solve the problem. Dan Wing suggested that the problem is that we're lacking a message to say "STUN packet received" so why not create a stun message to say exactly that? Jonathan considered that, but thought that while it helps you turn off the STUN listener, it doesn't solve the demultiplexing issues. Cullen Jennings asked why we can't do both? The choice of one-to-one or many-to-one mappings between local and derived addresses is a local implementation choice, and which doesn't affect remote clients. Why not document the issue, and let the implementor choose? Jonathan agreed that this is a good way forward. Magnus Westerlund noted that ICE could generate a lot of packets, and may cause congestion. It may be better to have some initial delay and to send messages in priority order. Jonathan agreed that this could reduce the amount of data sent, but increased the post-dial delay (which is a hard requirment for some applications). Joerg Ott noted that it's unlikely there are many addresses, so this may not be such a problem: maybe just add a warning note? Jonathan agreed that a discussion of the issue would be appropriate. Magnus also worried about switching media between different addresses; we should highlight the potential congestion control issue when changing connection addresses. Jonathan committed to revising draft immediately after the meeting, to aim for working group last call before Christmas. Internet Media Guides Yuji Nomura discussed Internet Media Guides. The IMG requirements and framework are with the IESG for review, so it is now time to identify the specific protocol components that need to be developed. The main items are an IMG transfer envelope, a multicast delivery method, and a subscribe/notify delivery method. The groundwork for the unicast subscribe/notify mechanism is defined in draft-nomura-mmusic-img-notify-00.txt. Yuji noted that using HTTP doesn't meet the requirements, so the working assumption is that SIP events will be used for subscribe/notify, and there is a need to define an event package for IMG. Multicast delivery will be via FLUTE: an intial draft defining this has previously been submitted, and will be updated shortly. In addition to the transport protocols, and envelope is needed for the data. An initial proposal (draft-walsh-mmusic-img-envelope-01.txt) exists for this and provide a common minimal set of information to manage transfer of IMG data, independent of the transport protocol. The working assumption here is to use an XML format. Open issues include the need to define an IMG URI (e.g. img://...) and naming IMG data for encapsulation ("application/envelope+xml"?). It will also be necessary to define versioning and delta descriptions for the IMG data, to support partial transmission. Henning Schulzrinne asked if the IMG URI is intended to identify the content or the transport, and wondered how it should be used? There was some confusion on this point, and it isn't clear how to translate from the URI to the retrieval mechanism. Clarifiation is needed. Application Sharing Henning Schulzrinne discussed draft-schulzrinne-mmusic-sharing-00.txt on requirements for application sharing. This is speculative new work, and it's not clear if it belongs in MMUSIC. Our conferencing architecture is deficient in support for shared applications, and Henning has considered how this can be resolved without reinventing T.120. The presentation and draft outline the problem space and the requirements. Rohan Mahy expressed concern that the scope being addressed here is significantly larger than he had imagined. We may want to solve the problem for named categories of application, splitting the problem space rather than "trying to boil the ocean". Dave Oran, Jonathan Rosenberg and Roni Even and also expressed similar concern regarding the scope of the work, compatibility with other systems, the form of the data to be shared, etc. Henning noted that he's raising possible requirements, not suggesting that we'll solve them all immediately. Steve Casner noted that we already have limited RTP payload formats for pointers and text events, which may feed into this work. Joerg Ott concluded by noted that this is an intersting problem, and noted that while the negotiation of application sharing sessions is clearly in scope for MMUSIC, the application sharing protocol itself isn't. There doesn't seem to be a natural home for this work in the IETF, although we can think about it here for now. SDP Colin Perkins outlined the changes to draft-ietf-mmusic-sdp-new-21.txt since the last meeting (see slides for details). There are open issues regarding support for internationalized DNS, layered coding, direction attributes and the placement of the spec in context. Internationalized DNS names did not exist when the original SDP was written, so the draft doesn't indicate how they should be represented. Advice was solicited from the working group and Bernie Hoeneisen gave the suggestion that internationalized DNS names should be conveyed in the ASCII Compatible Encoding (ACE) form defined in RFC 3490, rather than in UTF-8 or some other encoding. This requires no changes to SDP, other than to note that this form should be used. Regarding layered coding, the issues are that allocation of consecutive multicast addresses is problematic, and that the "a=rtcp:" attribute is not fully specified for layered encoding. Colin suggested that, since this part of the spec is not widely implemented, it should be left as-is for now, and updated if layered multicast transport becomes popular. No comments were received. There was a suggestion that interactions between the direction attributes ("a=recvonly", etc.) and the offer/answer spec should be documented, and offer/answer referenced. More generally, is there need to include more context on how SDP is used with, for example, SIP? Jonathan Rosenberg and Keith Drage suggested that these interactions are defined in other drafts, so there's no need to add anything to the SDP spec. SDP Extension for Media Loopback Kaynam Hedayat discussed draft-hedayat-media-loopback-01.txt. The goal of this draft is to enable SIP endpoint to initiate calls with media loopback. It introduces two SDP media attributes, giving the type and mode of the loopback and is based on the offer/answer model. Colin Perkins and Dave Oran were uncomfortable with the requirement that endpoints MUST support RTCP-XR, and suggested that support for RTCP-XR be OPTIONAL. The loopback attribute is more general than voice over IP applications, so there is no way a particular subset of RTCP-XR support can be mandated. Magnus Westerlund expressed concern that the security aspects of this new attribute haven't been fully considered, and that it may introduce potential packet bombing attacks. This issue needs to be documented. The consensus of the room was that this a good idea, and should be adopted as an MMUSIC work item. SDP Extension for BFCP Gonzalo Camarillo presented (draft-camarillo-mmusic-sdp-bfcp-00.txt) on the SDP extensions needed to support the XCON binary floor control protocol. BFCP is defined under the "application/bfcp" media type and runs over TCP. It fits into SDP as a transport protocol with connection establishment is handled by the comedia framework. The "k=" line can be used to convey the shared secret needed by BFCP, and attributes are defined to convey the confid and userid. Mapping between floor IDs and streams can be done using the SDP label attribute. There is an open issue regarding the need for a nonce attribute, which will be discussed in XCON. The consensus of the room was to accept this as an MMUSIC work item. SDP Label Attribute Gonzalo Camarillo presented (draft-ietf-mmusic-sdp-media-label-00.txt) on the SDP label attribute. The main issue at the last meeting was why label media streams, rather than referring to the n'th media stream. It has been clarified that this is so static documents can be created that refer to specific media streams within future SDP files, without having to revise those static documents if the type or order of the media in those future sessions changes. The authors asked for the draft to go to working group last call. Colin Perkins raised an issue that the label is defined as "any octet string" but needs to be restricted to octet strings that can be represented in SDP (i.e. printable ASCII). The working group last call will be issued after the meeting, with this comment being fixed as an editorial clarification after the last call. SDP Connection Establishment Precondition Gonzalo Camarillo presented (draft-ietf-mmusic-connection-precon-00.txt) on SDP connection establishment preconditions, briefly noting that the SIP working group is performing an expert review of the draft. SDP Security Precondition Flemming Andreasen gave an overview of the SDP security precondition draft (draft-andreasen-mmusic-securityprecondition-02.txt). The problem that it solves is when an offer includes several security descriptions from which the answerer picks one and sends secure media. The media can start to arrive before the answer, but cannot be be decoded since the offerer doesn't know which security parameters were chosen. Hence a new precondition is defined to delay completion of the call until all parties have agred on the security parameters. Changes in this version are to clarify the definition of "send" and "recv" security preconditions, add more detail in the example flow, and add security considerations. This is needed by SIP, and there are no known open issues. Colin Perkins asked that an example be included using the kgmnt-ext form of SDP signalling, in addition to the sdescriptions examples, but otherwise agreed that the draft was in good shape. The authors were requested to make this change, and submit the draft as a working group draft, then a working group last call could start. SDP Connectivity Precondition Flemming Andreasen also presented the SDP connectivity preconditions (draft-andreasen-mmusic-connectivityprecondition-01.txt). This draft defines a precondition to ensure there is media stream connectivity between offerer and answerer prior to proceeding with session establishement. It doesn't mandate a particular mechanism to verify connectivity. Changes in this version are to clarify the definition of "send" and "recv" preconditions, add more detail in the example flow, and add security considerations. Open issues include adding an explanation of the relationship between this and ICE, and explaining how it will interact with SIP forking. Colin Perkins asked that this draft be clearer on the difference between it and the connection precondition, in particular to be careful about the precondition names (i.e. "con" vs. "conn"). Paul Kyzivat noted that we have many preconditions, and worried about use cases and feature interaction. It may be appropriate to consider documenting possible interactions? Henning Schulzrinne raised a general concern that the precondition framework may be covered by IPR? It was agreed that this draft should become an MMUSIC work item. -- + -- --------------030001050801000605050507 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --------------030001050801000605050507-- From mmusic-bounces@ietf.org Fri Dec 10 06:58:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07748 for ; Fri, 10 Dec 2004 06:58:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcjXB-00032z-7D for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 07:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcjHS-0000PX-0k; Fri, 10 Dec 2004 06:49:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcjFu-0008NB-1q for mmusic@megatron.ietf.org; Fri, 10 Dec 2004 06:48:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07193 for ; Fri, 10 Dec 2004 06:48:11 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcjN4-0002pd-MM for mmusic@ietf.org; Fri, 10 Dec 2004 06:55:39 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:61507) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CcjFM-0003vF-TG; Fri, 10 Dec 2004 11:47:40 +0000 In-Reply-To: <380024A2-48B2-11D9-8183-000A95DC10F2@cisco.com> References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> <41B5CAED.8000200@cisco.com> <77AB3B58-4870-11D9-9AFB-000A957FC5F2@csperkins.org> <380024A2-48B2-11D9-8183-000A95DC10F2@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48D9F414-4AA1-11D9-8CD9-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Fri, 10 Dec 2004 11:47:35 +0000 To: Mark Baugher X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Magnus Westerlund , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Mark, On 8 Dec 2004, at 00:43, Mark Baugher wrote: > Do we know of any other applications besides RFC 3611 that might > need to selectively encrypt SRTCP packets? I don't, but I can imagine future RTCP extensions which might require this feature (and applications that might want to encrypt various subsets of the RFC 3611 data). > I am okay with putting this requirement aside pending a separate > document. But before someone goes to the trouble of writing the new > draft, it might be good to consider if it's needed or not. Even if RTCP XR is the only driver, it might be appropriate to make that a separate short draft. There's been enough discussion on the list that I'm not entirely comfortable slotting it into sdescriptions this late in the process. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 11:27:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27250 for ; Fri, 10 Dec 2004 11:27:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcnjG-0008KM-Gt for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 11:34:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnRk-0003gQ-Hg; Fri, 10 Dec 2004 11:16:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnFb-0001iR-J5 for mmusic@megatron.ietf.org; Fri, 10 Dec 2004 11:04:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25961 for ; Fri, 10 Dec 2004 11:04:09 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcnMo-0007wP-1Q for mmusic@ietf.org; Fri, 10 Dec 2004 11:11:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 10 Dec 2004 08:03:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBAG3Wm4016832; Fri, 10 Dec 2004 08:03:32 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn5-1262.cisco.com [10.21.92.238]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBAG2X59016668; Fri, 10 Dec 2004 08:02:33 -0800 In-Reply-To: <48D9F414-4AA1-11D9-8CD9-000A957FC5F2@csperkins.org> References: <17EDF5FC-47DF-11D9-BD9F-000A95DC10F2@cisco.com> <41B59C43.4020401@ericsson.com> <41B5CAED.8000200@cisco.com> <77AB3B58-4870-11D9-9AFB-000A957FC5F2@csperkins.org> <380024A2-48B2-11D9-8183-000A95DC10F2@cisco.com> <48D9F414-4AA1-11D9-8CD9-000A957FC5F2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Fri, 10 Dec 2004 08:02:32 -0800 To: Colin Perkins X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102694553.817751"; x:"432200"; a:"rsa-sha1"; b:"nofws:1088"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dtyVqxLR6N47Ki7GuBn54M6fKnlPmIbyJUQIGYc08dppTjokI6f0x3VExavHA" "nXPcyKFStp5gYUoWKQspfMnasNECoCgR7jZMfFQz8/egpP7dNIocCujis4kld" "qJCIBkCgdudqfyBh26+4KJt+eEPzrLvTXCTTMgj966MNUXGxs="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Fri, 10 Dec 2004 08:02:32 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Colin, On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > Mark, > > On 8 Dec 2004, at 00:43, Mark Baugher wrote: >> Do we know of any other applications besides RFC 3611 that might >> need to selectively encrypt SRTCP packets? > > I don't, but I can imagine future RTCP extensions which might require > this feature (and applications that might want to encrypt various > subsets of the RFC 3611 data). I don't see a large downside in waiting until we see such extensions for real. > >> I am okay with putting this requirement aside pending a separate >> document. But before someone goes to the trouble of writing the new >> draft, it might be good to consider if it's needed or not. > > Even if RTCP XR is the only driver, it might be appropriate to make > that a separate short draft. There's been enough discussion on the > list that I'm not entirely comfortable slotting it into sdescriptions > this late in the process. Ok. If there are no objections, I'll generate a new version and post it early next week. Mark > > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 16:33:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27901 for ; Fri, 10 Dec 2004 16:33:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcsVE-0000jz-7W for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 16:40:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsBr-0005C0-Tl; Fri, 10 Dec 2004 16:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccrx5-0000nW-4J for mmusic@megatron.ietf.org; Fri, 10 Dec 2004 16:05:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22109 for ; Fri, 10 Dec 2004 16:05:21 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccs4H-0007Di-T6 for mmusic@ietf.org; Fri, 10 Dec 2004 16:12:53 -0500 Received: from [64.238.103.215] (port=1248 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1Ccrwv-0007hS-95; Fri, 10 Dec 2004 16:05:13 -0500 From: "Alan Clark" To: "Mark Baugher" , "Colin Perkins" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Fri, 10 Dec 2004 16:05:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Mark, Colin Where does this leave the issue? Some sizeable network and telecom equipment vendors are in the process of integrating support for the RFC3611 VoIP metrics, due in a large part to service provider and enterprise customer demand. The demand exists because customers need to manage their VoIP deployments, hence they see RFC3611 as a key element in their management infrastructure. The accessibility of RFC3611 VoIP metrics is therefore an issue of concern today. If it's proposed to deal with this in a separate draft then what is the expected timeframe - going through the regular I-D, WG draft, IESG process seem to take a year or so. Is there some mechanism by which this can be accelerated? If the proposal is to address the issue in the draft currently being finalized then my apologies if this has caused any last minute delays however the issue is important enough to warrant this (at least in my view). We hoped that the comment in the security considerations section of RFC3611 was strong enough to address the issue however it appears not to have been. Regards Alan -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]On Behalf Of Mark Baugher Sent: Friday, December 10, 2004 11:03 AM To: Colin Perkins Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Colin, On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > Mark, > > On 8 Dec 2004, at 00:43, Mark Baugher wrote: >> Do we know of any other applications besides RFC 3611 that might >> need to selectively encrypt SRTCP packets? > > I don't, but I can imagine future RTCP extensions which might require > this feature (and applications that might want to encrypt various > subsets of the RFC 3611 data). I don't see a large downside in waiting until we see such extensions for real. > >> I am okay with putting this requirement aside pending a separate >> document. But before someone goes to the trouble of writing the new >> draft, it might be good to consider if it's needed or not. > > Even if RTCP XR is the only driver, it might be appropriate to make > that a separate short draft. There's been enough discussion on the > list that I'm not entirely comfortable slotting it into sdescriptions > this late in the process. Ok. If there are no objections, I'll generate a new version and post it early next week. Mark > > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 16:55:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01631 for ; Fri, 10 Dec 2004 16:55:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcsqY-0001RN-VW for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 17:02:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsZN-0004lN-Fv; Fri, 10 Dec 2004 16:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsVu-0003UZ-Mn; Fri, 10 Dec 2004 16:41:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00688; Fri, 10 Dec 2004 16:41:20 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcsdA-00016w-QU; Fri, 10 Dec 2004 16:48:53 -0500 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBALfDBN042881 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Dec 2004 15:41:14 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Fri, 10 Dec 2004 15:41:12 -0600 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org Subject: [MMUSIC] Re: [Simple] MSRP: SDP usage concern X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit I really need to get closure on this, so I'd appreciate people agreeing or disagreeing. I have had off-list correspondence indicating both positions. In summary: In favor of the change, I had a comment to the effect that changing SDP semantics to ignore the C line and the port field on the M line really changes it to something that is no longer SDP, and that such deviations are in general bad for interop. In favor of leaving things as currently specified, I had two comments that decomposing URLs into the C and M lines is ugly, and that having a different mechanism to communicate endpoint addresses vs relay addresses is really ugly. So, do people agree with one or the other position? Something completely different? (Hopefully the people who sent off-list correspondence will reply on-list if they think I mischaracterized either position. Actually, I hope they will repost on-list even if they like my summaries) I have so far avoided interjecting my personal opinion so that I could do a fair summary. But, I actually tend to agree with the leave-things-as-specified position. While I am sensitive to the issue of deviating from the spirit of SDP, I don't really buy the interoperability argument. The currently defined usage _does_ put "msrp" in the M line--so only consumers that understand what that means will be able to act on it. I assume that any endpoint that understands what "msrp" means will also understand how to use the "path" attribute. The place that interoperability might suffer is if any non-endpoint needs to interpret things--which is generally not a goal. I guess can also see debug or monitoring tools who don't know about MSRP getting things wrong. My biggest technical objection is that using a different mechanism for determining where to connect depending on whether you are connecting peer to peer or through a relay, increases the chances of implementors getting things wrong. And I cannot personally think of a way to handle relay addresses that is more in the spirit of SDP than what we currently have. But in any case, I will be happy to document consensus, even if it disagrees with my position. But we need to close on it asap. Thanks! Ben. On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote: > I sent the attached to the SIMPLE list last week. I am reposting it to > both the SIMPLE and MMUSIC lists, as the discussion is of interest to > both groups. If you already responded to this on the SIMPLE list or in > private, it would be helpful if you can re-post your response to this > thread, so everyone sees the whole discussion. > > Thanks! > > Ben. > > ----------------------------------------------------------------------- > ----------------------------------------- > > > In the DC meeting, we discussed that MSRP's SDP usage should be > reviewed in MMUSIC, or at least by people who are more expert in SDP. > Colin Perkins and Joerg Ott looked at this, and suggested a change. > (Many thanks to them for taking the time, and I hope they will jump in > and correct me if I mischaracterize anything.) > > The upshot of the proposal is that the fact that MSRP ignores the > address in the sdp c-line, and the port and proto fields in the > m-line. Instead, MSRP gets all of this from the first URL in the path > a-line attribute. This deviates from the traditional usage in SDP, and > causes confusion. > > The proposed change is that the destination URL be broken into the > appropriate parts and encoded into the c-line and m-line. For example > (leaving out lines that don't change) > > c=IN IP4 alice.example.com > m=message 9 msrp * > a=path:msrp://a.example.com:7394/2s93i;tcp > > would become: > > c=IN IP4 a.example.com > m=message 7394 msrp/tcp * > a=session:2s93i > > The change would only be made for the destination URL. URLs for any > relays would be expressed the same way they are now. > > The advantage of this approach is that it more closely follows the > spirit of SDP. This will be easier to understand for people who > already know SDP. Existing SDP code could be reused more effectively. > > The disadvantage of the proposed change is, it means the way an MSRP > client determines the destination URL would be different depending on > whether the URL represented the final destination or a relay. Instead > of the current approach of simply copying the path attribute value > into the To-Path header in MSRP messages, a client would copy the > path header value if exists, reconstitute the destination URL from the > m and c lines, and append the destination URL to the path header > value. > > So, what do people think? (I note that we actually did something > similar to this before we added the "path" attribute. ) > > > Thanks! > > Ben. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 17:39:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04613 for ; Fri, 10 Dec 2004 17:39:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CctXi-0002KU-Kk for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 17:47:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CctMg-0008I4-1A; Fri, 10 Dec 2004 17:35:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CctIe-0007SQ-3c; Fri, 10 Dec 2004 17:31:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04169; Fri, 10 Dec 2004 17:31:41 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CctPu-0002B9-Vz; Fri, 10 Dec 2004 17:39:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 Dec 2004 17:31:14 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBAMVAQ6027257; Fri, 10 Dec 2004 17:31:10 -0500 (EST) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANQ09484; Fri, 10 Dec 2004 17:31:07 -0500 (EST) Message-ID: <41BA23AB.7010106@cisco.com> Date: Fri, 10 Dec 2004 17:31:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org Subject: [MMUSIC] Re: [Simple] MSRP: SDP usage concern X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Ben, I agree with what you say below, and have no more to add now. Paul Ben Campbell wrote: > I really need to get closure on this, so I'd appreciate people agreeing > or disagreeing. > > I have had off-list correspondence indicating both positions. In summary: > > In favor of the change, I had a comment to the effect that changing SDP > semantics to ignore the C line and the port field on the M line really > changes it to something that is no longer SDP, and that such deviations > are in general bad for interop. > > In favor of leaving things as currently specified, I had two comments > that decomposing URLs into the C and M lines is ugly, and that having a > different mechanism to communicate endpoint addresses vs relay > addresses is really ugly. > > So, do people agree with one or the other position? Something > completely different? (Hopefully the people who sent off-list > correspondence will reply on-list if they think I mischaracterized > either position. Actually, I hope they will repost on-list even if they > like my summaries) > > I have so far avoided interjecting my personal opinion so that I could > do a fair summary. But, I actually tend to agree with the > leave-things-as-specified position. > > While I am sensitive to the issue of deviating from the spirit of SDP, > I don't really buy the interoperability argument. The currently defined > usage _does_ put "msrp" in the M line--so only consumers that > understand what that means will be able to act on it. I assume that any > endpoint that understands what "msrp" means will also understand how to > use the "path" attribute. > > The place that interoperability might suffer is if any non-endpoint > needs to interpret things--which is generally not a goal. I guess can > also see debug or monitoring tools who don't know about MSRP getting > things wrong. > > My biggest technical objection is that using a different mechanism for > determining where to connect depending on whether you are connecting > peer to peer or through a relay, increases the chances of implementors > getting things wrong. And I cannot personally think of a way to handle > relay addresses that is more in the spirit of SDP than what we > currently have. > > But in any case, I will be happy to document consensus, even if it > disagrees with my position. But we need to close on it asap. > > Thanks! > > Ben. > > On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote: > >> I sent the attached to the SIMPLE list last week. I am reposting it >> to both the SIMPLE and MMUSIC lists, as the discussion is of interest >> to both groups. If you already responded to this on the SIMPLE list >> or in private, it would be helpful if you can re-post your response >> to this thread, so everyone sees the whole discussion. >> >> Thanks! >> >> Ben. >> >> ----------------------------------------------------------------------- >> ----------------------------------------- >> >> >> In the DC meeting, we discussed that MSRP's SDP usage should be >> reviewed in MMUSIC, or at least by people who are more expert in >> SDP. Colin Perkins and Joerg Ott looked at this, and suggested a >> change. (Many thanks to them for taking the time, and I hope they >> will jump in and correct me if I mischaracterize anything.) >> >> The upshot of the proposal is that the fact that MSRP ignores the >> address in the sdp c-line, and the port and proto fields in the >> m-line. Instead, MSRP gets all of this from the first URL in the path >> a-line attribute. This deviates from the traditional usage in SDP, >> and causes confusion. >> >> The proposed change is that the destination URL be broken into the >> appropriate parts and encoded into the c-line and m-line. For example >> (leaving out lines that don't change) >> >> c=IN IP4 alice.example.com >> m=message 9 msrp * >> a=path:msrp://a.example.com:7394/2s93i;tcp >> >> would become: >> >> c=IN IP4 a.example.com >> m=message 7394 msrp/tcp * >> a=session:2s93i >> >> The change would only be made for the destination URL. URLs for any >> relays would be expressed the same way they are now. >> >> The advantage of this approach is that it more closely follows the >> spirit of SDP. This will be easier to understand for people who >> already know SDP. Existing SDP code could be reused more effectively. >> >> The disadvantage of the proposed change is, it means the way an MSRP >> client determines the destination URL would be different depending on >> whether the URL represented the final destination or a relay. Instead >> of the current approach of simply copying the path attribute value >> into the To-Path header in MSRP messages, a client would copy the >> path header value if exists, reconstitute the destination URL from >> the m and c lines, and append the destination URL to the path header >> value. >> >> So, what do people think? (I note that we actually did something >> similar to this before we added the "path" attribute. ) >> >> >> Thanks! >> >> Ben. >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 18:47:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11612 for ; Fri, 10 Dec 2004 18:47:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcubF-0003i0-LO for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 18:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuOV-0006Qm-A1; Fri, 10 Dec 2004 18:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuNA-0005z5-31 for mmusic@megatron.ietf.org; Fri, 10 Dec 2004 18:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11222 for ; Fri, 10 Dec 2004 18:40:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcuUR-0003Zh-IJ for mmusic@ietf.org; Fri, 10 Dec 2004 18:47:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2004 15:43:13 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBANe35M004915; Fri, 10 Dec 2004 15:40:03 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn5-1262.cisco.com [10.21.92.238]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBANcwic020047; Fri, 10 Dec 2004 15:38:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Fri, 10 Dec 2004 15:38:58 -0800 To: "Alan Clark" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102721939.199028"; x:"432200"; a:"rsa-sha1"; b:"nofws:3278"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PNyMHkg1e5lE4KsMkFVF3CMYIgXLUr+br4MMblC41/VrIKsW7l13uQzsUUBsV" "3ENb6uzfNtKByXMwE/ganxwm6JTGtDD4OnuHfvSttvq6N+BoW8JYgFyKqStrX" "I4i1QwMrvifhjeiLq0oSZftz289j4gBzG0u+e2GWAphQameBA="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP"; c:"Date: Fri, 10 Dec 2004 15:38:58 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Alan, I'm finishing sdescriptions-08 without any change to accommodate XR packets to use the E bit. I don't yet know who is going to do the work on the I-D that Colin suggested to address Magnus' issues with E-bit usage. As it stands now, UNENCRYPTED_SRTCP will need to be signaled in order to keep XR packets in the clear. Mark On Dec 10, 2004, at 1:05 PM, Alan Clark wrote: > Mark, Colin > > Where does this leave the issue? Some sizeable network and telecom > equipment vendors are in the process of integrating support for the > RFC3611 > VoIP metrics, due in a large part to service provider and enterprise > customer demand. The demand exists because customers need to manage > their > VoIP deployments, hence they see RFC3611 as a key element in their > management infrastructure. The accessibility of RFC3611 VoIP metrics > is > therefore an issue of concern today. > > If it's proposed to deal with this in a separate draft then what is the > expected timeframe - going through the regular I-D, WG draft, IESG > process > seem to take a year or so. Is there some mechanism by which this can be > accelerated? > > If the proposal is to address the issue in the draft currently being > finalized then my apologies if this has caused any last minute delays > however the issue is important enough to warrant this (at least in my > view). > We hoped that the comment in the security considerations section of > RFC3611 > was strong enough to address the issue however it appears not to have > been. > > Regards > > Alan > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]On Behalf > Of Mark Baugher > Sent: Friday, December 10, 2004 11:03 AM > To: Colin Perkins > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > Colin, > > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > >> Mark, >> >> On 8 Dec 2004, at 00:43, Mark Baugher wrote: >>> Do we know of any other applications besides RFC 3611 that might >>> need to selectively encrypt SRTCP packets? >> >> I don't, but I can imagine future RTCP extensions which might require >> this feature (and applications that might want to encrypt various >> subsets of the RFC 3611 data). > > I don't see a large downside in waiting until we see such extensions > for real. >> >>> I am okay with putting this requirement aside pending a separate >>> document. But before someone goes to the trouble of writing the new >>> draft, it might be good to consider if it's needed or not. >> >> Even if RTCP XR is the only driver, it might be appropriate to make >> that a separate short draft. There's been enough discussion on the >> list that I'm not entirely comfortable slotting it into sdescriptions >> this late in the process. > > Ok. If there are no objections, I'll generate a new version and post > it early next week. > > Mark >> >> Colin >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 10 22:17:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26691 for ; Fri, 10 Dec 2004 22:17:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccxt1-0007sR-0q for mmusic-web-archive@ietf.org; Fri, 10 Dec 2004 22:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcxjD-0004v4-Ql; Fri, 10 Dec 2004 22:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccxde-0003bg-RY for mmusic@megatron.ietf.org; Fri, 10 Dec 2004 22:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26068 for ; Fri, 10 Dec 2004 22:09:40 -0500 (EST) Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccxky-0007jM-1H for mmusic@ietf.org; Fri, 10 Dec 2004 22:17:16 -0500 Received: from [195.14.218.218] (helo=[195.14.218.218]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1Ccxd4-000725-5o for mmusic@ietf.org; Sat, 11 Dec 2004 04:09:06 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0310F5F4-4B22-11D9-9C4A-0030658FAAAC@let.de> Content-Transfer-Encoding: 7bit From: Marc Manthey Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sat, 11 Dec 2004 04:09:03 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.619) X-Relay-User: marc@let.de X-Spam-Score: 1.2 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit ...This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). a protocol that protocols a protocol.... *SCNR* leave it like it is;) cheers marc -- "Fragmentation is like classful addressing , an interesting early architectural error that shows how much experimentation was going on while IP was being designed." http://www.multicasttech.com/status/msdp.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 11 07:35:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18888 for ; Sat, 11 Dec 2004 07:35:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd6ai-0001YZ-3H for mmusic-web-archive@ietf.org; Sat, 11 Dec 2004 07:43:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6PS-000062-KH; Sat, 11 Dec 2004 07:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6I8-0006qG-80 for mmusic@megatron.ietf.org; Sat, 11 Dec 2004 07:24:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18196 for ; Sat, 11 Dec 2004 07:24:02 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd6PV-0001K8-OS for mmusic@ietf.org; Sat, 11 Dec 2004 07:31:43 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60378 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Cd6Hb-0008Ay-OB; Sat, 11 Dec 2004 12:23:31 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7208A67C-4B6F-11D9-8877-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sat, 11 Dec 2004 12:23:21 +0000 To: "Alan Clark" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Mark Baugher X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Alan, On 10 Dec 2004, at 21:05, Alan Clark wrote: > Where does this leave the issue? Some sizeable network and telecom > equipment vendors are in the process of integrating support for the > RFC3611 > VoIP metrics, due in a large part to service provider and enterprise > customer demand. The demand exists because customers need to manage > their > VoIP deployments, hence they see RFC3611 as a key element in their > management infrastructure. The accessibility of RFC3611 VoIP metrics > is > therefore an issue of concern today. Understood. I note that the sdescriptions work is also eagerly awaited by the industry. > If it's proposed to deal with this in a separate draft then what is the > expected timeframe - going through the regular I-D, WG draft, IESG > process > seem to take a year or so. Is there some mechanism by which this can be > accelerated? We have little influence on the IESG process, but the working group doesn't have to take a long time. If this issue is straightforward, we should be able to document a solution that can be progressed to the IESG very quickly. Would you be willing to write such a draft? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 11 07:37:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19046 for ; Sat, 11 Dec 2004 07:37:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd6ch-0001bt-63 for mmusic-web-archive@ietf.org; Sat, 11 Dec 2004 07:45:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6Pw-00009e-9q; Sat, 11 Dec 2004 07:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6Oj-0008Lm-4w; Sat, 11 Dec 2004 07:30:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18592; Sat, 11 Dec 2004 07:30:51 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd6W6-0001SZ-N4; Sat, 11 Dec 2004 07:38:32 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60428 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Cd6OC-0000bm-Kj; Sat, 11 Dec 2004 12:30:20 +0000 In-Reply-To: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Sat, 11 Dec 2004 12:30:12 +0000 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On 10 Dec 2004, at 21:41, Ben Campbell wrote: > I really need to get closure on this, so I'd appreciate people > agreeing or disagreeing. > > I have had off-list correspondence indicating both positions. In > summary: > > In favor of the change, I had a comment to the effect that changing > SDP semantics to ignore the C line and the port field on the M line > really changes it to something that is no longer SDP, and that such > deviations are in general bad for interop. > > In favor of leaving things as currently specified, I had two comments > that decomposing URLs into the C and M lines is ugly, and that having > a different mechanism to communicate endpoint addresses vs relay > addresses is really ugly. > > So, do people agree with one or the other position? Decomposing the URL into the "c=" and "m=" lines is very ugly. Unfortunately, that ugliness is required if you want to use SDP. This is why the SDPng work was started, to try to move to something less horrible... Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 11 08:04:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20433 for ; Sat, 11 Dec 2004 08:04:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd72m-0002CD-8Z for mmusic-web-archive@ietf.org; Sat, 11 Dec 2004 08:12:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6qb-0005OI-1h; Sat, 11 Dec 2004 07:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd6pb-0005CH-7f for mmusic@megatron.ietf.org; Sat, 11 Dec 2004 07:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20204 for ; Sat, 11 Dec 2004 07:58:37 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd6wz-00026p-RR for mmusic@ietf.org; Sat, 11 Dec 2004 08:06:18 -0500 Received: from [68.217.5.188] (port=1409 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1Cd6pW-0001tu-5v; Sat, 11 Dec 2004 07:58:34 -0500 From: "Alan Clark" To: "Colin Perkins" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sat, 11 Dec 2004 07:58:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <7208A67C-4B6F-11D9-8877-000A957FC5F2@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Mark Baugher X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Colin I would of course be willing to write a suitable draft if this will expedite things Regards Alan -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Saturday, December 11, 2004 7:23 AM To: Alan Clark Cc: mmusic@ietf.org; Mark Baugher Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Alan, On 10 Dec 2004, at 21:05, Alan Clark wrote: > Where does this leave the issue? Some sizeable network and telecom > equipment vendors are in the process of integrating support for the > RFC3611 > VoIP metrics, due in a large part to service provider and enterprise > customer demand. The demand exists because customers need to manage > their > VoIP deployments, hence they see RFC3611 as a key element in their > management infrastructure. The accessibility of RFC3611 VoIP metrics > is > therefore an issue of concern today. Understood. I note that the sdescriptions work is also eagerly awaited by the industry. > If it's proposed to deal with this in a separate draft then what is the > expected timeframe - going through the regular I-D, WG draft, IESG > process > seem to take a year or so. Is there some mechanism by which this can be > accelerated? We have little influence on the IESG process, but the working group doesn't have to take a long time. If this issue is straightforward, we should be able to document a solution that can be progressed to the IESG very quickly. Would you be willing to write such a draft? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 11 09:52:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26631 for ; Sat, 11 Dec 2004 09:52:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd8jL-00043v-7I for mmusic-web-archive@ietf.org; Sat, 11 Dec 2004 10:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd8aL-0008N0-RL; Sat, 11 Dec 2004 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cd8ZT-0008DO-22 for mmusic@megatron.ietf.org; Sat, 11 Dec 2004 09:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26570 for ; Sat, 11 Dec 2004 09:50:04 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd8gq-00041L-KW for mmusic@ietf.org; Sat, 11 Dec 2004 09:57:47 -0500 Received: from [68.217.5.188] (port=1761 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1Cd8ZP-0000gD-Q6; Sat, 11 Dec 2004 09:50:03 -0500 From: "Alan Clark" To: "Mark Baugher" , "Colin Perkins" , "Magnus Westerlund" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sat, 11 Dec 2004 09:50:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit It would seem that an additional draft needs to state roughly the following: (i) Scope - provides method for selective encryption/ unencryption of certain RTCP payload types (ii) Approach - allow for SRTCP encryption to be set ON by default but overridden for certain payload types (iii) New parameter SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames are encrypted with the exception of the listed payload types List of RTCP payload types .. SDES, BYE, RR, SR, XR, XR_VOIPMETRICS, XR_... Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES where ALL_INFORMATIONAL_TYPES = SR, RR as defined in RFC3550 and XR payloads as defined in RFC3611 (iv) Examples ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES or ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS Any comments on the general approach? Regards Alan -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Friday, December 10, 2004 6:39 PM To: Alan Clark Cc: mmusic@ietf.org; Colin Perkins Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Alan, I'm finishing sdescriptions-08 without any change to accommodate XR packets to use the E bit. I don't yet know who is going to do the work on the I-D that Colin suggested to address Magnus' issues with E-bit usage. As it stands now, UNENCRYPTED_SRTCP will need to be signaled in order to keep XR packets in the clear. Mark On Dec 10, 2004, at 1:05 PM, Alan Clark wrote: > Mark, Colin > > Where does this leave the issue? Some sizeable network and telecom > equipment vendors are in the process of integrating support for the > RFC3611 > VoIP metrics, due in a large part to service provider and enterprise > customer demand. The demand exists because customers need to manage > their > VoIP deployments, hence they see RFC3611 as a key element in their > management infrastructure. The accessibility of RFC3611 VoIP metrics > is > therefore an issue of concern today. > > If it's proposed to deal with this in a separate draft then what is the > expected timeframe - going through the regular I-D, WG draft, IESG > process > seem to take a year or so. Is there some mechanism by which this can be > accelerated? > > If the proposal is to address the issue in the draft currently being > finalized then my apologies if this has caused any last minute delays > however the issue is important enough to warrant this (at least in my > view). > We hoped that the comment in the security considerations section of > RFC3611 > was strong enough to address the issue however it appears not to have > been. > > Regards > > Alan > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]On Behalf > Of Mark Baugher > Sent: Friday, December 10, 2004 11:03 AM > To: Colin Perkins > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > Colin, > > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > >> Mark, >> >> On 8 Dec 2004, at 00:43, Mark Baugher wrote: >>> Do we know of any other applications besides RFC 3611 that might >>> need to selectively encrypt SRTCP packets? >> >> I don't, but I can imagine future RTCP extensions which might require >> this feature (and applications that might want to encrypt various >> subsets of the RFC 3611 data). > > I don't see a large downside in waiting until we see such extensions > for real. >> >>> I am okay with putting this requirement aside pending a separate >>> document. But before someone goes to the trouble of writing the new >>> draft, it might be good to consider if it's needed or not. >> >> Even if RTCP XR is the only driver, it might be appropriate to make >> that a separate short draft. There's been enough discussion on the >> list that I'm not entirely comfortable slotting it into sdescriptions >> this late in the process. > > Ok. If there are no objections, I'll generate a new version and post > it early next week. > > Mark >> >> Colin >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 11 14:38:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13113 for ; Sat, 11 Dec 2004 14:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdDCQ-0000eQ-7f for mmusic-web-archive@ietf.org; Sat, 11 Dec 2004 14:46:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdCvB-000754-NY; Sat, 11 Dec 2004 14:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdCtj-0006kC-5U for mmusic@megatron.ietf.org; Sat, 11 Dec 2004 14:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12296 for ; Sat, 11 Dec 2004 14:27:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdD1A-0000Oh-E5 for mmusic@ietf.org; Sat, 11 Dec 2004 14:35:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2004 12:32:43 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBBJQfPx005711; Sat, 11 Dec 2004 11:26:44 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn1-439.cisco.com [10.21.97.183]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR49213; Sat, 11 Dec 2004 11:26:41 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 11 Dec 2004 03:47:49 -0800 Subject: Re: [MMUSIC] ICE issue: obfuscating candidate addresses From: Cullen Jennings To: Magnus Westerlund , Jonathan Rosenberg Message-ID: In-Reply-To: <41B732C5.1090801@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On 12/8/04 8:58 AM, "Magnus Westerlund" wrote: > > - Are these NATs that are helpfull common? I've been trying to figure this out for awhile and I really don't think anyone knows the answer to that questions. I have software that detects in but have not yet run it on a ton of NATs. It is clear that 1) the vast majority of NATs don't do this 2) there is more than 1 vendor that at one time or another has shipped one that does. "helpful" now there's a new word for them :-) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 01:34:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20225 for ; Sun, 12 Dec 2004 01:34:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdNRL-0003op-4c for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 01:42:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdNId-0005T4-AI; Sun, 12 Dec 2004 01:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdNGY-0005Ci-Sg; Sun, 12 Dec 2004 01:31:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20152; Sun, 12 Dec 2004 01:31:34 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdNO5-0003lf-3k; Sun, 12 Dec 2004 01:39:23 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2004 01:31:02 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBC6Ux9E020714; Sun, 12 Dec 2004 01:30:59 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-34.cisco.com [10.86.242.34]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANQ43697; Sun, 12 Dec 2004 01:30:58 -0500 (EST) Message-ID: <41BBE5A2.4080208@cisco.com> Date: Sun, 12 Dec 2004 01:30:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Colin Perkins wrote: > > Decomposing the URL into the "c=" and "m=" lines is very ugly. > Unfortunately, that ugliness is required if you want to use SDP. This is > why the SDPng work was started, to try to move to something less > horrible... You state that as if it was a hard and fast written law. Is it? It was one thing to decompose these parts of the communication address one time for RTP. But there was no URL for that. Now times have moved on, and URLs are common and useful, and they don't fit so well into this paradigm. Something has to adapt, but why aren't we free to have an open mind about where the adaptation is applied? Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 05:38:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17866 for ; Sun, 12 Dec 2004 05:38:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdRFW-000440-GQ for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 05:46:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdR4p-0000Zo-QO; Sun, 12 Dec 2004 05:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdR3o-0000NO-Nb for mmusic@megatron.ietf.org; Sun, 12 Dec 2004 05:34:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17749 for ; Sun, 12 Dec 2004 05:34:38 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdRBP-0003zp-0J for mmusic@ietf.org; Sun, 12 Dec 2004 05:42:31 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBCAWfo4026640 for ; Sun, 12 Dec 2004 05:32:41 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBCAWdo4026610 for ; Sun, 12 Dec 2004 05:32:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sun, 12 Dec 2004 12:34:35 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTfkTb9mNFHmcAlRheGOR5N5s3u+wAo4niw From: "Romascanu, Dan \(Dan\)" To: "Alan Clark" , "Mark Baugher" , "Colin Perkins" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable The short poll run a few days ago was indicating that the RFC 3611 = packets seem to be the only ones candidates right now for selective = encryption. There also were concerns about making a negotiation = mechanism too complex. To keep things simple by now, but flexible for = the future I would suggest that the document does not include the list = of the to the candidate payload types that have a demand for running = non-encrypted in a SRTP deployment, but rather refer to a list external = to the document and maintained by IANA. This list will include only XR = to begin with, and can be extended later without changing this document, = or creating new ones.=20 Regards, Dan > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > Sent: 11 December, 2004 4:50 PM > To: Mark Baugher; Colin Perkins; Magnus Westerlund > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 >=20 > It would seem that an additional draft needs to state roughly=20 > the following: >=20 > (i) Scope - provides method for selective encryption/ unencryption of > certain RTCP payload types >=20 > (ii) Approach - allow for SRTCP encryption to be set ON by default but > overridden for certain payload types >=20 > (iii) New parameter >=20 > SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames=20 > are encrypted > with the exception of the listed payload types >=20 > List of RTCP payload types .. SDES, BYE, RR, SR, XR,=20 > XR_VOIPMETRICS, XR_... >=20 > Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES > where ALL_INFORMATIONAL_TYPES =3D SR, RR as defined in RFC3550=20 > and XR payloads > as defined in RFC3611 >=20 > (iv) Examples >=20 > ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES >=20 > or >=20 > ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS >=20 > Any comments on the general approach? >=20 > Regards >=20 > Alan >=20 >=20 > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Friday, December 10, 2004 6:39 PM > To: Alan Clark > Cc: mmusic@ietf.org; Colin Perkins > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > Alan, > I'm finishing sdescriptions-08 without any change to accommodate XR > packets to use the E bit. I don't yet know who is going to=20 > do the work > on the I-D that Colin suggested to address Magnus' issues with E-bit > usage. As it stands now, UNENCRYPTED_SRTCP will need to be=20 > signaled in > order to keep XR packets in the clear. >=20 > Mark > On Dec 10, 2004, at 1:05 PM, Alan Clark wrote: >=20 > > Mark, Colin > > > > Where does this leave the issue? Some sizeable network and telecom > > equipment vendors are in the process of integrating support for the > > RFC3611 > > VoIP metrics, due in a large part to service provider and enterprise > > customer demand. The demand exists because customers need to manage > > their > > VoIP deployments, hence they see RFC3611 as a key element in their > > management infrastructure. The accessibility of RFC3611=20 > VoIP metrics > > is > > therefore an issue of concern today. > > > > If it's proposed to deal with this in a separate draft then=20 > what is the > > expected timeframe - going through the regular I-D, WG draft, IESG > > process > > seem to take a year or so. Is there some mechanism by which=20 > this can be > > accelerated? > > > > If the proposal is to address the issue in the draft currently being > > finalized then my apologies if this has caused any last=20 > minute delays > > however the issue is important enough to warrant this (at=20 > least in my > > view). > > We hoped that the comment in the security considerations section of > > RFC3611 > > was strong enough to address the issue however it appears=20 > not to have > > been. > > > > Regards > > > > Alan > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf > > Of Mark Baugher > > Sent: Friday, December 10, 2004 11:03 AM > > To: Colin Perkins > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > Colin, > > > > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > > > >> Mark, > >> > >> On 8 Dec 2004, at 00:43, Mark Baugher wrote: > >>> Do we know of any other applications besides RFC 3611 that might > >>> need to selectively encrypt SRTCP packets? > >> > >> I don't, but I can imagine future RTCP extensions which=20 > might require > >> this feature (and applications that might want to encrypt various > >> subsets of the RFC 3611 data). > > > > I don't see a large downside in waiting until we see such extensions > > for real. > >> > >>> I am okay with putting this requirement aside pending a separate > >>> document. But before someone goes to the trouble of=20 > writing the new > >>> draft, it might be good to consider if it's needed or not. > >> > >> Even if RTCP XR is the only driver, it might be appropriate to make > >> that a separate short draft. There's been enough discussion on the > >> list that I'm not entirely comfortable slotting it into=20 > sdescriptions > >> this late in the process. > > > > Ok. If there are no objections, I'll generate a new=20 > version and post > > it early next week. > > > > Mark > >> > >> Colin > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 06:06:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18975 for ; Sun, 12 Dec 2004 06:06:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdRgG-0004U3-GE for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 06:14:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdRW1-0004xV-Ab; Sun, 12 Dec 2004 06:03:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdRSg-0003jB-0z; Sun, 12 Dec 2004 06:00:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18782; Sun, 12 Dec 2004 06:00:19 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdRaG-0004Os-B0; Sun, 12 Dec 2004 06:08:12 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBCB0BF20435; Sun, 12 Dec 2004 13:00:12 +0200 (EET) X-Scanned: Sun, 12 Dec 2004 12:59:28 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iBCAxShP005775; Sun, 12 Dec 2004 12:59:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00sn8Jvn; Sun, 12 Dec 2004 12:59:25 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBCAxPS25557; Sun, 12 Dec 2004 12:59:25 +0200 (EET) Received: from [172.21.35.181] ([172.21.35.181]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 12 Dec 2004 12:59:25 +0200 Message-ID: <41BC248D.4030906@nokia.com> Date: Sun, 12 Dec 2004 12:59:25 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> In-Reply-To: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2004 10:59:25.0531 (UTC) FILETIME=[A4C46AB0:01C4E039] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org Subject: [MMUSIC] Re: [Simple] MSRP: SDP usage concern X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit I also agree with Ben here. I don't see interoperability problems, since MSRP implementations will need to add extra support for SDP. I also think SDP is requiring a general mechanism to be able to indicate a URI as a connection address, rather than the traditional IP address + port number... but that is another story. Let's keep the SDP usage in MSRP as it is now. - Miguel Ben Campbell wrote: > I really need to get closure on this, so I'd appreciate people agreeing > or disagreeing. > > I have had off-list correspondence indicating both positions. In summary: > > In favor of the change, I had a comment to the effect that changing SDP > semantics to ignore the C line and the port field on the M line really > changes it to something that is no longer SDP, and that such deviations > are in general bad for interop. > > In favor of leaving things as currently specified, I had two comments > that decomposing URLs into the C and M lines is ugly, and that having a > different mechanism to communicate endpoint addresses vs relay > addresses is really ugly. > > So, do people agree with one or the other position? Something > completely different? (Hopefully the people who sent off-list > correspondence will reply on-list if they think I mischaracterized > either position. Actually, I hope they will repost on-list even if they > like my summaries) > > I have so far avoided interjecting my personal opinion so that I could > do a fair summary. But, I actually tend to agree with the > leave-things-as-specified position. > > While I am sensitive to the issue of deviating from the spirit of SDP, > I don't really buy the interoperability argument. The currently defined > usage _does_ put "msrp" in the M line--so only consumers that > understand what that means will be able to act on it. I assume that any > endpoint that understands what "msrp" means will also understand how to > use the "path" attribute. > > The place that interoperability might suffer is if any non-endpoint > needs to interpret things--which is generally not a goal. I guess can > also see debug or monitoring tools who don't know about MSRP getting > things wrong. > > My biggest technical objection is that using a different mechanism for > determining where to connect depending on whether you are connecting > peer to peer or through a relay, increases the chances of implementors > getting things wrong. And I cannot personally think of a way to handle > relay addresses that is more in the spirit of SDP than what we > currently have. > > But in any case, I will be happy to document consensus, even if it > disagrees with my position. But we need to close on it asap. > > Thanks! > > Ben. > > On Dec 7, 2004, at 5:20 PM, Ben Campbell wrote: > >> I sent the attached to the SIMPLE list last week. I am reposting it >> to both the SIMPLE and MMUSIC lists, as the discussion is of interest >> to both groups. If you already responded to this on the SIMPLE list >> or in private, it would be helpful if you can re-post your response >> to this thread, so everyone sees the whole discussion. >> >> Thanks! >> >> Ben. >> >> ----------------------------------------------------------------------- >> ----------------------------------------- >> >> >> In the DC meeting, we discussed that MSRP's SDP usage should be >> reviewed in MMUSIC, or at least by people who are more expert in >> SDP. Colin Perkins and Joerg Ott looked at this, and suggested a >> change. (Many thanks to them for taking the time, and I hope they >> will jump in and correct me if I mischaracterize anything.) >> >> The upshot of the proposal is that the fact that MSRP ignores the >> address in the sdp c-line, and the port and proto fields in the >> m-line. Instead, MSRP gets all of this from the first URL in the path >> a-line attribute. This deviates from the traditional usage in SDP, >> and causes confusion. >> >> The proposed change is that the destination URL be broken into the >> appropriate parts and encoded into the c-line and m-line. For example >> (leaving out lines that don't change) >> >> c=IN IP4 alice.example.com >> m=message 9 msrp * >> a=path:msrp://a.example.com:7394/2s93i;tcp >> >> would become: >> >> c=IN IP4 a.example.com >> m=message 7394 msrp/tcp * >> a=session:2s93i >> >> The change would only be made for the destination URL. URLs for any >> relays would be expressed the same way they are now. >> >> The advantage of this approach is that it more closely follows the >> spirit of SDP. This will be easier to understand for people who >> already know SDP. Existing SDP code could be reused more effectively. >> >> The disadvantage of the proposed change is, it means the way an MSRP >> client determines the destination URL would be different depending on >> whether the URL represented the final destination or a relay. Instead >> of the current approach of simply copying the path attribute value >> into the To-Path header in MSRP messages, a client would copy the >> path header value if exists, reconstitute the destination URL from >> the m and c lines, and append the destination URL to the path header >> value. >> >> So, what do people think? (I note that we actually did something >> similar to this before we added the "path" attribute. ) >> >> >> Thanks! >> >> Ben. >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 07:05:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21603 for ; Sun, 12 Dec 2004 07:05:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdSav-0005S8-HS for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 07:12:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdSPD-0007yv-Pq; Sun, 12 Dec 2004 07:00:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdSN9-0007ah-DE; Sun, 12 Dec 2004 06:58:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21345; Sun, 12 Dec 2004 06:58:40 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdSUj-0005M2-SM; Sun, 12 Dec 2004 07:06:34 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id iBCBwNcP017372; Sun, 12 Dec 2004 12:58:31 +0100 (MET) Message-ID: <41BC325D.4010808@tzi.uni-bremen.de> Date: Sun, 12 Dec 2004 12:58:21 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> In-Reply-To: <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Simple WG , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit I agree with Colin on the ugliness issue of decomposing URLs into c= and m= lines. But this is the way SDP has worked and works today. The present discussion we are having here is about changing SDP to for address/URL handling in one particular case. This does not strike me as something MSRP should be concerned with. I would like to make one thing clear: we are either using existing tools in another document or we are building new ones. There is nothing much in between. Changing c=/m= semantics means changing SDP. Just because the syntax still looks the same does not mean that it is still the same protocol. Any entity or generic protocol engine used to dealing with SDP m=/c= would no longer do the right thing. We see this kind of approach quite often -- by far too often -- over the past years (just think the many "uses" of SIP defined elsewhere, usually resulting in something "a little but not entirely unlike" SIP). What I would like avoid is having special treatment of SDP depending on what the media type is (or other attributes signify). Therefore, I strongly agree with Colin's conclusion: take SDP as is or leave it altogether and pursue a different path. Joerg Colin Perkins wrote: > On 10 Dec 2004, at 21:41, Ben Campbell wrote: > >> I really need to get closure on this, so I'd appreciate people >> agreeing or disagreeing. >> >> I have had off-list correspondence indicating both positions. In summary: >> >> In favor of the change, I had a comment to the effect that changing >> SDP semantics to ignore the C line and the port field on the M line >> really changes it to something that is no longer SDP, and that such >> deviations are in general bad for interop. >> >> In favor of leaving things as currently specified, I had two comments >> that decomposing URLs into the C and M lines is ugly, and that having >> a different mechanism to communicate endpoint addresses vs relay >> addresses is really ugly. >> >> So, do people agree with one or the other position? > > > Decomposing the URL into the "c=" and "m=" lines is very ugly. > Unfortunately, that ugliness is required if you want to use SDP. This is > why the SDPng work was started, to try to move to something less > horrible... > > Colin > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 15:03:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24988 for ; Sun, 12 Dec 2004 15:03:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cda3f-0006k7-3k for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 15:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdZql-0001Ua-Le; Sun, 12 Dec 2004 14:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdZo5-0000zv-L9; Sun, 12 Dec 2004 14:55:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24456; Sun, 12 Dec 2004 14:55:00 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdZvk-0006Yk-UB; Sun, 12 Dec 2004 15:02:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2004 11:57:59 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBCJsM5M029272; Sun, 12 Dec 2004 11:54:23 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-34.cisco.com [10.86.242.34]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANQ53245; Sun, 12 Dec 2004 14:54:17 -0500 (EST) Message-ID: <41BCA1E9.8080007@cisco.com> Date: Sun, 12 Dec 2004 14:54:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Ott Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Colin Perkins , Simple WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Joerg Ott wrote: > I agree with Colin on the ugliness issue of decomposing URLs into > c= and m= lines. But this is the way SDP has worked and works today. > > The present discussion we are having here is about changing SDP to > for address/URL handling in one particular case. This does not > strike me as something MSRP should be concerned with. > > I would like to make one thing clear: we are either using existing tools > in another document or we are building new ones. There is nothing much > in between. > > Changing c=/m= semantics means changing SDP. Just because the syntax > still looks the same does not mean that it is still the same protocol. > Any entity or generic protocol engine used to dealing with SDP m=/c= > would no longer do the right thing. Can you explain what sort of generic processing of SDP that would break as a result of this change, but would not break as a result of adding MSRP in a syntax you have in mind? There is really only a minimal amount of generic processing that can be done for SDP as it stands. That doesn't include actual management of sockets, since that is all dependent on "transport". I have worked with an SDP "stack", and it isn't harmed in any way by the usage proposed in MSRP. The work that will be needed to support MSRP will only be made more complex by tearing info out of a URL and pasting it into the c- and m- lines. > We see this kind of approach quite often -- by far too often -- over > the past years (just think the many "uses" of SIP defined elsewhere, > usually resulting in something "a little but not entirely unlike" SIP). > > What I would like avoid is having special treatment of SDP depending > on what the media type is (or other attributes signify). Then why not just restrict SDP to use with RTP transports? That covers what it seems to have been designed for. Half the stuff defined in SDP is only applicable in that case. It has also been a real stretch to apply SDP to the offer/answer needs of SIP. Maybe that was an abuse too. > Therefore, I strongly agree with Colin's conclusion: take SDP as is > or leave it altogether and pursue a different path. Right! Given that the only alternative in sight is SDPng, and apparently nobody as any belief that it will be adopted in our lifetimes. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 12 18:45:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12981 for ; Sun, 12 Dec 2004 18:45:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CddWc-00034v-Az for mmusic-web-archive@ietf.org; Sun, 12 Dec 2004 18:53:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CddNY-0000sf-Gx; Sun, 12 Dec 2004 18:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CddLF-0000Th-Ix for mmusic@megatron.ietf.org; Sun, 12 Dec 2004 18:41:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12756 for ; Sun, 12 Dec 2004 18:41:26 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CddSw-00030u-4L for mmusic@ietf.org; Sun, 12 Dec 2004 18:49:26 -0500 Received: from [68.217.5.188] (port=3026 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CddLD-0001fV-98; Sun, 12 Dec 2004 18:41:27 -0500 From: "Alan Clark" To: "Romascanu, Dan \(Dan\)" , "Mark Baugher" , "Colin Perkins" , "Magnus Westerlund" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Sun, 12 Dec 2004 18:41:33 -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.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: 7bit There is already an IANA numbering system for the various report types and presumably we should just use this IANA already knows about:- FIR full INTRA-frame request 192 [RFC2032] NACK negative acknowledgement 193 [RFC2032] SR sender report 200 [RFC3551] RR receiver report 201 [RFC3551] SDES source description 202 [RFC3551] BYE goodbye 203 [RFC3551] APP application-defined 204 [RFC3551] XR extended report 207 [RFC3611] and for RTCP XR BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Packet Receipt Times Report Block 4 Receiver Reference Time Report Block 5 DLRR Report Block 6 Statistics Summary Report Block 7 VoIP Metrics Report Block This would result in syntax along the lines of ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[7],BYE or ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[6,7] or presumably ....., SELECTIVE_SRTCP_UNENCRYPTED:200,201,207[6,7] This looks like quite a short draft!!!!! We only need to add one new parameter to the sdescriptions to give much more flexibility. Regards Alan -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Sunday, December 12, 2004 5:35 AM To: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund Cc: mmusic@ietf.org Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP The short poll run a few days ago was indicating that the RFC 3611 packets seem to be the only ones candidates right now for selective encryption. There also were concerns about making a negotiation mechanism too complex. To keep things simple by now, but flexible for the future I would suggest that the document does not include the list of the to the candidate payload types that have a demand for running non-encrypted in a SRTP deployment, but rather refer to a list external to the document and maintained by IANA. This list will include only XR to begin with, and can be extended later without changing this document, or creating new ones. Regards, Dan > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > Sent: 11 December, 2004 4:50 PM > To: Mark Baugher; Colin Perkins; Magnus Westerlund > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > It would seem that an additional draft needs to state roughly > the following: > > (i) Scope - provides method for selective encryption/ unencryption of > certain RTCP payload types > > (ii) Approach - allow for SRTCP encryption to be set ON by default but > overridden for certain payload types > > (iii) New parameter > > SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames > are encrypted > with the exception of the listed payload types > > List of RTCP payload types .. SDES, BYE, RR, SR, XR, > XR_VOIPMETRICS, XR_... > > Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES > where ALL_INFORMATIONAL_TYPES = SR, RR as defined in RFC3550 > and XR payloads > as defined in RFC3611 > > (iv) Examples > > ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES > > or > > ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS > > Any comments on the general approach? > > Regards > > Alan > > > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Friday, December 10, 2004 6:39 PM > To: Alan Clark > Cc: mmusic@ietf.org; Colin Perkins > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > Alan, > I'm finishing sdescriptions-08 without any change to accommodate XR > packets to use the E bit. I don't yet know who is going to > do the work > on the I-D that Colin suggested to address Magnus' issues with E-bit > usage. As it stands now, UNENCRYPTED_SRTCP will need to be > signaled in > order to keep XR packets in the clear. > > Mark > On Dec 10, 2004, at 1:05 PM, Alan Clark wrote: > > > Mark, Colin > > > > Where does this leave the issue? Some sizeable network and telecom > > equipment vendors are in the process of integrating support for the > > RFC3611 > > VoIP metrics, due in a large part to service provider and enterprise > > customer demand. The demand exists because customers need to manage > > their > > VoIP deployments, hence they see RFC3611 as a key element in their > > management infrastructure. The accessibility of RFC3611 > VoIP metrics > > is > > therefore an issue of concern today. > > > > If it's proposed to deal with this in a separate draft then > what is the > > expected timeframe - going through the regular I-D, WG draft, IESG > > process > > seem to take a year or so. Is there some mechanism by which > this can be > > accelerated? > > > > If the proposal is to address the issue in the draft currently being > > finalized then my apologies if this has caused any last > minute delays > > however the issue is important enough to warrant this (at > least in my > > view). > > We hoped that the comment in the security considerations section of > > RFC3611 > > was strong enough to address the issue however it appears > not to have > > been. > > > > Regards > > > > Alan > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org]On Behalf > > Of Mark Baugher > > Sent: Friday, December 10, 2004 11:03 AM > > To: Colin Perkins > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > Colin, > > > > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > > > >> Mark, > >> > >> On 8 Dec 2004, at 00:43, Mark Baugher wrote: > >>> Do we know of any other applications besides RFC 3611 that might > >>> need to selectively encrypt SRTCP packets? > >> > >> I don't, but I can imagine future RTCP extensions which > might require > >> this feature (and applications that might want to encrypt various > >> subsets of the RFC 3611 data). > > > > I don't see a large downside in waiting until we see such extensions > > for real. > >> > >>> I am okay with putting this requirement aside pending a separate > >>> document. But before someone goes to the trouble of > writing the new > >>> draft, it might be good to consider if it's needed or not. > >> > >> Even if RTCP XR is the only driver, it might be appropriate to make > >> that a separate short draft. There's been enough discussion on the > >> list that I'm not entirely comfortable slotting it into > sdescriptions > >> this late in the process. > > > > Ok. If there are no objections, I'll generate a new > version and post > > it early next week. > > > > Mark > >> > >> Colin > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > 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-bounces@ietf.org Mon Dec 13 04:25:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14904 for ; Mon, 13 Dec 2004 04:25:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmaM-0008IT-Oz for mmusic-web-archive@ietf.org; Mon, 13 Dec 2004 04:33:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmOq-0002h5-Me; Mon, 13 Dec 2004 04:21:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmEC-0007Z5-CO; Mon, 13 Dec 2004 04:10:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12657; Mon, 13 Dec 2004 04:10:46 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmLx-0007t5-Pz; Mon, 13 Dec 2004 04:18:51 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 8DC7BA9567; Mon, 13 Dec 2004 10:10:14 +0100 (CET) Received: from [192.168.1.67] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id C801DA9560; Mon, 13 Dec 2004 10:10:12 +0100 (CET) In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Mon, 13 Dec 2004 10:10:06 +0100 To: Joerg Ott X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Colin Perkins , Simple WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit (not as chair, but as an MSRP protocol contributor) The objection to using the SDP c and m lines is not purely a cosmetic objection. We are not saying that SDP the way it is defined today is ugly so we want to rearrange it to look better. We have a fundamental objection: having 2 ways to construct a next hop URI that depends on the entity that is the next hop is not acceptable. Endpoints should not be required to have 2 engines implemented. Unless we are given an alternative that allows endpoint implementers to implement one piece of code for constructing an next hop MSRP URI, I'm afraid we have no choice but to keep what we have today in MSRP as is. You telling us to go find another protocol if we don't like SDP the way it is today is hardly contructive. SDPng is not an option and we call know it. Let me add that comedia also violates what you claim to be a fundamental piece of the protocol that if broken will cause the SDP protocol not to be SDP any longer. An argument that I don't buy. We have violated things before: - t= line does not mean anything in SIP and is set to 0 0 (which in SDP means that the session is permanent and unbounded). - s= line carries session name. It is set to - when used with SIP. Also, quoting the SDP draft: "For unicast IP sessions, the following are conveyed: o The remote address for media o The remote transport port for media The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types MAY redefine this behaviour, but this is NOT RECOMMENDED." We are changing the semantics. As far as I understand from the quoted paragraph above, we are not violating anything, even-though it is not recommended. I have a question to SDP stack implementers that plan to implement MSRP: Does the current way MSRP specifies the use of SDP (ignore the c line address and the m line port and instead use the attribute a=path) cause problems to you and requires you to do some hacking in your SDP stack? If so, is that acceptable or do you prefer for your MSRP implementation to implement two ways of contructing an MSRP URL depending on the what the next hop is? Regards, Hisham On Dec 12, 2004, at 12:58 PM, Joerg Ott wrote: > I agree with Colin on the ugliness issue of decomposing URLs into > c= and m= lines. But this is the way SDP has worked and works today. > > The present discussion we are having here is about changing SDP to > for address/URL handling in one particular case. This does not > strike me as something MSRP should be concerned with. > > I would like to make one thing clear: we are either using existing > tools > in another document or we are building new ones. There is nothing much > in between. > > Changing c=/m= semantics means changing SDP. Just because the syntax > still looks the same does not mean that it is still the same protocol. > Any entity or generic protocol engine used to dealing with SDP m=/c= > would no longer do the right thing. > > We see this kind of approach quite often -- by far too often -- over > the past years (just think the many "uses" of SIP defined elsewhere, > usually resulting in something "a little but not entirely unlike" SIP). > > What I would like avoid is having special treatment of SDP depending > on what the media type is (or other attributes signify). > > Therefore, I strongly agree with Colin's conclusion: take SDP as is > or leave it altogether and pursue a different path. > > Joerg > > > Colin Perkins wrote: > >> On 10 Dec 2004, at 21:41, Ben Campbell wrote: >>> I really need to get closure on this, so I'd appreciate people >>> agreeing or disagreeing. >>> >>> I have had off-list correspondence indicating both positions. In >>> summary: >>> >>> In favor of the change, I had a comment to the effect that changing >>> SDP semantics to ignore the C line and the port field on the M line >>> really changes it to something that is no longer SDP, and that such >>> deviations are in general bad for interop. >>> >>> In favor of leaving things as currently specified, I had two >>> comments that decomposing URLs into the C and M lines is ugly, and >>> that having a different mechanism to communicate endpoint addresses >>> vs relay addresses is really ugly. >>> >>> So, do people agree with one or the other position? >> Decomposing the URL into the "c=" and "m=" lines is very ugly. >> Unfortunately, that ugliness is required if you want to use SDP. This >> is why the SDPng work was started, to try to move to something less >> horrible... >> Colin >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 13 05:04:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17649 for ; Mon, 13 Dec 2004 05:04:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdnBt-0000g3-7r for mmusic-web-archive@ietf.org; Mon, 13 Dec 2004 05:12:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdmy1-0005ET-Kd; Mon, 13 Dec 2004 04:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdmrd-0003IX-Lh for mmusic@megatron.ietf.org; Mon, 13 Dec 2004 04:51:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16930 for ; Mon, 13 Dec 2004 04:51:31 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmzQ-0000OX-9T for mmusic@ietf.org; Mon, 13 Dec 2004 04:59:36 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBD9nYo4001235 for ; Mon, 13 Dec 2004 04:49:34 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBD9nWo4001213 for ; Mon, 13 Dec 2004 04:49:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Mon, 13 Dec 2004 11:51:29 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTgpBxEMzadtHU0RXyrDpdEjFqYXgAVGcQA From: "Romascanu, Dan \(Dan\)" To: "Alan Clark" , "Mark Baugher" , "Colin Perkins" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: quoted-printable Previous discussions revealed concerns about extensive complexity, = especially in implementation and testing, in the situation that today we = know that only there is a need only for the 3611 report type to be = transmitted as selectively unencrypted. My suggestion is that we define = in IANA the subset of the report types that need to be transmitted = unencrypted. The list would include only XR extended reports 207 by now = and may be extended in the future. The draft remains similarly short, = but the syntax is to be defined in a manner generic enough to cover by = reference future extensions.=20 Regards, Dan > -----Original Message----- > From: Alan Clark [mailto:alan.d.clark@telchemy.com] > Sent: 13 December, 2004 1:42 AM > To: Romascanu, Dan (Dan); Mark Baugher; Colin Perkins; Magnus=20 > Westerlund > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 >=20 > There is already an IANA numbering system for the various=20 > report types and > presumably we should just use this >=20 > IANA already knows about:- >=20 > FIR full INTRA-frame request 192 [RFC2032] > NACK negative acknowledgement 193 [RFC2032] > SR sender report 200 [RFC3551] > RR receiver report 201 [RFC3551] > SDES source description 202 [RFC3551] > BYE goodbye 203 [RFC3551] > APP application-defined 204 [RFC3551] > XR extended report 207 [RFC3611] >=20 > and for RTCP XR >=20 > BT name > -- ---- > 1 Loss RLE Report Block > 2 Duplicate RLE Report Block > 3 Packet Receipt Times Report Block > 4 Receiver Reference Time Report Block > 5 DLRR Report Block > 6 Statistics Summary Report Block > 7 VoIP Metrics Report Block >=20 > This would result in syntax along the lines of >=20 > ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[7],BYE >=20 > or >=20 > ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[6,7] >=20 > or presumably >=20 > ....., SELECTIVE_SRTCP_UNENCRYPTED:200,201,207[6,7] >=20 > This looks like quite a short draft!!!!! We only need to add one new > parameter to the sdescriptions to give much more flexibility. >=20 > Regards >=20 > Alan >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Sunday, December 12, 2004 5:35 AM > To: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > The short poll run a few days ago was indicating that the RFC=20 > 3611 packets > seem to be the only ones candidates right now for selective=20 > encryption. > There also were concerns about making a negotiation mechanism=20 > too complex. > To keep things simple by now, but flexible for the future I=20 > would suggest > that the document does not include the list of the to the=20 > candidate payload > types that have a demand for running non-encrypted in a SRTP=20 > deployment, but > rather refer to a list external to the document and=20 > maintained by IANA. This > list will include only XR to begin with, and can be extended=20 > later without > changing this document, or creating new ones. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org]On Behalf Of Alan Clark > > Sent: 11 December, 2004 4:50 PM > > To: Mark Baugher; Colin Perkins; Magnus Westerlund > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > > > It would seem that an additional draft needs to state roughly > > the following: > > > > (i) Scope - provides method for selective encryption/=20 > unencryption of > > certain RTCP payload types > > > > (ii) Approach - allow for SRTCP encryption to be set ON by=20 > default but > > overridden for certain payload types > > > > (iii) New parameter > > > > SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames > > are encrypted > > with the exception of the listed payload types > > > > List of RTCP payload types .. SDES, BYE, RR, SR, XR, > > XR_VOIPMETRICS, XR_... > > > > Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES > > where ALL_INFORMATIONAL_TYPES =3D SR, RR as defined in RFC3550 > > and XR payloads > > as defined in RFC3611 > > > > (iv) Examples > > > > ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES > > > > or > > > > ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS > > > > Any comments on the general approach? > > > > Regards > > > > Alan > > > > > > -----Original Message----- > > From: Mark Baugher [mailto:mbaugher@cisco.com] > > Sent: Friday, December 10, 2004 6:39 PM > > To: Alan Clark > > Cc: mmusic@ietf.org; Colin Perkins > > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > Alan, > > I'm finishing sdescriptions-08 without any change to=20 > accommodate XR > > packets to use the E bit. I don't yet know who is going to > > do the work > > on the I-D that Colin suggested to address Magnus' issues with E-bit > > usage. As it stands now, UNENCRYPTED_SRTCP will need to be > > signaled in > > order to keep XR packets in the clear. > > > > Mark > > On Dec 10, 2004, at 1:05 PM, Alan Clark wrote: > > > > > Mark, Colin > > > > > > Where does this leave the issue? Some sizeable network=20 > and telecom > > > equipment vendors are in the process of integrating=20 > support for the > > > RFC3611 > > > VoIP metrics, due in a large part to service provider and=20 > enterprise > > > customer demand. The demand exists because customers=20 > need to manage > > > their > > > VoIP deployments, hence they see RFC3611 as a key element in their > > > management infrastructure. The accessibility of RFC3611 > > VoIP metrics > > > is > > > therefore an issue of concern today. > > > > > > If it's proposed to deal with this in a separate draft then > > what is the > > > expected timeframe - going through the regular I-D, WG draft, IESG > > > process > > > seem to take a year or so. Is there some mechanism by which > > this can be > > > accelerated? > > > > > > If the proposal is to address the issue in the draft=20 > currently being > > > finalized then my apologies if this has caused any last > > minute delays > > > however the issue is important enough to warrant this (at > > least in my > > > view). > > > We hoped that the comment in the security considerations=20 > section of > > > RFC3611 > > > was strong enough to address the issue however it appears > > not to have > > > been. > > > > > > Regards > > > > > > Alan > > > > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org]On Behalf > > > Of Mark Baugher > > > Sent: Friday, December 10, 2004 11:03 AM > > > To: Colin Perkins > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > > > > Colin, > > > > > > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote: > > > > > >> Mark, > > >> > > >> On 8 Dec 2004, at 00:43, Mark Baugher wrote: > > >>> Do we know of any other applications besides RFC 3611=20 > that might > > >>> need to selectively encrypt SRTCP packets? > > >> > > >> I don't, but I can imagine future RTCP extensions which > > might require > > >> this feature (and applications that might want to encrypt various > > >> subsets of the RFC 3611 data). > > > > > > I don't see a large downside in waiting until we see such=20 > extensions > > > for real. > > >> > > >>> I am okay with putting this requirement aside pending=20 > a separate > > >>> document. But before someone goes to the trouble of > > writing the new > > >>> draft, it might be good to consider if it's needed or not. > > >> > > >> Even if RTCP XR is the only driver, it might be=20 > appropriate to make > > >> that a separate short draft. There's been enough=20 > discussion on the > > >> list that I'm not entirely comfortable slotting it into > > sdescriptions > > >> this late in the process. > > > > > > Ok. If there are no objections, I'll generate a new > > version and post > > > it early next week. > > > > > > Mark > > >> > > >> Colin > > >> > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 13 16:07:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20805 for ; Mon, 13 Dec 2004 16:07:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdxXS-0001Ya-Qr for mmusic-web-archive@ietf.org; Mon, 13 Dec 2004 16:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdwxE-0004Nj-TL; Mon, 13 Dec 2004 15:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdwtM-0001m0-4r; Mon, 13 Dec 2004 15:34:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16357; Mon, 13 Dec 2004 15:33:58 -0500 (EST) Message-Id: <200412132033.PAA16357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 13 Dec 2004 15:33:58 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : M. Handley, et al. Filename : draft-ietf-mmusic-sdp-new-23.txt Pages : 48 Date : 2004-12-13 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-new-23.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-23.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-13145537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-13145537.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Dec 13 17:50:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04334 for ; Mon, 13 Dec 2004 17:50:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdz8v-0005B6-QJ for mmusic-web-archive@ietf.org; Mon, 13 Dec 2004 17:58:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdyzu-0007Ia-CZ; Mon, 13 Dec 2004 17:48:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdyrw-0005jd-Ok for mmusic@megatron.ietf.org; Mon, 13 Dec 2004 17:40:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03768 for ; Mon, 13 Dec 2004 17:40:38 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdyzp-0004zY-D7 for mmusic@ietf.org; Mon, 13 Dec 2004 17:48:50 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63585 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CdyrL-000483-Rj; Mon, 13 Dec 2004 22:40:03 +0000 In-Reply-To: <200412132033.PAA16357@ietf.org> References: <200412132033.PAA16357@ietf.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-23.txt Date: Mon, 13 Dec 2004 22:39:49 +0000 To: IETF MMUSIC Working Group X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On 13 Dec 2004, at 20:33, Internet-Drafts@ietf.org wrote: > Title : SDP: Session Description Protocol > Author(s) : M. Handley, et al. > Filename : draft-ietf-mmusic-sdp-new-23.txt > Pages : 48 > Date : 2004-12-13 > > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-23.txt Changes in this version: - Fix section references in IANA considerations; expand "Encoding Considerations" - Note that the and in "o=" may be chosen to obfuscate the actual values, provided this does not compromise the global uniqueness of the field. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 02:51:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28319 for ; Tue, 14 Dec 2004 02:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce7ak-0000Bd-LU for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 02:59:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce7Qp-0003AE-5H; Tue, 14 Dec 2004 02:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce7OY-000303-EI for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 02:46:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28100 for ; Tue, 14 Dec 2004 02:46:53 -0500 (EST) Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce7WV-00007c-Rb for mmusic@ietf.org; Tue, 14 Dec 2004 02:55:09 -0500 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id iBE7jp8s014177; Mon, 13 Dec 2004 23:45:51 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 13 Dec 2004 23:45:50 -0800 (PST) From: Stephen Casner To: "Romascanu, Dan (Dan)" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP In-Reply-To: Message-ID: <20041213233834.S8608@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Magnus Westerlund , mmusic@ietf.org, Mark Baugher , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Mon, 13 Dec 2004, Romascanu, Dan (Dan) wrote: > Previous discussions revealed concerns about extensive complexity, > especially in implementation and testing, in the situation that > today we know that only there is a need only for the 3611 report > type to be transmitted as selectively unencrypted. My suggestion is > that we define in IANA the subset of the report types that need to > be transmitted unencrypted. The list would include only XR extended > reports 207 by now and may be extended in the future. This means I write my application today using the selectively unencrypted RTCP option knowning that only XR is unencrypted, then tomorrow my implementation talks to some new implementation that knows the IANA registry has changed to include XR and FOO, so both packet types are sent to me unencrypted when I don't expect it! This is not feasible. Security policies would be violated. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 04:53:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08738 for ; Tue, 14 Dec 2004 04:53:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce9Ug-0003H5-Ol for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 05:01:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce9LW-0003n8-Ey; Tue, 14 Dec 2004 04:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce9K0-0003aq-9l for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 04:50:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08229 for ; Tue, 14 Dec 2004 04:50:18 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce9Rx-00033j-VO for mmusic@ietf.org; Tue, 14 Dec 2004 04:58:35 -0500 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBE9o9h9027987; Tue, 14 Dec 2004 10:50:10 +0100 (MET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Dec 2004 10:50:06 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Dec 2004 10:48:21 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 965A3189CC; Tue, 14 Dec 2004 11:48:20 +0200 (EET) Message-ID: <41BEB6E4.1070905@ericsson.com> Date: Tue, 14 Dec 2004 11:48:20 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [MMUSIC] Connection-Precon-01 question References: <4.3.2.7.2.20041203120630.0339a960@localhost> In-Reply-To: <4.3.2.7.2.20041203120630.0339a960@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2004 09:48:21.0375 (UTC) FILETIME=[0BF558F0:01C4E1C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hi James, > I thought the idea of preconditions was that they need to be met prior > to session establishment. I believe this is when the precondition state > table is identical in both UAs. The tables do not actually need to be the same in both UAs. The tables that need to be equal are the table showing the current status and the table showing the desired status of the preconditions. Furthermore, in our case, the tables need only to be equal at the UAS. That's why the UAC does not ask for updates on the status. Once the UAS knows that both tables are equal, it resumes session establishment without explicitly informing the UAC. In this example, the UAS receives an INVITE that says: "do not alert the user until the TCP connection is established". The rest of the SIP messages exchanged between both ends do not have anything to do with the precondition. They have to do with establishing the TCP connection. Once the TCP connection is established, the precondition is met. Now the UAS could send a SIP message to the UAC saying "the current status is now sendrecv so I will now resume session establishment"... but the UAS does not actually need to do this, because the 180 Ringing will inform the UAC anyway that session establishment has resumed. That's why you do not see any message with "curr:conn e2e sendserv" in the flow. Note that when dealing with this type of precondition, UAs usually get local information on the status of the connection. That is, the UAs know that the TCP connection is established because they gets this information from their own socket. That's why we do not usually need to use SIP to inform the other end about this type of event. In any case, if you want me to clarify something in the text let me know and I will do it. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 05:02:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09212 for ; Tue, 14 Dec 2004 05:02:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce9dV-0003RV-6h for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 05:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce9UH-0004qD-6s; Tue, 14 Dec 2004 05:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce9Ob-000489-9V for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 04:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08808 for ; Tue, 14 Dec 2004 04:55:03 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce9Wa-0003J5-TV for mmusic@ietf.org; Tue, 14 Dec 2004 05:03:21 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBE9kFfX025971 for ; Tue, 14 Dec 2004 04:46:15 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBE9kDfX025913 for ; Tue, 14 Dec 2004 04:46:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 14 Dec 2004 11:55:00 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcThsPplIBwXmJ6ESYKL6iFGK/OlKgAEEYig From: "Romascanu, Dan \(Dan\)" To: "Stephen Casner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , mmusic@ietf.org, Mark Baugher , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable See in-line.=20 Regards, Dan > -----Original Message----- > From: casner@packetdesign.com=20 > [mailto:casner@packetdesign.com]On Behalf Of Stephen Casner > Sent: 14 December, 2004 9:46 AM > To: Romascanu, Dan (Dan) > Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus=20 > Westerlund; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > On Mon, 13 Dec 2004, Romascanu, Dan (Dan) wrote: >=20 > > Previous discussions revealed concerns about extensive complexity, > > especially in implementation and testing, in the situation that > > today we know that only there is a need only for the 3611 report > > type to be transmitted as selectively unencrypted. My suggestion is > > that we define in IANA the subset of the report types that need to > > be transmitted unencrypted. The list would include only XR extended > > reports 207 by now and may be extended in the future. >=20 > This means I write my application today using the selectively > unencrypted RTCP option knowning that only XR is unencrypted, then > tomorrow my implementation talks to some new implementation that > knows the IANA registry has changed to include XR and FOO, so both > packet types are sent to me unencrypted when I don't expect it! >=20 > This is not feasible. Security policies would be violated. The alternative is to define that only XR packets can run un-encrypted = and every time new cases requiring other types to run un-encrypted show = up re-write the standard. This looks to un-flexible to me.=20 Note that security policies may require in some cases that even XR be = encrypted. In the enterprise space I can assure you that requiring end = devices to transmit data unencrypted over Service Providers backbones = may be a problem, because one is trading security for monitoring. That's = why I believe that we need anyway some means of refusing to receive = un-encrypted packets of a certain type - for example do not start = sending un-encrypted packets until you received the information from the = other end that it intends to do the same.=20 >=20 > -- Steve >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 06:33:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14640 for ; Tue, 14 Dec 2004 06:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeB3K-0005Gy-Np for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 06:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeAtO-0002Tp-Md; Tue, 14 Dec 2004 06:30:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeArB-00026k-Bh for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 06:28:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14383 for ; Tue, 14 Dec 2004 06:28:39 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeAzA-0005C5-Gt for mmusic@ietf.org; Tue, 14 Dec 2004 06:36:58 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBEBSbh5024345 for ; Tue, 14 Dec 2004 12:28:37 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Dec 2004 12:28:37 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YLNLXRGZ; Tue, 14 Dec 2004 12:28:37 +0100 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ABA65189CC; Tue, 14 Dec 2004 13:28:36 +0200 (EET) Message-ID: <41BECE64.3040401@ericsson.com> Date: Tue, 14 Dec 2004 13:28:36 +0200 X-Sybari-Trust: c8e7d61a 96d33411 4e0a7834 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt References: <1A440D10-46EC-11D9-844E-000A957FC5F2@csperkins.org> <41B45670.5040601@ericsson.com> In-Reply-To: <41B45670.5040601@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2004 11:28:37.0282 (UTC) FILETIME=[0DB7E820:01C4E1D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC Working Group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi Magnus, > 1. Section 4: No ABNF definition of "token". I assume that you use that > of SDP. However it needs to be either referenced or explicitly defined. yes, I got this comment from Colin before in a conversation we had. We will reference SDPnew and clarify that the attribute value is not arbitrary text but a token. > 2. No reference to what BNF you are using. I guess a reference to RFC > 2234 is all that is needed. Otherwise, there would however be some > uncertainties about spacing. Is any white spaces allowed between > "a=label:" and the pointer. In RFC 2234 BNF the syntax would say no. In > some other BNF the answer may be yes. We will reference RFC 2234. > 3. Section 5. I am a bit worried about the offer/answer section. It is > very unclear on the handling of this attribute. Can we really trust > applications to define such behavior? From my work with Offer/Answer I > sometimes find it difficult to get the right behavior out of SDP in > offer/answer usage. If this behavior is left to the application then > there is need for a much more explicit section that explains the > different choices. Also I think using application defined behavior will > result in quite divergent behavior. If this was an attribute that had any influence in the offer/answer behabior I would agree with you. But this attribute, from the offer/answer point of view, is just informational. That's why offerers and answerers can use it as the wish. It does not have any influence in the session being established. The behavior we expect applications to define would be something like, "use the same label in the media line as in the XML document you are using to describe your conference". Note that this attribute is always for the remote's UA information, so, the values that this attribute takes in an answer is completely independent from the value it takes in the offer. > 4. Reference [4] is only informative. We'll fix it. Thanks for the comments, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 11:32:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17887 for ; Tue, 14 Dec 2004 11:32:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFjd-0006Ea-1U for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 11:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFa2-00023K-Cg; Tue, 14 Dec 2004 11:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFXx-0001eI-RM for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 11:29:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17448 for ; Tue, 14 Dec 2004 11:29:07 -0500 (EST) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFg0-00066f-Mr for mmusic@ietf.org; Tue, 14 Dec 2004 11:37:29 -0500 Received: from [64.238.103.215] (port=1248 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CeFXv-0005e1-Bi; Tue, 14 Dec 2004 11:29:07 -0500 From: "Alan Clark" To: "Romascanu, Dan \(Dan\)" , "Stephen Casner" Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 14 Dec 2004 11:29:06 -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.6604 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , mmusic@ietf.org, Mark Baugher , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Dan The concept is to allow all RTCP packets to be sent in encrypted form if the security policy requires it, and to allow either all RTCP packets or selected types of payload to be sent unencrypted if that is acceptable to the network operator/ enterprise/ service provider. What's the problem? Alan -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, December 14, 2004 4:55 AM To: Stephen Casner Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund; mmusic@ietf.org Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP See in-line. Regards, Dan > -----Original Message----- > From: casner@packetdesign.com > [mailto:casner@packetdesign.com]On Behalf Of Stephen Casner > Sent: 14 December, 2004 9:46 AM > To: Romascanu, Dan (Dan) > Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus > Westerlund; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > On Mon, 13 Dec 2004, Romascanu, Dan (Dan) wrote: > > > Previous discussions revealed concerns about extensive complexity, > > especially in implementation and testing, in the situation that > > today we know that only there is a need only for the 3611 report > > type to be transmitted as selectively unencrypted. My suggestion is > > that we define in IANA the subset of the report types that need to > > be transmitted unencrypted. The list would include only XR extended > > reports 207 by now and may be extended in the future. > > This means I write my application today using the selectively > unencrypted RTCP option knowning that only XR is unencrypted, then > tomorrow my implementation talks to some new implementation that > knows the IANA registry has changed to include XR and FOO, so both > packet types are sent to me unencrypted when I don't expect it! > > This is not feasible. Security policies would be violated. The alternative is to define that only XR packets can run un-encrypted and every time new cases requiring other types to run un-encrypted show up re-write the standard. This looks to un-flexible to me. Note that security policies may require in some cases that even XR be encrypted. In the enterprise space I can assure you that requiring end devices to transmit data unencrypted over Service Providers backbones may be a problem, because one is trading security for monitoring. That's why I believe that we need anyway some means of refusing to receive un-encrypted packets of a certain type - for example do not start sending un-encrypted packets until you received the information from the other end that it intends to do the same. > > -- Steve > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 11:47:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19381 for ; Tue, 14 Dec 2004 11:47:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFxK-0006hp-9I for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 11:55:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFj2-0003l0-M5; Tue, 14 Dec 2004 11:40:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeFeK-0002lh-35 for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 11:35:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18525 for ; Tue, 14 Dec 2004 11:35:42 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeFmM-0006On-6q for mmusic@ietf.org; Tue, 14 Dec 2004 11:44:03 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBEGXho4002808 for ; Tue, 14 Dec 2004 11:33:43 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBEGXdo4002705 for ; Tue, 14 Dec 2004 11:33:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Date: Tue, 14 Dec 2004 18:35:36 +0200 Message-ID: Thread-Topic: [MMUSIC] RE: [AVT] RFC 3711 and RTCP Thread-Index: AcTh+hFac/4vFM79R0uAu29C0ezcXQAAEUOw From: "Romascanu, Dan \(Dan\)" To: "Alan Clark" , "Stephen Casner" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , mmusic@ietf.org, Mark Baugher , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Alan, I understand the concept, and there is no problem.=20 The discussion is about how flexible we would like the mechanism = described in the document to be. Stephen seems to favor a mechanism that = designates only the XR packet types to be covered by the standard, I = would prefer a more flexible mechanism, that refers a list maintained by = IANA (subset of the full list) which may include other types than XR be = added in the future.=20 Regards, Dan > -----Original Message----- > From: Alan Clark [mailto:alan.d.clark@telchemy.com] > Sent: 14 December, 2004 6:29 PM > To: Romascanu, Dan (Dan); Stephen Casner > Cc: Mark Baugher; Colin Perkins; Magnus Westerlund; mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > Dan >=20 > The concept is to allow all RTCP packets to be sent in=20 > encrypted form if the > security policy requires it, and to allow either all RTCP packets or > selected types of payload to be sent unencrypted if that is=20 > acceptable to > the network operator/ enterprise/ service provider. What's=20 > the problem? >=20 > Alan >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, December 14, 2004 4:55 AM > To: Stephen Casner > Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund; > mmusic@ietf.org > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP >=20 >=20 > See in-line. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: casner@packetdesign.com > > [mailto:casner@packetdesign.com]On Behalf Of Stephen Casner > > Sent: 14 December, 2004 9:46 AM > > To: Romascanu, Dan (Dan) > > Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus > > Westerlund; mmusic@ietf.org > > Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP > > > > > > On Mon, 13 Dec 2004, Romascanu, Dan (Dan) wrote: > > > > > Previous discussions revealed concerns about extensive complexity, > > > especially in implementation and testing, in the situation that > > > today we know that only there is a need only for the 3611 report > > > type to be transmitted as selectively unencrypted. My=20 > suggestion is > > > that we define in IANA the subset of the report types that need to > > > be transmitted unencrypted. The list would include only=20 > XR extended > > > reports 207 by now and may be extended in the future. > > > > This means I write my application today using the selectively > > unencrypted RTCP option knowning that only XR is unencrypted, then > > tomorrow my implementation talks to some new implementation that > > knows the IANA registry has changed to include XR and FOO, so both > > packet types are sent to me unencrypted when I don't expect it! > > > > This is not feasible. Security policies would be violated. >=20 > The alternative is to define that only XR packets can run=20 > un-encrypted and > every time new cases requiring other types to run un-encrypted show up > re-write the standard. This looks to un-flexible to me. >=20 > Note that security policies may require in some cases that even XR be > encrypted. In the enterprise space I can assure you that requiring end > devices to transmit data unencrypted over Service Providers=20 > backbones may be > a problem, because one is trading security for monitoring.=20 > That's why I > believe that we need anyway some means of refusing to receive=20 > un-encrypted > packets of a certain type - for example do not start sending=20 > un-encrypted > packets until you received the information from the other end that it > intends to do the same. >=20 > > > > -- Steve > > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 14 18:45:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05788 for ; Tue, 14 Dec 2004 18:45:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeMUJ-0002mx-5n for mmusic-web-archive@ietf.org; Tue, 14 Dec 2004 18:53:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeMHL-00032W-Ld; Tue, 14 Dec 2004 18:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeMCo-0002Yj-UY for mmusic@megatron.ietf.org; Tue, 14 Dec 2004 18:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05306 for ; Tue, 14 Dec 2004 18:35:44 -0500 (EST) Received: from ns.live.com ([66.80.62.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeMKv-0002b0-C4 for mmusic@ietf.org; Tue, 14 Dec 2004 18:44:09 -0500 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.13.1/8.12.11) with ESMTP id iBENZfs7083415 for ; Tue, 14 Dec 2004 15:35:42 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.13.1/8.12.9/Submit) id iBENZf94083409; Tue, 14 Dec 2004 15:35:41 -0800 (PST) (envelope-from rsf) Message-Id: <6.2.0.14.1.20041214153026.02ce6eb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 14 Dec 2004 15:34:22 -0800 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [MMUSIC] FYI: Use port 8554 rather than port 7070 for RTSP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Many current RTSP server implementations use port 7070 for RTSP (in addition to the default RTSP port 554). Until recently, I had just assumed that 7070 was an 'official' alternate port number for RTSP. However, looking at the official IANA registry I discovered, to my surprise, that port 7070 is assigned to some other protocol: "ARCP". (I don't know what protocol this is.) Instead, port 8554 is assigned to RTSP: rtsp-alt 8554/tcp RTSP Alternate (see port 554) rtsp-alt 8554/udp RTSP Alternate (see port 554) I thought I'd mention this on this ("mmusic") mailing list, because it does not seem to be common knowledge. Ross. Ross Finlayson LIVE.COM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 15 08:12:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29035 for ; Wed, 15 Dec 2004 08:12:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeZ5u-0005HS-TP for mmusic-web-archive@ietf.org; Wed, 15 Dec 2004 08:21:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeYtZ-0004lh-VQ; Wed, 15 Dec 2004 08:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeYlG-0002Y6-0O for mmusic@megatron.ietf.org; Wed, 15 Dec 2004 08:00:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27932 for ; Wed, 15 Dec 2004 08:00:08 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeYtI-0004sx-S0 for mmusic@ietf.org; Wed, 15 Dec 2004 08:08:40 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBFCxvh5028461 for ; Wed, 15 Dec 2004 13:59:57 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 13:59:56 +0100 Received: from [147.214.97.151] (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XVCXV13C; Wed, 15 Dec 2004 13:59:56 +0100 Message-ID: <41C0354C.5080403@ericsson.com> Date: Wed, 15 Dec 2004 13:59:56 +0100 X-Sybari-Trust: 171f575d a5e9b67f 86440af6 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gonzalo Camarillo (JO/LMF)" Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt References: <41BECE64.3040401@ericsson.com> In-Reply-To: <41BECE64.3040401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2004 12:59:56.0737 (UTC) FILETIME=[FA242310:01C4E2A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC Working Group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi Gonzalo, The proposed changes looks fine. See below about point 3. Gonzalo Camarillo (JO/LMF) wrote: > > 3. Section 5. I am a bit worried about the offer/answer section. It is > > very unclear on the handling of this attribute. Can we really trust > > applications to define such behavior? From my work with Offer/Answer I > > sometimes find it difficult to get the right behavior out of SDP in > > offer/answer usage. If this behavior is left to the application then > > there is need for a much more explicit section that explains the > > different choices. Also I think using application defined behavior will > > result in quite divergent behavior. > > If this was an attribute that had any influence in the offer/answer > behabior I would agree with you. But this attribute, from the > offer/answer point of view, is just informational. That's why offerers > and answerers can use it as the wish. It does not have any influence in > the session being established. > > The behavior we expect applications to define would be something like, > "use the same label in the media line as in the XML document you are > using to describe your conference". Note that this attribute is always > for the remote's UA information, so, the values that this attribute > takes in an answer is completely independent from the value it takes in > the offer. > Okay, I do understand. I think it is okay with the current text. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 15 09:47:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04639 for ; Wed, 15 Dec 2004 09:47:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeaZn-0007QK-3V for mmusic-web-archive@ietf.org; Wed, 15 Dec 2004 09:56:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeaHn-0007Ls-1Z; Wed, 15 Dec 2004 09:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cea8Y-0005G2-SH for mmusic@megatron.ietf.org; Wed, 15 Dec 2004 09:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03467 for ; Wed, 15 Dec 2004 09:28:16 -0500 (EST) Received: from smtp7.clb.oleane.net ([213.56.31.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeaGn-0006wq-MS for mmusic@ietf.org; Wed, 15 Dec 2004 09:36:50 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp7.clb.oleane.net with ESMTP id iBFERe3J017135 for ; Wed, 15 Dec 2004 15:27:46 +0100 Message-Id: <200412151427.iBFERe3J017135@smtp7.clb.oleane.net> From: "Gunter" To: Date: Wed, 15 Dec 2004 15:27:45 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTisj5Yckoi/V7oR2CMKfbARYglzg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [MMUSIC] WiMAX Summit'05 - Paris - France X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2044683419==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. --===============2044683419== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E6_01C4E2BA.A0728270" This is a multi-part message in MIME format. ------=_NextPart_000_03E6_01C4E2BA.A0728270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . What is the business model for WiMAX? . What do we learn from earlier deployments? . What about the future extensions of the standard? . How is addressed the interoperability challenge? These questions, among others, will be addressed during the second edition of the WiMAX Summit to be organised in Paris next 5-8 April 2005. Get all details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_03E6_01C4E2BA.A0728270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

• = What is the business model for WiMAX?
• = What do we learn from earlier deployments?
• = What about the future extensions of the standard?
• = How is addressed the interoperability challenge?

These questions, among others, will be addressed during the second = edition of the WiMAX Summit to be organised in Paris next 5-8 April 2005.

 

Get all details = at:

http://www.u= pperside.fr/wimax05/wimax2005intro.htm

=

 

 

------=_NextPart_000_03E6_01C4E2BA.A0728270-- --===============2044683419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============2044683419==-- From mmusic-bounces@ietf.org Wed Dec 15 14:35:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01528 for ; Wed, 15 Dec 2004 14:35:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cef4J-0007cu-Mm for mmusic-web-archive@ietf.org; Wed, 15 Dec 2004 14:44:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceegu-0006OT-UE; Wed, 15 Dec 2004 14:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeYS-0004Em-MQ for mmusic@megatron.ietf.org; Wed, 15 Dec 2004 14:11:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29147 for ; Wed, 15 Dec 2004 14:11:18 -0500 (EST) Received: from webadmin.keyvoice.com ([12.153.69.6] helo=home.ringle.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceegj-0006wA-V1 for mmusic@ietf.org; Wed, 15 Dec 2004 14:19:54 -0500 Received: by home.ringle.org (Postfix, from userid 501) id 41ECAB86B9; Wed, 15 Dec 2004 14:10:44 -0500 (EST) From: Jon Ringle To: Jonathan Rosenberg Date: Wed, 15 Dec 2004 14:10:43 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412151410.43989.ml-mmusic@ringle.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: [MMUSIC] ICE-03 minor typos X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ml-mmusic@ringle.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Some minor typos in the ICE-03 draft. Jon --- draft-ietf-mmusic-ice-03.txt 2004-11-09 10:49:40.000000000 -0500 +++ draft-ietf-mmusic-ice-03.txt.jon 2004-12-15 14:07:00.000000000 -0500 @@ -306,7 +306,7 @@ Transport Address: The combination of an IP address and port. - Local Transport Address: A local transport address a transport + Local Transport Address: A local transport address is a transport address that has been allocated from the operating system on the host. This includes transport addresses obtained through Virtual Private Networks (VPNs) and transport addresses obtained through @@ -1054,7 +1054,7 @@ (although that fact is not signaled in the message). The usernames and passwords for these transport addresses are shown in Figure 3. The initiate message is sent to the responder. The responder has a - local transport address (10.0.1.76:43443), and a a STUN derived + local transport address (10.0.1.76:43443), and a STUN derived transport address (192.0.2.64:54766) derived from (10.0.1.76:43444). Call these two local transport addresses X and Y respectively. The @@ -2077,7 +2077,7 @@ Attribute Name: candidate - Long Form: candidiate + Long Form: candidate Type of Attribute: media level _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 17 08:22:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16384 for ; Fri, 17 Dec 2004 08:22:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfICr-0004P8-2O for mmusic-web-archive@ietf.org; Fri, 17 Dec 2004 08:31:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfI0g-0006kN-QY; Fri, 17 Dec 2004 08:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHvb-00066r-Ou for mmusic@megatron.ietf.org; Fri, 17 Dec 2004 08:13:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15539 for ; Fri, 17 Dec 2004 08:13:50 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfI4F-00046y-Ga for mmusic@ietf.org; Fri, 17 Dec 2004 08:22:48 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:63429) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CfHv1-0002o1-SE; Fri, 17 Dec 2004 13:13:15 +0000 In-Reply-To: <41C0354C.5080403@ericsson.com> References: <41BECE64.3040401@ericsson.com> <41C0354C.5080403@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6843E474-502D-11D9-8152-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-media-label-00.txt Date: Fri, 17 Dec 2004 13:13:13 +0000 To: Magnus Westerlund X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: "Gonzalo Camarillo \(JO/LMF\)" , IETF MMUSIC Working Group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit This last call ends today. It looks like there are minor issues to be resolved in an updated draft. Once the revised draft is available, we'll allow a short time to check that all comments have been addressed, then advance the draft. Colin On 15 Dec 2004, at 12:59, Magnus Westerlund wrote: > Hi Gonzalo, > > The proposed changes looks fine. See below about point 3. > > Gonzalo Camarillo (JO/LMF) wrote: >> > 3. Section 5. I am a bit worried about the offer/answer section. >> It is >> > very unclear on the handling of this attribute. Can we really trust >> > applications to define such behavior? From my work with >> Offer/Answer I >> > sometimes find it difficult to get the right behavior out of SDP in >> > offer/answer usage. If this behavior is left to the application >> then >> > there is need for a much more explicit section that explains the >> > different choices. Also I think using application defined behavior >> will >> > result in quite divergent behavior. >> If this was an attribute that had any influence in the offer/answer >> behabior I would agree with you. But this attribute, from the >> offer/answer point of view, is just informational. That's why offerers >> and answerers can use it as the wish. It does not have any influence >> in >> the session being established. >> The behavior we expect applications to define would be something like, >> "use the same label in the media line as in the XML document you are >> using to describe your conference". Note that this attribute is always >> for the remote's UA information, so, the values that this attribute >> takes in an answer is completely independent from the value it takes >> in >> the offer. > > Okay, I do understand. I think it is okay with the current text. > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 17 17:43:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22770 for ; Fri, 17 Dec 2004 17:43:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQxv-0001ZJ-6Y for mmusic-web-archive@ietf.org; Fri, 17 Dec 2004 17:52:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQVq-0000gh-N4; Fri, 17 Dec 2004 17:23:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQQE-0006VO-Cu; Fri, 17 Dec 2004 17:18:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19192; Fri, 17 Dec 2004 17:17:59 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQYw-0000J3-3n; Fri, 17 Dec 2004 17:27:02 -0500 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMHtkO004838 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Dec 2004 16:17:56 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de> References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81AAFAB1-5079-11D9-B702-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Fri, 17 Dec 2004 16:17:58 -0600 To: Joerg Ott X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Colin Perkins , Simple WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit On Dec 12, 2004, at 5:58 AM, Joerg Ott wrote: > I agree with Colin on the ugliness issue of decomposing URLs into > c= and m= lines. But this is the way SDP has worked and works today. > > The present discussion we are having here is about changing SDP to > for address/URL handling in one particular case. This does not > strike me as something MSRP should be concerned with. > > I would like to make one thing clear: we are either using existing > tools > in another document or we are building new ones. There is nothing much > in between. > > Changing c=/m= semantics means changing SDP. Just because the syntax > still looks the same does not mean that it is still the same protocol. > Any entity or generic protocol engine used to dealing with SDP m=/c= > would no longer do the right thing. > > We see this kind of approach quite often -- by far too often -- over > the past years (just think the many "uses" of SIP defined elsewhere, > usually resulting in something "a little but not entirely unlike" SIP). > > What I would like avoid is having special treatment of SDP depending > on what the media type is (or other attributes signify). > > Therefore, I strongly agree with Colin's conclusion: take SDP as is > or leave it altogether and pursue a different path. > I am sensitive to the philosophical desire to keep things pure, but on the pragmatic side this seems to me to be a false dichotomy. We extend protocols all the time, for good or ill. Can you describe specific interoperability problems that would be introduced by the MSRP usage as currently described? How about this as a potential compromise: We keep the path attribute as is, but _also_ copy the information for the endpoint into the m and c lines. This would seem to me to be consistent with the usage in the current ICE draft, in which ICE aware endpoints use the candidate attributes to determine the address and port, but the default address and port are copied into the m and c line for backwards compatibility? Considering that the ICE need for backwards compatibility seems much more clear than the MSRP need for the same? > Joerg > > > Colin Perkins wrote: > >> On 10 Dec 2004, at 21:41, Ben Campbell wrote: >>> I really need to get closure on this, so I'd appreciate people >>> agreeing or disagreeing. >>> >>> I have had off-list correspondence indicating both positions. In >>> summary: >>> >>> In favor of the change, I had a comment to the effect that changing >>> SDP semantics to ignore the C line and the port field on the M line >>> really changes it to something that is no longer SDP, and that such >>> deviations are in general bad for interop. >>> >>> In favor of leaving things as currently specified, I had two >>> comments that decomposing URLs into the C and M lines is ugly, and >>> that having a different mechanism to communicate endpoint addresses >>> vs relay addresses is really ugly. >>> >>> So, do people agree with one or the other position? >> Decomposing the URL into the "c=" and "m=" lines is very ugly. >> Unfortunately, that ugliness is required if you want to use SDP. This >> is why the SDPng work was started, to try to move to something less >> horrible... >> Colin >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 17 17:45:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22907 for ; Fri, 17 Dec 2004 17:45:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQyv-0001cD-Kv for mmusic-web-archive@ietf.org; Fri, 17 Dec 2004 17:54:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQW4-0000lm-Vn; Fri, 17 Dec 2004 17:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfQRi-00076V-S3; Fri, 17 Dec 2004 17:19:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19366; Fri, 17 Dec 2004 17:19:32 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQaR-0000Mk-20; Fri, 17 Dec 2004 17:28:35 -0500 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBHMJTRd005000 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Dec 2004 16:19:30 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Fri, 17 Dec 2004 16:19:31 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Joerg Ott , Colin Perkins , Simple WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit On Dec 13, 2004, at 3:10 AM, Hisham Khartabil wrote: > (not as chair, but as an MSRP protocol contributor) > > The objection to using the SDP c and m lines is not purely a cosmetic > objection. We are not saying that SDP the way it is defined today is > ugly so we want to rearrange it to look better. > > We have a fundamental objection: having 2 ways to construct a next hop > URI that depends on the entity that is the next hop is not acceptable. > Endpoints should not be required to have 2 engines implemented. > Unless we are given an alternative that allows endpoint implementers > to implement one piece of code for constructing an next hop MSRP URI, > I'm afraid we have no choice but to keep what we have today in MSRP as > is. > I think Hisham expressed my concern much more precisely than I previously expressed it. This is exactly what I was trying to say. > You telling us to go find another protocol if we don't like SDP the > way it is today is hardly contructive. SDPng is not an option and we > call know it. > > Let me add that comedia also violates what you claim to be a > fundamental piece of the protocol that if broken will cause the SDP > protocol not to be SDP any longer. An argument that I don't buy. We > have violated things before: > > - t= line does not mean anything in SIP and is set to 0 0 (which in > SDP means that the session is permanent and unbounded). > - s= line carries session name. It is set to - when used with SIP. > > Also, quoting the SDP draft: > > "For unicast IP sessions, the following are conveyed: > > o The remote address for media > > o The remote transport port for media > > The semantics of this address and port depend on the media and > transport protocol defined. By default, this SHOULD be the remote > address and remote port to which data is sent. Some media types MAY > redefine this behaviour, but this is NOT RECOMMENDED." > > We are changing the semantics. As far as I understand from the quoted > paragraph above, we are not violating anything, even-though it is not > recommended. > > I have a question to SDP stack implementers that plan to implement > MSRP: Does the current way MSRP specifies the use of SDP (ignore the c > line address and the m line port and instead use the attribute a=path) > cause problems to you and requires you to do some hacking in your SDP > stack? If so, is that acceptable or do you prefer for your MSRP > implementation to implement two ways of contructing an MSRP URL > depending on the what the next hop is? > > Regards, > Hisham > > On Dec 12, 2004, at 12:58 PM, Joerg Ott wrote: > >> I agree with Colin on the ugliness issue of decomposing URLs into >> c= and m= lines. But this is the way SDP has worked and works today. >> >> The present discussion we are having here is about changing SDP to >> for address/URL handling in one particular case. This does not >> strike me as something MSRP should be concerned with. >> >> I would like to make one thing clear: we are either using existing >> tools >> in another document or we are building new ones. There is nothing >> much >> in between. >> >> Changing c=/m= semantics means changing SDP. Just because the syntax >> still looks the same does not mean that it is still the same protocol. >> Any entity or generic protocol engine used to dealing with SDP m=/c= >> would no longer do the right thing. >> >> We see this kind of approach quite often -- by far too often -- over >> the past years (just think the many "uses" of SIP defined elsewhere, >> usually resulting in something "a little but not entirely unlike" >> SIP). >> >> What I would like avoid is having special treatment of SDP depending >> on what the media type is (or other attributes signify). >> >> Therefore, I strongly agree with Colin's conclusion: take SDP as is >> or leave it altogether and pursue a different path. >> >> Joerg >> >> >> Colin Perkins wrote: >> >>> On 10 Dec 2004, at 21:41, Ben Campbell wrote: >>>> I really need to get closure on this, so I'd appreciate people >>>> agreeing or disagreeing. >>>> >>>> I have had off-list correspondence indicating both positions. In >>>> summary: >>>> >>>> In favor of the change, I had a comment to the effect that changing >>>> SDP semantics to ignore the C line and the port field on the M line >>>> really changes it to something that is no longer SDP, and that such >>>> deviations are in general bad for interop. >>>> >>>> In favor of leaving things as currently specified, I had two >>>> comments that decomposing URLs into the C and M lines is ugly, and >>>> that having a different mechanism to communicate endpoint addresses >>>> vs relay addresses is really ugly. >>>> >>>> So, do people agree with one or the other position? >>> Decomposing the URL into the "c=" and "m=" lines is very ugly. >>> Unfortunately, that ugliness is required if you want to use SDP. >>> This is why the SDPng work was started, to try to move to something >>> less horrible... >>> Colin >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 18 13:19:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06672 for ; Sat, 18 Dec 2004 13:19:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfjJt-0000Mm-8K for mmusic-web-archive@ietf.org; Sat, 18 Dec 2004 13:28:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cfj6Y-0001pu-T5; Sat, 18 Dec 2004 13:14:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cfj4X-0000M6-AO; Sat, 18 Dec 2004 13:12:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06057; Sat, 18 Dec 2004 13:12:50 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfjDP-0000BS-O1; Sat, 18 Dec 2004 13:22:05 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2004 10:16:59 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBIICHHn027276; Sat, 18 Dec 2004 10:12:18 -0800 (PST) Received: from cisco.com (rtp-vpn2-121.cisco.com [10.82.240.121]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANU77671; Sat, 18 Dec 2004 13:12:15 -0500 (EST) Message-ID: <41C472FF.7020308@cisco.com> Date: Sat, 18 Dec 2004 13:12:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Ridler Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, "'Joerg Ott'" , "'Colin Perkins'" , "'Simple WG'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Peter Ridler wrote: > I also agree with Colin and Joerg. > > I will also have two SDP parse engines (one for RTP and another for MSRP). Do you currently support anything but RTP? How much do you expect to share between the two in the best case? I don't think you are really talking about the parser - that isn't what is different. I think you are talking about implementing the connection semantics represented by the SDP. No matter what you do, these are different for RTP and MSRP. The SDP parser that I have worked with is quite capable of handling this either way. It is only involved with the *syntax* of SDP. Note that the syntax of SDP is already quite a mallable thing. Much of the important syntax is hidden in a-lines. MSRP has its own a-lines, and these need to be parsed in any case. > This will complicate the code. Computers do not care about ugly formatting > --- overall performance should be the concern (I think all text formatted > protocols are a waste of network bandwidth and memory resources -- but I'm > stuck with them). > > We should follow the standards as best we can. If the standard does not > meet your requirements then define/use another. Can you suggest what you have in mind? Its not like this is an independent decision for MSRP. MSRP is intended to be negotiated via SIP. And it isn't a matter of mutual exclusion - negotiate MSRP with sip and something other than SDP, negotiate RPT with sip and SDP - I expect to be negotiating *both* MSRP and RPT with the same sip offer/answer exchange. It seems you must have SDPng in mind. So you are suggesting we can't finish MSRP until the migration to SDPng is complete? > Another text based protocol is draft-ietf-sipping-toip-00.txt This fits the > SIP/SDP model nicely. It fits because it runs over RTP. It doesn't meet our requirements. It feels like you are trying to make the SDP tail wag the SIP dog. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 19 11:53:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13977 for ; Sun, 19 Dec 2004 11:53:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cg4S6-0005QB-7H for mmusic-web-archive@ietf.org; Sun, 19 Dec 2004 12:02:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4Hf-00065P-Jt; Sun, 19 Dec 2004 11:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg4Gt-0005v5-Mm for mmusic@megatron.ietf.org; Sun, 19 Dec 2004 11:51:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13937 for ; Sun, 19 Dec 2004 11:51:00 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cg4Py-0005NL-Or for mmusic@ietf.org; Sun, 19 Dec 2004 12:00:27 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id iBJGonK1004765; Sun, 19 Dec 2004 17:50:55 +0100 (MET) Message-ID: <41C5B167.1050203@tzi.uni-bremen.de> Date: Sun, 19 Dec 2004 17:50:47 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Colin Perkins Subject: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit This is to announce Working Group Last Call on the revised SDP specification "SDP: Session Description Protocol" recently published as draft-ietf-mmusic-sdp-new-23.txt The document shall be advanced to Proposed Standard (PS). The WGLC is to end on 9 January 2005. Please review the latest draft carefully and direct all comments to the MMUSIC list and the authors. Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 19 17:49:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16882 for ; Sun, 19 Dec 2004 17:49:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgA0i-0005Ly-49 for mmusic-web-archive@ietf.org; Sun, 19 Dec 2004 17:58:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg9ia-0003Q3-So; Sun, 19 Dec 2004 17:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg9hd-0003FA-DN; Sun, 19 Dec 2004 17:39:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16292; Sun, 19 Dec 2004 17:38:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cg9ql-00057l-T0; Sun, 19 Dec 2004 17:48:28 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Dec 2004 15:46:02 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBJMcQHn021734; Sun, 19 Dec 2004 14:38:27 -0800 (PST) Received: from [66.103.196.117] (sjc-vpn4-290.cisco.com [10.21.81.34]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW66663; Sun, 19 Dec 2004 14:38:24 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 19 Dec 2004 14:38:22 -0800 Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern From: Cullen Jennings To: Peter Ridler , "'Joerg Ott'" , "'Colin Perkins'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" , "mmusic@ietf.org" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit I think that the MSRP folks have not clearly explained what we want to do in SDP. We want to set up a path of multiple addresses, not just a single address for one far end. That the protocol uses TCP or that it transports text instead of audio I don't think should cause it to be much different. On 12/18/04 7:16 AM, "Peter Ridler" wrote: > > I also agree with Colin and Joerg. > > I will also have two SDP parse engines (one for RTP and another for MSRP). > This will complicate the code. Computers do not care about ugly formatting > --- overall performance should be the concern (I think all text formatted > protocols are a waste of network bandwidth and memory resources -- but I'm > stuck with them). > > We should follow the standards as best we can. If the standard does not > meet your requirements then define/use another. > > Another text based protocol is draft-ietf-sipping-toip-00.txt This fits the > SIP/SDP model nicely. > > Peter > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott >> Sent: Sunday, December 12, 2004 6:58 AM >> To: Colin Perkins >> Cc: Simple WG; mmusic@ietf.org >> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern >> >> I agree with Colin on the ugliness issue of decomposing URLs >> into c= and m= lines. But this is the way SDP has worked and >> works today. >> >> The present discussion we are having here is about changing >> SDP to for address/URL handling in one particular case. This >> does not strike me as something MSRP should be concerned with. >> >> I would like to make one thing clear: we are either using >> existing tools in another document or we are building new >> ones. There is nothing much in between. >> >> Changing c=/m= semantics means changing SDP. Just because >> the syntax still looks the same does not mean that it is >> still the same protocol. >> Any entity or generic protocol engine used to dealing with >> SDP m=/c= would no longer do the right thing. >> >> We see this kind of approach quite often -- by far too often >> -- over the past years (just think the many "uses" of SIP >> defined elsewhere, usually resulting in something "a little >> but not entirely unlike" SIP). >> >> What I would like avoid is having special treatment of SDP >> depending on what the media type is (or other attributes signify). >> >> Therefore, I strongly agree with Colin's conclusion: take SDP >> as is or leave it altogether and pursue a different path. >> >> Joerg >> >> >> Colin Perkins wrote: >> >>> On 10 Dec 2004, at 21:41, Ben Campbell wrote: >>> >>>> I really need to get closure on this, so I'd appreciate people >>>> agreeing or disagreeing. >>>> >>>> I have had off-list correspondence indicating both >> positions. In summary: >>>> >>>> In favor of the change, I had a comment to the effect that >> changing >>>> SDP semantics to ignore the C line and the port field on >> the M line >>>> really changes it to something that is no longer SDP, and >> that such >>>> deviations are in general bad for interop. >>>> >>>> In favor of leaving things as currently specified, I had >> two comments >>>> that decomposing URLs into the C and M lines is ugly, and >> that having >>>> a different mechanism to communicate endpoint addresses vs relay >>>> addresses is really ugly. >>>> >>>> So, do people agree with one or the other position? >>> >>> >>> Decomposing the URL into the "c=" and "m=" lines is very ugly. >>> Unfortunately, that ugliness is required if you want to use >> SDP. This >>> is why the SDPng work was started, to try to move to something less >>> horrible... >>> >>> Colin >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 19 19:38:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25955 for ; Sun, 19 Dec 2004 19:38:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgBi0-0008Bs-VZ for mmusic-web-archive@ietf.org; Sun, 19 Dec 2004 19:47:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgBXo-00032w-Ew; Sun, 19 Dec 2004 19:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgBVd-0002Tn-Bu for mmusic@megatron.ietf.org; Sun, 19 Dec 2004 19:34:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25641 for ; Sun, 19 Dec 2004 19:34:41 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgBem-00083i-OH for mmusic@ietf.org; Sun, 19 Dec 2004 19:44:13 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBK0Xak24262; Sun, 19 Dec 2004 19:33:36 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 19 Dec 2004 19:33:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF01347A35@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'mmusic@ietf.org'" , "'van@packetdesign.com'" , "'M.Handley@cs.ucl.ac.uk'" , "'Colin Perkins'" Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt Date: Sun, 19 Dec 2004 19:33:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: "'Cullen Jennings'" , "'Joerg Ott'" , "'Stephen Casner'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1630229395==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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. --===============1630229395== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E62B.879816CB" 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_01C4E62B.879816CB Content-Type: text/plain I would like to request a clarification in section 5.14 of draft-ietf-mmusic-sdp-new-23. As we discovered in BEHAVE, certain SDP implementations are misinterpretting RFC 3550 section 11 2nd paragraph. In a SIP Offer/Answer for example, these implementations unilaterally change an odd RTP port indicated in an SDP (from the other end) with to the even port that one lower. In other words, if the other end indicates an RTP port of 5201, these implemenations will send RTP to 5200, which will be a big problem. Note that this issue is slightly orthogonal to the use of the rtcp attribute of RFC 3605. For example, if an application discovers (with STUN or ICE) that its RTP port is 5201, it may then discover that it's RTCP port is 5202 (which would satisfy the contiguity rule). This is very likely to happen because NATs typically assign ports sequentially. An application could (somewhat foolishlingly) not use RFC 3605 in this case because it follows the contiguity rule (but not the parity rule). Another issue is for implementations that do not support RTCP in the first place. In order to avoid these problems, I propose that we explicitly state that the for RTP indicates the actual port and MUST not be changed regardless of parity (i.e., DO NOT substract 1 if it is odd). I believe that would finally put to rest this parity issue for all SDP-based protocols. Also, on a similar note, would it make sense to incorporate RFC 3605 (the directly into sdp-new, instead of having it stand as a separate RFC) and make its support mandatory? The biggest problem with RFC 3605 is that I can do the best SIP/SDP implementation possible, support STUN, ICE, 3605 and all, but if the other end doesn't support 3605 (because they don't even know of NATs), the problem above will still occur. > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Joerg Ott > Sent: Sunday, December 19, 2004 08:51 > To: mmusic@ietf.org > Cc: Colin Perkins > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt > > > This is to announce Working Group Last Call on the revised > SDP specification "SDP: Session Description Protocol" > recently published as > > draft-ietf-mmusic-sdp-new-23.txt > > The document shall be advanced to Proposed Standard (PS). > > The WGLC is to end on 9 January 2005. > > Please review the latest draft carefully and direct all > comments to the MMUSIC list and the authors. > > Joerg > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > ------_=_NextPart_001_01C4E62B.879816CB Content-Type: text/html RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt

I would like to request a clarification in section 5.14 of
draft-ietf-mmusic-sdp-new-23.

As we discovered in BEHAVE, certain SDP implementations are misinterpretting
RFC 3550 section 11 2nd paragraph. In a SIP Offer/Answer for example, these
implementations unilaterally change an odd RTP port indicated in an SDP (from the
other end) with to the even port that one lower. In other words, if the other end
indicates an RTP port of 5201, these implemenations will send RTP to 5200, which will
be a big problem.

Note that this issue is slightly orthogonal to the use of the rtcp attribute of
RFC 3605. For example, if an application discovers (with STUN or ICE) that its
RTP port is 5201, it may then discover that it's RTCP port is 5202 (which would
satisfy the contiguity rule). This is very likely to happen because NATs typically
assign ports sequentially. An application could (somewhat foolishlingly) not
use RFC 3605 in this case because it follows the contiguity rule (but not the parity
rule).

Another issue is for implementations that do not support RTCP in the first place.

In order to avoid these problems, I propose that we explicitly state that
the <port> for RTP indicates the actual port and MUST not be changed regardless of
parity (i.e., DO NOT substract 1 if it is odd).

I believe that would finally put to rest this parity issue for all SDP-based
protocols.

Also, on a similar note, would it make sense to incorporate RFC 3605 (the  directly into
sdp-new, instead of having it stand as a separate RFC) and make its support mandatory?
The biggest problem with RFC 3605 is that I can do the best SIP/SDP
implementation possible, support STUN, ICE, 3605 and all, but if the other end doesn't
support 3605 (because they don't even know of NATs), the problem above will still occur.


> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Joerg Ott
> Sent: Sunday, December 19, 2004 08:51
> To: mmusic@ietf.org
> Cc: Colin Perkins
> Subject: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt
>
>
> This is to announce Working Group Last Call on the revised
> SDP specification "SDP: Session Description Protocol"
> recently published as
>
>      draft-ietf-mmusic-sdp-new-23.txt
>
> The document shall be advanced to Proposed Standard (PS).
>
> The WGLC is to end on 9 January 2005.
>
> Please review the latest draft carefully and direct all
> comments to the MMUSIC list and the authors.
>
> Joerg
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>

------_=_NextPart_001_01C4E62B.879816CB-- --===============1630229395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1630229395==-- From mmusic-bounces@ietf.org Sun Dec 19 19:55:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27079 for ; Sun, 19 Dec 2004 19:55:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgByt-00009t-SB for mmusic-web-archive@ietf.org; Sun, 19 Dec 2004 20:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgBnM-00052U-3r; Sun, 19 Dec 2004 19:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgBmT-0004r4-NA; Sun, 19 Dec 2004 19:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26824; Sun, 19 Dec 2004 19:52:05 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgBvc-00005A-HL; Sun, 19 Dec 2004 20:01:37 -0500 Received: from razor.cs.columbia.edu (IDENT:l59pBPtYDVv9VpBx8lxed6W9cGXQDz/3@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBK0q5e9003931 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 19 Dec 2004 19:52:05 -0500 (EST) Received: from [127.0.0.1] (IDENT:6ixMjLMhlTNMDEER1LRwoBQUPKmr7ISW@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBK0q4U3007110; Sun, 19 Dec 2004 19:52:04 -0500 Message-ID: <41C62240.5070202@cs.columbia.edu> Date: Sun, 19 Dec 2004 19:52:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.12.18.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Maximum non-scaled image size X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Do any video payload formats specify, as SDP format attributes or otherwise, the maximum image size supported natively (i.e., without downscaling)? For a draft we're working on, I'd like to re-use any existing conventions. In general, it would seem useful to know this since there isn't much point in sending at a higher resolution than the screen resolution or the maximum size that an application can handle. This seems like a natural extension to a=framerate in SDP. Henning _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 02:41:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07710 for ; Mon, 20 Dec 2004 02:41:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgIJX-0000nN-8B for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 02:50:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI95-0007On-Sw; Mon, 20 Dec 2004 02:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI86-0007E7-8R; Mon, 20 Dec 2004 02:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07589; Mon, 20 Dec 2004 02:38:52 -0500 (EST) Received: from fep15.012.net.il ([212.117.129.240]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgIHI-0000kI-KM; Mon, 20 Dec 2004 02:48:25 -0500 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by fep15.012.net.il with ESMTP id <20041220073611.ZLO5205.fep15@isrexch01.israel.polycom.com>; Mon, 20 Dec 2004 09:36:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Maximum non-scaled image size Date: Mon, 20 Dec 2004 09:32:21 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C921901@IsrExch01.israel.polycom.com> Thread-Topic: [MMUSIC] Maximum non-scaled image size Thread-Index: AcTmLtRxkdMT/ytaQ8+WhE+BIblXUwANKIQA From: "Even, Roni" To: "Henning Schulzrinne" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Henning, In the bis drafts for the H.263 and H.261 I added the support for specifying the image size that the decoder can receive per frame rate. For H.261 the support is for fixed resolutions for H.263 the support is also for custom formats. See draft-ietf-avt-rfc2429-bis-03.txt and draft-ietf-avt-rfc2032-bis-03.txt In the H.264, see draft-ietf-avt-rtp-h264-11, the concept was that the decoder, using the level parameter, specifies the number of macro blocks per second it can process; The level as specified in H.264 gives a maximum on the frame rate and resolution. The level parameters can be overridden by the optional parameters specified in the draft. The transformation from the decoder to the display is up to the implementer. =20 As can be seen in H.261 and H.263 the SDP from the receiver can specify an exact picture size(resolution)it can receive, but still the encoder can send any allowed picture size that is bellow the decoder capability. For example in H.261 if the decoder specifies it can receive a CIF picture at 30 fps, the encoder can send a QCIF picture at 15 fps.=20 In H.264 there is no explicit resolution specified. Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 20, 2004 2:52 AM To: avt@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Maximum non-scaled image size Do any video payload formats specify, as SDP format attributes or=20 otherwise, the maximum image size supported natively (i.e., without=20 downscaling)? For a draft we're working on, I'd like to re-use any existing=20 conventions. In general, it would seem useful to know this since there=20 isn't much point in sending at a higher resolution than the screen=20 resolution or the maximum size that an application can handle. This=20 seems like a natural extension to a=3Dframerate in SDP. Henning _______________________________________________ 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-bounces@ietf.org Mon Dec 20 04:24:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13970 for ; Mon, 20 Dec 2004 04:24:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJvs-0003GG-Ui for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 04:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJhl-00034Y-Pb; Mon, 20 Dec 2004 04:19:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJfS-0002jE-Pl; Mon, 20 Dec 2004 04:17:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13514; Mon, 20 Dec 2004 04:17:24 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJof-00032v-Ss; Mon, 20 Dec 2004 04:26:58 -0500 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Mon, 20 Dec 2004 18:15:18 +0900 Received: from spam.etri.re.kr ([129.254.16.120]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Dec 2004 16:46:12 +0900 Received: (snipe 10353 invoked by alias); 20 Dec 2004 16:39:53 +0900 Received: from avt-bounces@ietf.org with Spamsniper 2.83.27 (Processed in 0.776181 secs); Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by unknown with SMTP; 20 Dec 2004 16:39:52 +0900 X-RCPTTO: tjlee@etri.re.kr, mrpark@etri.re.kr Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI96-0007P4-TB; Mon, 20 Dec 2004 02:39:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI86-0007E7-8R; Mon, 20 Dec 2004 02:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07589; Mon, 20 Dec 2004 02:38:52 -0500 (EST) Received: from fep15.012.net.il ([212.117.129.240]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgIHI-0000kI-KM; Mon, 20 Dec 2004 02:48:25 -0500 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by fep15.012.net.il with ESMTP id <20041220073611.ZLO5205.fep15@isrexch01.israel.polycom.com>; Mon, 20 Dec 2004 09:36:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2004 09:32:21 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C921901@IsrExch01.israel.polycom.com> Thread-Topic: [MMUSIC] Maximum non-scaled image size Thread-Index: AcTmLtRxkdMT/ytaQ8+WhE+BIblXUwANKIQA From: "Even, Roni" To: "Henning Schulzrinne" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: [MMUSIC] Maximum non-scaled image size X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Dec 2004 07:46:12.0724 (UTC) FILETIME=[FA387340:01C4E667] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: mmusic@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Henning, In the bis drafts for the H.263 and H.261 I added the support for specifying the image size that the decoder can receive per frame rate. For H.261 the support is for fixed resolutions for H.263 the support is also for custom formats. See draft-ietf-avt-rfc2429-bis-03.txt and draft-ietf-avt-rfc2032-bis-03.txt In the H.264, see draft-ietf-avt-rtp-h264-11, the concept was that the decoder, using the level parameter, specifies the number of macro blocks per second it can process; The level as specified in H.264 gives a maximum on the frame rate and resolution. The level parameters can be overridden by the optional parameters specified in the draft. The transformation from the decoder to the display is up to the implementer. =20 As can be seen in H.261 and H.263 the SDP from the receiver can specify an exact picture size(resolution)it can receive, but still the encoder can send any allowed picture size that is bellow the decoder capability. For example in H.261 if the decoder specifies it can receive a CIF picture at 30 fps, the encoder can send a QCIF picture at 15 fps.=20 In H.264 there is no explicit resolution specified. Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 20, 2004 2:52 AM To: avt@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Maximum non-scaled image size Do any video payload formats specify, as SDP format attributes or=20 otherwise, the maximum image size supported natively (i.e., without=20 downscaling)? For a draft we're working on, I'd like to re-use any existing=20 conventions. In general, it would seem useful to know this since there=20 isn't much point in sending at a higher resolution than the screen=20 resolution or the maximum size that an application can handle. This=20 seems like a natural extension to a=3Dframerate in SDP. Henning _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 04:26:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14103 for ; Mon, 20 Dec 2004 04:26:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJxM-0003Jr-HM for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 04:35:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJi0-0003AB-Uo; Mon, 20 Dec 2004 04:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJfp-0002ka-GF; Mon, 20 Dec 2004 04:17:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13540; Mon, 20 Dec 2004 04:17:47 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJp3-00032v-Dm; Mon, 20 Dec 2004 04:27:22 -0500 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Mon, 20 Dec 2004 18:15:18 +0900 Received: from spam.etri.re.kr ([129.254.16.120]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Dec 2004 16:46:12 +0900 Received: (snipe 10353 invoked by alias); 20 Dec 2004 16:39:53 +0900 Received: from avt-bounces@ietf.org with Spamsniper 2.83.27 (Processed in 0.776181 secs); Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by unknown with SMTP; 20 Dec 2004 16:39:52 +0900 X-RCPTTO: tjlee@etri.re.kr, mrpark@etri.re.kr Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI96-0007P4-TB; Mon, 20 Dec 2004 02:39:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgI86-0007E7-8R; Mon, 20 Dec 2004 02:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07589; Mon, 20 Dec 2004 02:38:52 -0500 (EST) Received: from fep15.012.net.il ([212.117.129.240]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgIHI-0000kI-KM; Mon, 20 Dec 2004 02:48:25 -0500 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by fep15.012.net.il with ESMTP id <20041220073611.ZLO5205.fep15@isrexch01.israel.polycom.com>; Mon, 20 Dec 2004 09:36:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2004 09:32:21 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C921901@IsrExch01.israel.polycom.com> Thread-Topic: [MMUSIC] Maximum non-scaled image size Thread-Index: AcTmLtRxkdMT/ytaQ8+WhE+BIblXUwANKIQA From: "Even, Roni" To: "Henning Schulzrinne" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: [MMUSIC] Maximum non-scaled image size X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Dec 2004 07:46:12.0724 (UTC) FILETIME=[FA387340:01C4E667] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: mmusic@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Henning, In the bis drafts for the H.263 and H.261 I added the support for specifying the image size that the decoder can receive per frame rate. For H.261 the support is for fixed resolutions for H.263 the support is also for custom formats. See draft-ietf-avt-rfc2429-bis-03.txt and draft-ietf-avt-rfc2032-bis-03.txt In the H.264, see draft-ietf-avt-rtp-h264-11, the concept was that the decoder, using the level parameter, specifies the number of macro blocks per second it can process; The level as specified in H.264 gives a maximum on the frame rate and resolution. The level parameters can be overridden by the optional parameters specified in the draft. The transformation from the decoder to the display is up to the implementer. =20 As can be seen in H.261 and H.263 the SDP from the receiver can specify an exact picture size(resolution)it can receive, but still the encoder can send any allowed picture size that is bellow the decoder capability. For example in H.261 if the decoder specifies it can receive a CIF picture at 30 fps, the encoder can send a QCIF picture at 15 fps.=20 In H.264 there is no explicit resolution specified. Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 20, 2004 2:52 AM To: avt@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Maximum non-scaled image size Do any video payload formats specify, as SDP format attributes or=20 otherwise, the maximum image size supported natively (i.e., without=20 downscaling)? For a draft we're working on, I'd like to re-use any existing=20 conventions. In general, it would seem useful to know this since there=20 isn't much point in sending at a higher resolution than the screen=20 resolution or the maximum size that an application can handle. This=20 seems like a natural extension to a=3Dframerate in SDP. Henning _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 05:30:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17650 for ; Mon, 20 Dec 2004 05:30:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgKxr-0004j4-Bd for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 05:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgKmd-0003Mg-Am; Mon, 20 Dec 2004 05:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgKm7-0003Gr-Te for mmusic@megatron.ietf.org; Mon, 20 Dec 2004 05:28:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17448 for ; Mon, 20 Dec 2004 05:28:21 -0500 (EST) Received: from vs.informatik.uni-ulm.de ([134.60.77.243]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgKvM-0004fD-Hc for mmusic@ietf.org; Mon, 20 Dec 2004 05:37:57 -0500 Received: from localhost (sikanda [127.0.0.1]) by vs.informatik.uni-ulm.de (Postfix) with ESMTP id 655AE3E430F for ; Mon, 20 Dec 2004 11:27:51 +0100 (CET) Received: from vs.informatik.uni-ulm.de ([127.0.0.1]) by localhost (sikanda [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13599-10 for ; Mon, 20 Dec 2004 11:27:48 +0100 (CET) Received: from vs.informatik.uni-ulm.de (discovery.informatik.uni-ulm.de [134.60.77.113]) by vs.informatik.uni-ulm.de (Postfix) with ESMTP id 3B7523E430D for ; Mon, 20 Dec 2004 11:27:48 +0100 (CET) Message-ID: <41C6AA71.80304@vs.informatik.uni-ulm.de> Date: Mon, 20 Dec 2004 11:33:21 +0100 From: Teodora Guenkova-Luy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, de MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] Maximum non-scaled image size Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at vs.informatik.uni-ulm.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >Do any video payload formats specify, as SDP format attributes or >otherwise, the maximum image size supported natively (i.e., without >downscaling)? ------------------------------------------------------------------------- Dear All, The ITU-T standards (e.g. H.261, H.263, H.264, etc.) explicitly specify image sizes for the codecs. H.261 and H.263 specify image sizes according to ITU CIF standard in form of (height x width) resolution. H.264 also specifies max image sizes per used profile level in form of max bits per image, but without specifying aspect ratios. From the MPEG standards only MPEG-1 specifies max image size of 352x240 height x width resolution. All the other Video MPEGs are with arbitrary image sizes. Another possibility to specify image sizes are the VESA standards from www.vesa.org (e.g. VESA's VGA BIOS Extensions). Note, that some standards for video specify frame-rate, frame-size and colour-quality dependencies. Hence, using some standard definitions might influence all of these 3 parameters, i.e. the colour-quality (number of colours per image) might also influence the amount of network data for the video streams. Note, that frame-size can be specified in 3 different manners: - (height x width) resolution in (pixel x pixel) - standard - i.e. CIF or VESA - max number of bits + aspect ratio - e.g. commonly used aspect ratios are height: width = 4:3, 5:4, 11:9, 16:9, 16:10. These aspect ratios stem also from CIF and VESA For the complete and unique video performance specification with SDP in case of arbitrary video image specification one needs to have specifications for frame-rate, frame-size and colour-quality. Best Regards, Teodora Guenkova-Luy _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 08:31:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27547 for ; Mon, 20 Dec 2004 08:31:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgNmL-0000GJ-Bq for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 08:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNWT-0002nl-IF; Mon, 20 Dec 2004 08:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfgKr-0001ug-FP; Sat, 18 Dec 2004 10:17:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24295; Sat, 18 Dec 2004 10:17:30 -0500 (EST) Received: from bayc1-pasmtp03.bayc1.hotmail.com ([65.54.191.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfgTi-0005BQ-KC; Sat, 18 Dec 2004 10:26:43 -0500 Message-ID: X-Originating-IP: [64.228.36.149] X-Originating-Email: [peter.ridler@sympatico.ca] Received: from jedi ([64.228.36.149]) by bayc1-pasmtp03.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Dec 2004 07:16:52 -0800 From: "Peter Ridler" To: "'Joerg Ott'" , "'Colin Perkins'" Subject: RE: [MMUSIC] Re: [Simple] MSRP: SDP usage concern Date: Sat, 18 Dec 2004 10:16:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTkZthNP+O3Mc8CSVmztZ3kPs8N8wAq2WDw In-Reply-To: <41BC325D.4010808@tzi.uni-bremen.de> Message-ID: X-OriginalArrivalTime: 18 Dec 2004 15:16:56.0365 (UTC) FILETIME=[9CA915D0:01C4E514] X-Spam-Score: 1.0 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Dec 2004 08:24:24 -0500 Cc: "'Simple WG'" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit I also agree with Colin and Joerg. I will also have two SDP parse engines (one for RTP and another for MSRP). This will complicate the code. Computers do not care about ugly formatting --- overall performance should be the concern (I think all text formatted protocols are a waste of network bandwidth and memory resources -- but I'm stuck with them). We should follow the standards as best we can. If the standard does not meet your requirements then define/use another. Another text based protocol is draft-ietf-sipping-toip-00.txt This fits the SIP/SDP model nicely. Peter > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott > Sent: Sunday, December 12, 2004 6:58 AM > To: Colin Perkins > Cc: Simple WG; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern > > I agree with Colin on the ugliness issue of decomposing URLs > into c= and m= lines. But this is the way SDP has worked and > works today. > > The present discussion we are having here is about changing > SDP to for address/URL handling in one particular case. This > does not strike me as something MSRP should be concerned with. > > I would like to make one thing clear: we are either using > existing tools in another document or we are building new > ones. There is nothing much in between. > > Changing c=/m= semantics means changing SDP. Just because > the syntax still looks the same does not mean that it is > still the same protocol. > Any entity or generic protocol engine used to dealing with > SDP m=/c= would no longer do the right thing. > > We see this kind of approach quite often -- by far too often > -- over the past years (just think the many "uses" of SIP > defined elsewhere, usually resulting in something "a little > but not entirely unlike" SIP). > > What I would like avoid is having special treatment of SDP > depending on what the media type is (or other attributes signify). > > Therefore, I strongly agree with Colin's conclusion: take SDP > as is or leave it altogether and pursue a different path. > > Joerg > > > Colin Perkins wrote: > > > On 10 Dec 2004, at 21:41, Ben Campbell wrote: > > > >> I really need to get closure on this, so I'd appreciate people > >> agreeing or disagreeing. > >> > >> I have had off-list correspondence indicating both > positions. In summary: > >> > >> In favor of the change, I had a comment to the effect that > changing > >> SDP semantics to ignore the C line and the port field on > the M line > >> really changes it to something that is no longer SDP, and > that such > >> deviations are in general bad for interop. > >> > >> In favor of leaving things as currently specified, I had > two comments > >> that decomposing URLs into the C and M lines is ugly, and > that having > >> a different mechanism to communicate endpoint addresses vs relay > >> addresses is really ugly. > >> > >> So, do people agree with one or the other position? > > > > > > Decomposing the URL into the "c=" and "m=" lines is very ugly. > > Unfortunately, that ugliness is required if you want to use > SDP. This > > is why the SDPng work was started, to try to move to something less > > horrible... > > > > Colin > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 08:32:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27608 for ; Mon, 20 Dec 2004 08:32:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgNnV-0000IB-UP for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 08:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNWT-0002nq-S0; Mon, 20 Dec 2004 08:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgCQm-00014f-Qj; Sun, 19 Dec 2004 20:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29739; Sun, 19 Dec 2004 20:33:46 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgCZv-00011A-BW; Sun, 19 Dec 2004 20:43:16 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Dec 2004 17:32:05 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Sun, 19 Dec 2004 17:32:06 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Sun, 19 Dec 2004 17:32:05 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Sun, 19 Dec 2004 17:32:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Dec 2004 17:32:01 -0800 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460C5B1F71@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Maximum non-scaled image size thread-index: AcTmLtSTU4zTsv0oSk6UHzZYvGVuOAAAWePg From: "Gary Sullivan" To: "Henning Schulzrinne" , , X-OriginalArrivalTime: 20 Dec 2004 01:32:05.0321 (UTC) FILETIME=[B6869390:01C4E633] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 20 Dec 2004 08:24:24 -0500 Subject: [MMUSIC] RE: [AVT] Maximum non-scaled image size X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable There are ways to declare an image size as part of a decoder capability or a decoder preference indication in both H.245 and SDP (and perhaps other places too, most likely including H.241 and what H.320 uses) -- I would suggest checking the design in regards to H.263 as that has probably been the most commonly used video codec in two-way communication scenarios. When specified as part of a declaration of decoder capability, an image size would ordinarily be interpreted as the maximum that the decoder could decode, rather than as the maximum it can display. But if specified as a decoder preference, its interpretation would be more akin to what you mention. That would be a declaration of what image size the decoder would most like to receive, although perhaps not necessarily an indication of exactly why. In some sense, that might be a better thing to design than what you seek. (Why pick only one specific reason for the decoder to indicate its preference for something?) A decoder might also, of course, use censorship of its decoder capability declaration to simply not declare capabilities beyond its native display resolutions. >From draft-ietf-avt-rfc2429-bis-03.txt (September 2004, section 8.1), there is a way in SDP for an H.263 decoder to indicate an ordered list of preferences for picture resolution and frame rate. (That stuff is also probably in the original RFC 2429 as well -- I just happen to have checked the "bis" draft). Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 +> Behalf Of Henning Schulzrinne +> Sent: Sunday, December 19, 2004 4:52 PM +> To: avt@ietf.org; mmusic@ietf.org +> Subject: [AVT] Maximum non-scaled image size +>=20 +> Do any video payload formats specify, as SDP format attributes or=20 +> otherwise, the maximum image size supported natively (i.e., without=20 +> downscaling)? +>=20 +> For a draft we're working on, I'd like to re-use any existing=20 +> conventions. In general, it would seem useful to know this=20 +> since there=20 +> isn't much point in sending at a higher resolution than the screen=20 +> resolution or the maximum size that an application can handle. This=20 +> seems like a natural extension to a=3Dframerate in SDP. +>=20 +> Henning +>=20 +>=20 +> _______________________________________________ +> Audio/Video Transport Working Group +> avt@ietf.org +> https://www1.ietf.org/mailman/listinfo/avt +>=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 20 13:56:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22714 for ; Mon, 20 Dec 2004 13:56:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgSrE-000089-Dn for mmusic-web-archive@ietf.org; Mon, 20 Dec 2004 14:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgSbR-000682-UJ; Mon, 20 Dec 2004 13:49:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgSYB-0005iZ-Cj for mmusic@megatron.ietf.org; Mon, 20 Dec 2004 13:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22202 for ; Mon, 20 Dec 2004 13:46:30 -0500 (EST) Received: from vs.informatik.uni-ulm.de ([134.60.77.243]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgShU-0008Kt-3C for mmusic@ietf.org; Mon, 20 Dec 2004 13:56:09 -0500 Received: from localhost (sikanda [127.0.0.1]) by vs.informatik.uni-ulm.de (Postfix) with ESMTP id CBB113E430F; Mon, 20 Dec 2004 19:45:58 +0100 (CET) Received: from vs.informatik.uni-ulm.de ([127.0.0.1]) by localhost (sikanda [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20101-04; Mon, 20 Dec 2004 19:45:55 +0100 (CET) Received: from vs.informatik.uni-ulm.de (discovery.informatik.uni-ulm.de [134.60.77.113]) by vs.informatik.uni-ulm.de (Postfix) with ESMTP id 5B29E3E430D; Mon, 20 Dec 2004 19:45:55 +0100 (CET) Message-ID: <41C71F30.1080302@vs.informatik.uni-ulm.de> Date: Mon, 20 Dec 2004 19:51:28 +0100 From: Teodora Guenkova-Luy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, de MIME-Version: 1.0 To: Henning Schulzrinne , mmusic@ietf.org Subject: Re: [MMUSIC] Maximum non-scaled image size References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> In-Reply-To: <41C6DEA2.6050201@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at vs.informatik.uni-ulm.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Dear Henning Schulzrinne, For some codecs the framerate is also a fix parameter of the codec=20 definition (e.g. the ITU-T H.26x codecs profiles and levels) and for other codecs (e.g. MPEG-4) it is a generic parameter, which should=20 be defined using descriptions of the media like in SDP. The framerate is the parameter of biggest influence for the network=20 traffic and IMHO that is why nobody has considered the framesize and the colour quality as generic parameter in SDP up to now. But in=20 order to specify performance for codecs with arbitrary definitions of framesize and the colour quality, you need their media definition in=20 SDP (or even better in XML format in SDPng) as well. With respect to framesize, I would rather put the framesize information=20 as one line and would rather specify the following for SDP: framesize-type =3D "a=3Dframesize:" sizetype SP width SP height sizetype =3D ciftype | vesatype | "arbitrary" Where the "ciftype" can be described considering the inputs of the=20 following table: CIF Format Resolution in pixels (width x height) SQCIF 128 =D7 96 QCIF 176 =D7 144 CIF 352 =D7 288 4CIF 704 =D7 576 9CIF 1056 =D7 864 16CIF 1408 =D7 1152 TV 720 =D7 576 SIF 352 =D7 240 SIF (NTSC) 360 =D7 240 SIF (PAL) 360 =D7 288 and "vesatype" (AR is Aspect Ratio): VESA Format width height AR-16:10 AR-16:9 AR-4:3 =20 non-square pixel QUXGA-Wide 3820 2400 x =20 WUXGA 1920 1200 x =20 WSXGA+ 1680 1050 x =20 WXGA+ =20 WXGA 1440 900 x =20 1280 854 x =20 3:2 1280 800 x =20 1280 768 x =20 5:3 1080i/1080p 1920 1080 x =20 720i/720p 1280 720 x =20 QUXGA 3200 2400 x = =20 QXGA 2048 1536 =20 x =20 UXGA 1600 1200 =20 x =20 SXGA+ 1400 1050 =20 x =20 SXGA 1280 1024 =20 x 5:4 XGA 1024 768 =20 x =20 SVGA 800 600 =20 x =20 VGA 640 480 =20 x =20 QVGA 320 240 =20 x =20 If specifying a "ciftype" or "vesatype" the SDP "width" and "height"=20 parameters could be optional, e.g. a=3Dframesize:4CIF If specifying an "arbitrary" framesize then the "width" and "height"=20 parameters are mandatory and shall be expressed in pixel, e.g. a=3Dframesize:arbitrary 300 200 Hope this helps, Teodora Guenkova-Luy Henning Schulzrinne wrote: > Thanks for all the explanation. It seems a bit asymmetric that=20 > framerate is specified as a generic a=3D parameter in SDP, while=20 > resolution is specified, if at all, on a per-codec basis. Would it=20 > make sense to have an 'a=3Dwidth' and 'a=3Dheight' parameter as well? > > Teodora Guenkova-Luy wrote: > >> Henning Schulzrinne wrote: >> >Do any video payload formats specify, as SDP format attributes or >> >otherwise, the maximum image size supported natively (i.e., without >> >downscaling)? >> ----------------------------------------------------------------------= ---=20 >> >> Dear All, >> >> The ITU-T standards (e.g. H.261, H.263, H.264, etc.) explicitly=20 >> specify image sizes for the codecs. H.261 and H.263 specify image=20 >> sizes according to ITU CIF standard in form of (height x width)=20 >> resolution. H.264 also specifies max image sizes per used profile=20 >> level in form of max bits per image, but without specifying aspect=20 >> ratios. From the MPEG standards only MPEG-1 specifies max image size=20 >> of 352x240 height x width resolution. All the other Video MPEGs are=20 >> with arbitrary image sizes. Another possibility to specify image=20 >> sizes are the VESA standards from www.vesa.org (e.g. VESA's VGA BIOS=20 >> Extensions). Note, that some standards for video specify frame-rate,=20 >> frame-size and colour-quality dependencies. Hence, using some=20 >> standard definitions might influence all of these 3 parameters, i.e.=20 >> the colour-quality (number of colours per image) might also influence=20 >> the amount of network data for the video streams. >> Note, that frame-size can be specified in 3 different manners: >> - (height x width) resolution in (pixel x pixel) >> - standard - i.e. CIF or VESA >> - max number of bits + aspect ratio - e.g. commonly used aspect=20 >> ratios are height: width =3D 4:3, 5:4, 11:9, 16:9, 16:10. These aspect= =20 >> ratios stem also from CIF and VESA >> For the complete and unique video performance specification with SDP=20 >> in case of arbitrary video image specification one needs to have=20 >> specifications for frame-rate, frame-size and colour-quality. >> Best Regards, >> Teodora Guenkova-Luy >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > --=20 ----------------------------------------- Teodora Guenkova-Luy Dept. Distributed Systems, University of Ulm,=20 Oberer Eselsberg, 89069 Ulm, Germany Tel.: +49 (0731) 502-4148=20 FAX: +49 (0731) 502-4142 e-Mail: guenkova@vs.informatik.uni-ulm.de Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/=20 ----------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 21 09:17:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12507 for ; Tue, 21 Dec 2004 09:17:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgkzC-0004lj-Ho for mmusic-web-archive@ietf.org; Tue, 21 Dec 2004 09:27:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgkiN-00088I-RD; Tue, 21 Dec 2004 09:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgkZO-0006Xv-3i for mmusic@megatron.ietf.org; Tue, 21 Dec 2004 09:00:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11238 for ; Tue, 21 Dec 2004 09:00:53 -0500 (EST) Received: from fep14.012.net.il ([212.117.129.241]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgkin-0004Kb-Hn for mmusic@ietf.org; Tue, 21 Dec 2004 09:10:42 -0500 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by fep14.012.net.il with ESMTP id <20041221135537.CMLK13819.fep14@isrexch01.israel.polycom.com>; Tue, 21 Dec 2004 15:55:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Maximum non-scaled image size Date: Tue, 21 Dec 2004 16:00:21 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C921DB0@IsrExch01.israel.polycom.com> Thread-Topic: [MMUSIC] Maximum non-scaled image size Thread-Index: AcTmxuZJ8tgEe2opSGKwZDuKSjYeHgAnZmdA From: "Even, Roni" To: "Teodora Guenkova-Luy" , "Henning Schulzrinne" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Hi, Just a small correction. The frame rate is not a fixed parameter, for H.261 there are no profile = and level. For H.263++ you can use profile and levels but the levels = gives maximum on frame rate and on resolution. That is why we are adding = in draft-ietf-avt-rfc2032-bis and draft-ietf-avt-rfc2429-bis the SDP = parameters to specify the resolutions and the frame rates that can be = used. The specific video codecs (H.261 and H.263) has a list of defined = resolutions they support and not all the list specified. H.263 can = support custom formats. Roni Even=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Teodora Guenkova-Luy Sent: Monday, December 20, 2004 8:51 PM To: Henning Schulzrinne; mmusic@ietf.org Subject: Re: [MMUSIC] Maximum non-scaled image size Dear Henning Schulzrinne, For some codecs the framerate is also a fix parameter of the codec=20 definition (e.g. the ITU-T H.26x codecs profiles and levels) and for other codecs (e.g. MPEG-4) it is a generic parameter, which should=20 be defined using descriptions of the media like in SDP. The framerate is the parameter of biggest influence for the network=20 traffic and IMHO that is why nobody has considered the framesize and the colour quality as generic parameter in SDP up to now. But in=20 order to specify performance for codecs with arbitrary definitions of framesize and the colour quality, you need their media definition in=20 SDP (or even better in XML format in SDPng) as well. With respect to framesize, I would rather put the framesize information=20 as one line and would rather specify the following for SDP: framesize-type =3D "a=3Dframesize:" sizetype SP width SP height sizetype =3D ciftype | vesatype | "arbitrary" Where the "ciftype" can be described considering the inputs of the=20 following table: CIF Format Resolution in pixels (width x height) SQCIF 128 =AA 96 QCIF 176 =AA 144 CIF 352 =AA 288 4CIF 704 =AA 576 9CIF 1056 =AA 864 16CIF 1408 =AA 1152 TV 720 =AA 576 SIF 352 =AA 240 SIF (NTSC) 360 =AA 240 SIF (PAL) 360 =AA 288 and "vesatype" (AR is Aspect Ratio): VESA Format width height AR-16:10 AR-16:9 AR-4:3 =20 non-square pixel QUXGA-Wide 3820 2400 x =20 WUXGA 1920 1200 x =20 WSXGA+ 1680 1050 x =20 WXGA+ =20 WXGA 1440 900 x =20 1280 854 x =20 3:2 1280 800 x =20 1280 768 x =20 5:3 1080i/1080p 1920 1080 x =20 720i/720p 1280 720 x =20 QUXGA 3200 2400 x = =20 QXGA 2048 1536 = x =20 UXGA 1600 1200 = x =20 SXGA+ 1400 1050 =20 x =20 SXGA 1280 1024 = x 5:4 XGA 1024 768 = x =20 SVGA 800 600 =20 x =20 VGA 640 480 =20 x =20 QVGA 320 240 =20 x =20 If specifying a "ciftype" or "vesatype" the SDP "width" and "height"=20 parameters could be optional, e.g. a=3Dframesize:4CIF If specifying an "arbitrary" framesize then the "width" and "height"=20 parameters are mandatory and shall be expressed in pixel, e.g. a=3Dframesize:arbitrary 300 200 Hope this helps, Teodora Guenkova-Luy Henning Schulzrinne wrote: > Thanks for all the explanation. It seems a bit asymmetric that=20 > framerate is specified as a generic a=3D parameter in SDP, while=20 > resolution is specified, if at all, on a per-codec basis. Would it=20 > make sense to have an 'a=3Dwidth' and 'a=3Dheight' parameter as well? > > Teodora Guenkova-Luy wrote: > >> Henning Schulzrinne wrote: >> >Do any video payload formats specify, as SDP format attributes or >> >otherwise, the maximum image size supported natively (i.e., without >> >downscaling)? >> = -------------------------------------------------------------------------= =20 >> >> Dear All, >> >> The ITU-T standards (e.g. H.261, H.263, H.264, etc.) explicitly=20 >> specify image sizes for the codecs. H.261 and H.263 specify image=20 >> sizes according to ITU CIF standard in form of (height x width)=20 >> resolution. H.264 also specifies max image sizes per used profile=20 >> level in form of max bits per image, but without specifying aspect=20 >> ratios. From the MPEG standards only MPEG-1 specifies max image size=20 >> of 352x240 height x width resolution. All the other Video MPEGs are=20 >> with arbitrary image sizes. Another possibility to specify image=20 >> sizes are the VESA standards from www.vesa.org (e.g. VESA's VGA BIOS=20 >> Extensions). Note, that some standards for video specify frame-rate, = >> frame-size and colour-quality dependencies. Hence, using some=20 >> standard definitions might influence all of these 3 parameters, i.e.=20 >> the colour-quality (number of colours per image) might also influence = >> the amount of network data for the video streams. >> Note, that frame-size can be specified in 3 different manners: >> - (height x width) resolution in (pixel x pixel) >> - standard - i.e. CIF or VESA >> - max number of bits + aspect ratio - e.g. commonly used aspect=20 >> ratios are height: width =3D 4:3, 5:4, 11:9, 16:9, 16:10. These = aspect=20 >> ratios stem also from CIF and VESA >> For the complete and unique video performance specification with SDP=20 >> in case of arbitrary video image specification one needs to have=20 >> specifications for frame-rate, frame-size and colour-quality. >> Best Regards, >> Teodora Guenkova-Luy >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > --=20 ----------------------------------------- Teodora Guenkova-Luy Dept. Distributed Systems, University of Ulm,=20 Oberer Eselsberg, 89069 Ulm, Germany Tel.: +49 (0731) 502-4148=20 FAX: +49 (0731) 502-4142 e-Mail: guenkova@vs.informatik.uni-ulm.de Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/=20 ----------------------------------------- _______________________________________________ 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-bounces@ietf.org Tue Dec 21 18:20:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18323 for ; Tue, 21 Dec 2004 18:20:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgtOg-0000h1-F1 for mmusic-web-archive@ietf.org; Tue, 21 Dec 2004 18:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgt99-00009a-NA; Tue, 21 Dec 2004 18:10:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgsxu-0000C5-PJ; Tue, 21 Dec 2004 17:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12754; Tue, 21 Dec 2004 17:58:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgt7T-0006tQ-BB; Tue, 21 Dec 2004 18:08:43 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cgslu-0003Hm-6D; Tue, 21 Dec 2004 17:46:26 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 21 Dec 2004 17:46:26 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , mmusic chair , RFC Editor Subject: [MMUSIC] Protocol Action: 'The Alternative Network Address Types Semantics (ANAT) for theSession Description Protocol (SDP) Grouping Framework' to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The IESG has approved the following document: - 'The Alternative Network Address Types Semantics (ANAT) for theSession Description Protocol (SDP) Grouping Framework ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This addition to the Session Description Protocol (SDP) allows an SDP offer to contain more than one network address associated with a single offered media stream. The motivation for this is IPv6 transition - it allows a dual-stack client to offer both an IPv6 and an IPv4 address from which the answerer can choose. It also allows these addresses to be prioritized, so an offerer can indicate that they would prefer to connect via IPv6, if possible. This has significant applicability to the Interactive Connectivity Establishment (ICE) mechanism being developed in MMUSIC. Working Group Summary The MMUSIC working group supported the advancement of this document. A concern was expressed that interaction of other media grouping semantics in SDP was insufficiently specified, but the media grouping framework was authored by some f the same individuals who wrote this document, and they seem to feel that the distinction is clear enough. Protocol Quality This specification was reviewed for the IESG by Jon Peterson. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 22 08:32:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21903 for ; Wed, 22 Dec 2004 08:32:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch6kk-00068Y-J1 for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 08:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch6Wq-0001Jo-Ss; Wed, 22 Dec 2004 08:27:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch2EA-00068e-Ug for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 03:52:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02371 for ; Wed, 22 Dec 2004 03:52:12 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch2Nn-0006by-Ib for mmusic@ietf.org; Wed, 22 Dec 2004 04:02:12 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id iBM8svo1028824 for ; Wed, 22 Dec 2004 01:54:57 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iBM8oiAQ016818 for ; Wed, 22 Dec 2004 02:50:46 -0600 Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Dec 2004 14:21:07 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F3245BA7@zin24exm01.ap.mot.com> From: Vavilapalli Srikanth-A19563 To: "'Mark Baugher'" , "'mmusic@ietf.org'" Date: Wed, 22 Dec 2004 14:21:02 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 22 Dec 2004 08:27:46 -0500 Cc: fandreas@cisco.com, dwing@cisco.com Subject: [MMUSIC] SDP Support for exchanging different auth tag length for SRTP and SRTCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi Ref: In this draft, I did not find a way to exchange the both SRTP and SRTCP authentication tag lengths using SDP secure attributes. i.e. if a SRTP application wishes to use 32-bit weak authentication for SRTP packets and 80-bit strong authentication for SRTCP packets and has chosen the mechanism described in the above draft to communicate between sender and receiver, How can a offerer/answerer include this information in the a=crypto line of SDP offer or answer respectively? Regards Srikanth _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 22 08:40:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22944 for ; Wed, 22 Dec 2004 08:40:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch6t5-0006Py-0j for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 08:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch6ZE-0002be-Kq; Wed, 22 Dec 2004 08:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch6Jj-0004JV-CR for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 08:14:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20394 for ; Wed, 22 Dec 2004 08:14:13 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch6TO-0005Tm-55 for mmusic@ietf.org; Wed, 22 Dec 2004 08:24:15 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBMDEBO6009959 for ; Wed, 22 Dec 2004 14:14:11 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Dec 2004 14:14:11 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Dec 2004 14:14:11 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Joerg Ott'" , mmusic@ietf.org Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt Date: Wed, 22 Dec 2004 14:14:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Dec 2004 13:14:11.0841 (UTC) FILETIME=[20B6E710:01C4E828] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi, I have a small question. The sdp-new draft says that "inactive" is used to put users on hold, while RFC3264(offer/answer) says that "sendonly" is used. Now, in the original SDP RFC, which RFC3246 refers to, "inactive" was not defined, so I wonder if RFC3264 is to be updated? Or, are both hold mechanisms "according to the standard"? Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org]On Behalf > Of Joerg Ott > Sent: 19. joulukuuta 2004 18:51 > To: mmusic@ietf.org > Cc: Colin Perkins > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt > > > This is to announce Working Group Last Call on the revised > SDP specification "SDP: Session Description Protocol" > recently published as > > draft-ietf-mmusic-sdp-new-23.txt > > The document shall be advanced to Proposed Standard (PS). > > The WGLC is to end on 9 January 2005. > > Please review the latest draft carefully and direct all comments > to the MMUSIC list and the authors. > > Joerg > > > > _______________________________________________ > 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-bounces@ietf.org Wed Dec 22 09:50:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28988 for ; Wed, 22 Dec 2004 09:50:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch7yQ-0000KO-El for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 10:00:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7WW-0006oK-9z; Wed, 22 Dec 2004 09:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7OE-0003EU-7R for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 09:22:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25833 for ; Wed, 22 Dec 2004 09:22:56 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch7Xt-0007Wg-So for mmusic@ietf.org; Wed, 22 Dec 2004 09:32:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Dec 2004 06:27:49 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBMEMNHn019823; Wed, 22 Dec 2004 06:22:23 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn2-440.cisco.com [10.21.113.184]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBMEKa4J002174; Wed, 22 Dec 2004 06:20:36 -0800 In-Reply-To: <772BCEF88A1DD91191F80011856715F3245BA7@zin24exm01.ap.mot.com> References: <772BCEF88A1DD91191F80011856715F3245BA7@zin24exm01.ap.mot.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] SDP Support for exchanging different auth tag length for SRTP and SRTCP Date: Wed, 22 Dec 2004 06:22:18 -0800 To: Vavilapalli Srikanth-A19563 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1103725237.15673"; x:"432200"; a:"rsa-sha1"; b:"nofws:1510"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"P+1WDAsqajfTJEq8sWH8sHwuOyknqC0OKMjckHFq12QAu0+SVFdUDfGCIyol5" "Wb+sUe+8BhUbaJhdeSVOxkGhLkRcsS+Tbzde+0xOzHPvDhbPuD08z7SXliXPB" "Bz0VjzCzxis5Aj5YxhNmm0g8TiJoTXJYsCPOa0McR3HmMr7FQ="; c:"From: Mark Baugher "; c:"Subject: Re: [MMUSIC] SDP Support for exchanging different auth tag le" "ngth for SRTP and SRTCP"; c:"Date: Wed, 22 Dec 2004 06:22:18 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , "'mmusic@ietf.org'" , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit hi Srikanth, On Dec 22, 2004, at 12:51 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > Ref: > > In this draft, I did not find a way to exchange the both SRTP and SRTCP > authentication tag lengths using SDP secure attributes. There is no way to specify a different cryptographic policy for SRTP and SRTCP in sdescriptions. The reason for that is that I think it's a bad idea to have unnecessary complexity in a security protocol. > > i.e. if a SRTP application wishes to use 32-bit weak authentication > for SRTP > packets and 80-bit strong authentication for SRTCP packets and has > chosen > the mechanism described in the above draft to communicate between > sender and > receiver, How can a offerer/answerer include this information in the > a=crypto line of SDP offer or answer respectively? They can't. If someone wants to introduce this level of complexity into SRTP signaling, then they can write their own sdescriptions draft. sdescriptions is extensible, but I think it's better to keep things as simple as they can be. Allowing multiple policies within an SRTP session to me isn't simple. SRTP as a protocol does admit separate policies for SRTP and SRTCP. sdescriptions supports only a single policy per session. Cheers, Mark > > Regards > Srikanth > > _______________________________________________ > 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-bounces@ietf.org Wed Dec 22 11:26:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08549 for ; Wed, 22 Dec 2004 11:26:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9Tm-0003OR-5n for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 11:36:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch9IY-0006Go-6u; Wed, 22 Dec 2004 11:25:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch9Fy-0005I9-31 for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 11:22:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08185 for ; Wed, 22 Dec 2004 11:22:30 -0500 (EST) Received: from zukmail03.zreo.compaq.com ([161.114.128.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9Pc-0003GJ-VD for mmusic@ietf.org; Wed, 22 Dec 2004 11:32:35 -0500 Received: from IDAEXG12.emea.cpqcorp.net (idaexg12.emea.cpqcorp.net [16.16.5.39]) by zukmail03.zreo.compaq.com (Postfix) with ESMTP id 709B62FAF for ; Wed, 22 Dec 2004 16:21:57 +0000 (GMT) Received: from idaexc03.emea.cpqcorp.net ([16.16.5.20]) by IDAEXG12.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Dec 2004 17:21:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Dec 2004 17:21:56 +0100 Message-ID: Thread-Topic: Question about direction in draft-ietf-mmusic-offer-answer-examples-05 Thread-Index: AcToQYv+aoXaPwhVQp2QtNk7zU8umQ== From: "Pagani, Florence" To: X-OriginalArrivalTime: 22 Dec 2004 16:21:56.0965 (UTC) FILETIME=[5B406950:01C4E842] X-Spam-Score: 0.6 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [MMUSIC] Question about direction in draft-ietf-mmusic-offer-answer-examples-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354587161==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 This is a multi-part message in MIME format. --===============0354587161== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E842.5B15677E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E842.5B15677E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I am wondering why in http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examp les-05.txt, there is an answer without any direction (i.e. the default = =3D sendrecv) to an offer with direction sendonly. I would have put recvonly instead... Did I miss something? =20 Here is the example: _____ =20 3.2 Hold with Two Streams Alice offers two media streams, a bidirectional audio stream and a send only telephone event stream. Bob accepts both streams. Bob then puts Alice's audio stream on hold but not the tone stream. Alice responds with identical SDP to the initial offer. [Offer] v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 97 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:97 iLBC/8000 m=3Daudio 49172 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Dsendonly [Answer] v=3D0 o=3Dbob 2808844564 2808844564 IN IP4 host.biloxi.example.com s=3D c=3DIN IP4 host.biloxi.example.com t=3D0 0 m=3Daudio 49172 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 m=3Daudio 49174 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Drecvonly [Second-Offer] v=3D0 o=3Dbob 2808844564 2808844565 IN IP4 host.biloxi.example.com s=3D c=3DIN IP4 host.biloxi.example.com t=3D0 0 m=3Daudio 49172 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 a=3Dsendonly m=3Daudio 49174 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Drecvonly [Second-Answer] v=3D0 o=3Dalice 2890844526 2890844527 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 97 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:97 iLBC/8000 --> Why not recvonly = ???? m=3Daudio 49172 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Dsendonly -- Florence PAGANI HP OpenCall Business Unit - New Venture +33 (0)4 76 14 57 53 florence.pagani@hp.com =20 ------_=_NextPart_001_01C4E842.5B15677E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 all,
 
I am=20 wondering why in http://www.ietf.org/internet-drafts/draft-ietf-mmusic-= offer-answer-examples-05.txt,=20 there is an answer without any direction (i.e. the default =3D = sendrecv) to an offer with direction  sendonly. I = would have=20 put recvonly instead... Did I miss something?
 
Here is=20 the example:
3.2  Hold with Two=20 Streams

   Alice offers two media streams, a = bidirectional=20 audio stream and a
   send only telephone event = stream.  Bob=20 accepts both streams.  Bob
   then puts Alice's audio = stream=20 on hold but not the tone stream.
   Alice responds with = identical=20 SDP to the initial offer.


   =20 [Offer]

     =20 v=3D0
      o=3Dalice 2890844526 2890844526 = IN IP4=20 host.atlanta.example.com
     =20 s=3D
      c=3DIN IP4=20 host.atlanta.example.com
      t=3D0=20 0
      m=3Daudio 49170 RTP/AVP 0=20 97
      a=3Drtpmap:0=20 PCMU/8000
      a=3Drtpmap:97=20 iLBC/8000
      m=3Daudio 49172 RTP/AVP=20 98
      a=3Drtpmap:98=20 telephone-event/8000
     =20 a=3Dsendonly

   = [Answer]

     =20 v=3D0
      o=3Dbob 2808844564 2808844564 IN = IP4=20 host.biloxi.example.com
     =20 s=3D
      c=3DIN IP4=20 host.biloxi.example.com
      t=3D0=20 0
      m=3Daudio 49172 RTP/AVP=20 97
      a=3Drtpmap:97=20 iLBC/8000
      m=3Daudio 49174 RTP/AVP=20 98
      a=3Drtpmap:98=20 telephone-event/8000
     =20 a=3Drecvonly

  =20 [Second-Offer]

     =20 v=3D0
      o=3Dbob 2808844564 2808844565 IN = IP4=20 host.biloxi.example.com
     =20 s=3D
      c=3DIN IP4=20 host.biloxi.example.com
      t=3D0=20 0
      m=3Daudio 49172 RTP/AVP=20 97
      a=3Drtpmap:97=20 iLBC/8000
      a=3Dsendonly
      = m=3Daudio 49174=20 RTP/AVP 98
      a=3Drtpmap:98=20 telephone-event/8000
     =20 a=3Drecvonly


  =20 [Second-Answer]

     =20 v=3D0
      o=3Dalice 2890844526 2890844527 = IN IP4=20 host.atlanta.example.com
     =20 s=3D
      c=3DIN IP4=20 host.atlanta.example.com
      t=3D0=20 0
      m=3Daudio=20 49170 RTP/AVP 0 97
      a=3Drtpmap:0=20 PCMU/8000
      a=3Drtpmap:97=20 iLBC/8000              &nb= sp;    =20 --> Why not recvonly = ????
     =20 m=3Daudio 49172 RTP/AVP 98
      = a=3Drtpmap:98=20 telephone-event/8000
     =20 a=3Dsendonly
--
Florence = PAGANI
HP OpenCall Business Unit - New=20 Venture
+33 (0)4 = 76 14 57=20 53
florence.pagani@hp.com
 
------_=_NextPart_001_01C4E842.5B15677E-- --===============0354587161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0354587161==-- From mmusic-bounces@ietf.org Wed Dec 22 14:26:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25312 for ; Wed, 22 Dec 2004 14:26:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCHd-0000JL-1v for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 14:36:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChC6T-0004kg-Ul; Wed, 22 Dec 2004 14:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChBzB-0003Kt-6C for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 14:17:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24672 for ; Wed, 22 Dec 2004 14:17:23 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChC8t-0008Ts-Dh for mmusic@ietf.org; Wed, 22 Dec 2004 14:27:28 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBMJGQb25788; Wed, 22 Dec 2004 14:16:26 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Dec 2004 14:16:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF013B8050@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Christer Holmberg (JO/LMF)'" , "'Joerg Ott'" , "'mmusic@ietf.org'" Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt Date: Wed, 22 Dec 2004 14:16:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: "'Colin Perkins'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629811809==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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. --===============1629811809== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E85A.B6C168A2" 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_01C4E85A.B6C168A2 Content-Type: text/plain > Hi, > > I have a small question. > > The sdp-new draft says that "inactive" is used to put users > on hold, while RFC3264(offer/answer) says that "sendonly" is used. > > Now, in the original SDP RFC, which RFC3246 refers to, > "inactive" was not defined, so I wonder if RFC3264 is to be updated? > > Or, are both hold mechanisms "according to the standard"? Yes. They are slighly different forms of "hold". SIP/SDP doesn't really have a concept of "hold" in the traditional telephony sense. sendonly means that you can not receive media. inactive means that you can not receive media and that you are not sending either. They could both mean that you are "on hold". You can think of a Music On Hold service, versus a normal Hold service. But neither necessarily means "hold" as per traditional telephony. You could send inactive or sendonly for reasons that are not a logical hold, but just plain media pausing. ------_=_NextPart_001_01C4E85A.B6C168A2 Content-Type: text/html RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt

> Hi,
>
> I have a small question.
>
> The sdp-new draft says that "inactive" is used to put users
> on hold, while RFC3264(offer/answer) says that "sendonly" is used.
>
> Now, in the original SDP RFC, which RFC3246 refers to,
> "inactive" was not defined, so I wonder if RFC3264 is to be updated?
>
> Or, are both hold mechanisms "according to the standard"?

Yes.

They are slighly different forms of "hold".

SIP/SDP doesn't really have a concept of "hold" in the traditional telephony
sense.

sendonly means that you can not receive media.

inactive means that you can not receive media and that you are not sending
either.

They could both mean that you are "on hold". You can think of a Music On Hold
service,  versus a normal Hold service. But neither necessarily means "hold" as per
traditional telephony. You could send inactive or sendonly for reasons that are
not a logical hold, but just plain media pausing.

------_=_NextPart_001_01C4E85A.B6C168A2-- --===============1629811809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1629811809==-- From mmusic-bounces@ietf.org Wed Dec 22 22:33:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14315 for ; Wed, 22 Dec 2004 22:33:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChJsk-0004tj-Tl for mmusic-web-archive@ietf.org; Wed, 22 Dec 2004 22:43:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChJhn-0000z3-8P; Wed, 22 Dec 2004 22:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChJhN-0000pf-1r for mmusic@megatron.ietf.org; Wed, 22 Dec 2004 22:31:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14238 for ; Wed, 22 Dec 2004 22:31:30 -0500 (EST) Received: from junkmail.cs.umd.edu ([128.8.128.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChJrA-0004qe-Qp for mmusic@ietf.org; Wed, 22 Dec 2004 22:41:41 -0500 Received: from utz.cs.umd.edu (utz.cs.umd.edu [128.8.129.122]) by junkmail.cs.umd.edu (8.12.10/8.12.5) with ESMTP id iBN3V2Fs008135 for ; Wed, 22 Dec 2004 22:31:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by utz.cs.umd.edu (8.12.11/8.12.5) with ESMTP id iBN3V2p7011699 for ; Wed, 22 Dec 2004 22:31:02 -0500 Date: Wed, 22 Dec 2004 22:31:02 -0500 (EST) From: "Moustafa A. Youssef" To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [MMUSIC] CFP: IEEE WirelessCom Symposium on Mobile Computing, 2005 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Call for Papers Symposium on Mobile Computing http://www.csee.umbc.edu/~younis/WC_MobCom05.htm as part of IEEE WirelessCom 2005 Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/ June 13-16, 2005 Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC Recent years have witnessed an enormous growth in the development and applications of mobile computing environments and devices. Many practitioners envision a future empowered with context and location aware computation and communication infrastructure that allow users to access data and receive service at any place and any time. Compared to conventional platforms, the mobility of computing nodes introduces many challenges to the design of almost all systems components. This symposium will foster a forum for discussing and presenting recent research results on mobile computer systems. Original papers are invited in the broader area of mobile computing. Papers must report high-quality and previously unpublished work. Topics of interest include, but are not limited to, the following: - Architecture and infrastructure support - Middleware and operating systems services - Development platforms and environments - Adaptive resource management schemes - Pervasive and Context-aware Computing - Performance metrics and studies - Power aware computation and communication - Data consistency and synchronization protocols - Fault-tolerant architectural and operation models - Wearable computing devices and systems - Time constrained mobile systems - Robust ad-hoc networking techniques - Efficient localization techniques - Wireless sensor networks - Mobile peer to peer systems - Quality of service provisioning - Context-conscious computing - Web caching and services - Emerging applications and systems - Mobile agents - Mobile commerce - Security and privacy issues Submission Guidelines --------------------- Prospective authors should submit their paper electronically to younis@csee.umbc.edu. All papers are limited to 6 pages in MS-Word, PS or PDF using standard IEEE double-column format. The first page should include title, authors' contact information, an abstract and five keywords. Authors should attach the paper abstract to their message. Important Dates --------------- Paper Submission Deadline: March 15, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Symposium Co-Chairs ------------------- Mohamed Younis Department of Computer Science and Electrical Engineering University of Maryland Baltimore County, E-mail: younis@csee.umbc.edu Hesham El-Rewini Department of Computer Science and Engineering Southern Methodist University E-mail: rewini@engr.smu.edu Publicity Chair ---------------- Moustafa Youssef Department of Computer Science University of Maryland at College Park, E-mail: moustafa@cs.umd.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 23 05:50:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26323 for ; Thu, 23 Dec 2004 05:50:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChQhY-000794-W3 for mmusic-web-archive@ietf.org; Thu, 23 Dec 2004 06:00:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChQU8-0004fM-4f; Thu, 23 Dec 2004 05:46:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChQOw-0002oK-IC for mmusic@megatron.ietf.org; Thu, 23 Dec 2004 05:40:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25669 for ; Thu, 23 Dec 2004 05:40:55 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChQYn-0006tH-Pa for mmusic@ietf.org; Thu, 23 Dec 2004 05:51:10 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBNAesh5001885 for ; Thu, 23 Dec 2004 11:40:56 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Dec 2004 11:40:54 +0100 Received: from [153.88.8.195] (sealwa02m-195.sw.ericsson.se [153.88.8.195]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAPCWWC1; Thu, 23 Dec 2004 11:40:53 +0100 Message-ID: <41C9D6DE.9090306@ericsson.com> Date: Wed, 22 Dec 2004 21:19:42 +0100 X-Sybari-Trust: eb869b9f 96d33411 d65db381 00000138 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teodora Guenkova-Luy Subject: Re: [MMUSIC] Maximum non-scaled image size References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> <41C71F30.1080302@vs.informatik.uni-ulm.de> In-Reply-To: <41C71F30.1080302@vs.informatik.uni-ulm.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2004 10:40:54.0345 (UTC) FILETIME=[E0FE2390:01C4E8DB] X-Spam-Score: 0.4 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Henning Schulzrinne X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi, I would like to point out that 3GPP has defined in TS 26.234 a SDP attribute a=framesize. It has the following definition: The following media level SDP field is defined for PSS: - "a=framesize: -" This gives the largest video frame size of H.263 streams. The frame size field in SDP is needed by the client in order to properly allocate frame buffer memory. For MPEG-4 Visual streams, the frame size shall be extracted from the "config" information in the SDP. For H.264 (AVC) streams, the frame size shall be extracted from the sprop-parameters-sets information in the SDP. For H.263 streams, a PSS server shall include the "a=framesize" field at the media level for each stream in SDP, and a PSS client should interpret this field, if present. Clients should be ready to receive SDP descriptions without this attribute. If this attribute is present, the frame size parameters shall exactly match the largest frame size defined in the video stream. The width and height values shall be expressed in pixels. However, to my understanding, this attribute is not what Henning is seeking. I only like to warn you at an early stage about the potential name conflict. I am sorry that I haven't had time yet to write the SDP registration draft for the PSS specification. But on the point Henning is asking about, in the 3GPP Packet-based Streaming Service, the servers can use UAProf to determine the clients screen resolution. Cheers Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 23 06:21:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28625 for ; Thu, 23 Dec 2004 06:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChRBi-0007zx-Qn for mmusic-web-archive@ietf.org; Thu, 23 Dec 2004 06:31:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChQz0-0005UE-4m; Thu, 23 Dec 2004 06:18:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChQlt-0008Qv-JB for mmusic@megatron.ietf.org; Thu, 23 Dec 2004 06:04:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27390 for ; Thu, 23 Dec 2004 06:04:38 -0500 (EST) Received: from mtaout2.012.net.il ([84.95.2.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChQvk-0007Th-20 for mmusic@ietf.org; Thu, 23 Dec 2004 06:14:53 -0500 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTP id <0I960040D9HCCAG0@i_mtaout2.012.net.il> for mmusic@ietf.org; Thu, 23 Dec 2004 13:05:36 +0200 (IST) Date: Thu, 23 Dec 2004 13:03:49 +0200 From: "Even, Roni" Subject: RE: [MMUSIC] Maximum non-scaled image size To: Magnus Westerlund , Teodora Guenkova-Luy Message-id: <144ED8561CE90C41A3E5908EDECE315CA208A5@IsrExch01.israel.polycom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Thread-topic: [MMUSIC] Maximum non-scaled image size Thread-index: AcTo3ZQ1hKCzVxzySo2+eD7qWMAfqgAAKidw X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7BIT Cc: mmusic@ietf.org, Henning Schulzrinne X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7BIT Hi, Hi, As Magnus points out the maximum frame size is limited by the available frame buffer in the decoder but another parameter that is important is the frame rate. A decoder may have a large frame buffer or high resolution display, but due to processing power may be able to use the full size only for low frame rate. As for screen resolution I am wondering if the parameter that Magnus describes address the screen resolution or the available decoder frame buffer, are they the same. Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Wednesday, December 22, 2004 10:20 PM To: Teodora Guenkova-Luy Cc: mmusic@ietf.org; Henning Schulzrinne Subject: Re: [MMUSIC] Maximum non-scaled image size Hi, I would like to point out that 3GPP has defined in TS 26.234 a SDP attribute a=framesize. It has the following definition: The following media level SDP field is defined for PSS: - "a=framesize: -" This gives the largest video frame size of H.263 streams. The frame size field in SDP is needed by the client in order to properly allocate frame buffer memory. For MPEG-4 Visual streams, the frame size shall be extracted from the "config" information in the SDP. For H.264 (AVC) streams, the frame size shall be extracted from the sprop-parameters-sets information in the SDP. For H.263 streams, a PSS server shall include the "a=framesize" field at the media level for each stream in SDP, and a PSS client should interpret this field, if present. Clients should be ready to receive SDP descriptions without this attribute. If this attribute is present, the frame size parameters shall exactly match the largest frame size defined in the video stream. The width and height values shall be expressed in pixels. However, to my understanding, this attribute is not what Henning is seeking. I only like to warn you at an early stage about the potential name conflict. I am sorry that I haven't had time yet to write the SDP registration draft for the PSS specification. But on the point Henning is asking about, in the 3GPP Packet-based Streaming Service, the servers can use UAProf to determine the clients screen resolution. Cheers Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 23 13:55:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07843 for ; Thu, 23 Dec 2004 13:55:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChYHa-00042m-JA for mmusic-web-archive@ietf.org; Thu, 23 Dec 2004 14:05:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChY0k-0004h0-96; Thu, 23 Dec 2004 13:48:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChXno-00013F-4e for mmusic@megatron.ietf.org; Thu, 23 Dec 2004 13:35:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06358 for ; Thu, 23 Dec 2004 13:35:03 -0500 (EST) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChXxi-0003TD-6m for mmusic@ietf.org; Thu, 23 Dec 2004 13:45:22 -0500 Received: from srsdmail01.PVNS.COM (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id iBNIYPAe008439; Thu, 23 Dec 2004 12:34:25 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Dec 2004 10:34:25 -0800 Message-ID: <758B5A159B385447B4F950DE72D7D7AD678BD0@srsdmail01.PVNS.COM> Thread-Topic: Question on the Usage of Feature Tags in draft-ietf-mmusic-rfc2326bis-08.txt Thread-Index: AcTpHgdAmBbxOfWFRLm6HyfmOYE6/w== From: "Thomas Zeng" To: , X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [MMUSIC] Question on the Usage of Feature Tags in draft-ietf-mmusic-rfc2326bis-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775891231==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. --===============1775891231== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E91E.07411FB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E91E.07411FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Magnus: =20 Merry Christmas. =20 We have been looking at the subject of capability handling which led us = to RFC2326bis-08, Chapter 10, where it is suggested that the server uses = the Supported header to advertise the list of feature tags it is capable = of handling. =20 It is worth clarifying whether the list of tags in the Supported header = should be a function of the request URL or not. =20 For instance, if a client issues a DESCRIBE on a audio only request URL, = and the server in its 200 OK response includes the feature tag = "com.A_company.video-bit-stream-switching". Is that appropriate?=20 =20 Clearly video-bit-stream-switching does not apply to an audio-only URL, = but one could argue that video-bit-stream-switching is one of the = server's capabilities and the client may choose to take advantage of it = later on.=20 =20 What is your interpretation? What does the group think? =20 Thanks, -Thomas ------_=_NextPart_001_01C4E91E.07411FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 Magnus:
 
Merry=20 Christmas.
 
We = have=20 been looking at the subject of capability handling which led = us=20 to RFC2326bis-08, Chapter 10, where it is suggested that the server = uses=20 the Supported header to advertise the list of feature tags it is capable = of=20 handling.
 
It is = worth=20 clarifying whether the list of tags in the Supported=20 header should be a function of  the request URL or=20 not.
 
For = instance, if a=20 client issues a DESCRIBE on a audio only request URL, and the = server in its=20 200 OK response includes the feature tag=20 "com.A_company.video-bit-stream-switching". Is that appropriate?=20
 
Clearly=20 video-bit-stream-switching does not apply to an audio-only URL, but one = could=20 argue that video-bit-stream-switching is one of the server's = capabilities and=20 the client may choose to take advantage of it later on. =
 
What = is your=20 interpretation? What does the group think?
 
Thanks,
-Thomas
------_=_NextPart_001_01C4E91E.07411FB0-- --===============1775891231== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1775891231==-- From mmusic-bounces@ietf.org Fri Dec 24 12:28:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00479 for ; Fri, 24 Dec 2004 12:28:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChtPH-000732-W5 for mmusic-web-archive@ietf.org; Fri, 24 Dec 2004 12:39:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cht5p-0001rA-6K; Fri, 24 Dec 2004 12:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chsyy-0007b5-5S for mmusic@megatron.ietf.org; Fri, 24 Dec 2004 12:12:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29243 for ; Fri, 24 Dec 2004 12:12:00 -0500 (EST) Received: from web50404.mail.yahoo.com ([206.190.38.69]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cht94-0006hi-R1 for mmusic@ietf.org; Fri, 24 Dec 2004 12:22:32 -0500 Received: (qmail 97526 invoked by uid 60001); 24 Dec 2004 17:11:31 -0000 Message-ID: <20041224171131.97525.qmail@web50404.mail.yahoo.com> Received: from [202.4.189.74] by web50404.mail.yahoo.com via HTTP; Fri, 24 Dec 2004 09:11:31 PST Date: Fri, 24 Dec 2004 09:11:31 -0800 (PST) From: sunil bhargo Subject: Re: [MMUSIC] Question on the Usage of Feature Tags in draft-ietf-mmusic-rfc2326bis-08.txt To: Thomas Zeng , mmusic@ietf.org, magnus.westerlund@ericsson.com In-Reply-To: <758B5A159B385447B4F950DE72D7D7AD678BD0@srsdmail01.PVNS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Hi Thomas, Clients having the capability to maintain the server capabilities might require server capabilities and not url specific capabilities. If the client and server have exchanged the capabilities previously. In future if the clients receives the meta-file having multiple urls for the same content and the SDP is received Out of Band for these urls then the client can use the previously determined capabilities to select which url to use to have best experience. But it also might be argued that if the client has such capability then it should use the OPTIONS with "*" to get the server capability. And the server capabilities will only be sent if url is "*" and if it is presentation url then the capabilities pretaining to the media are sent. But I would prefer that the Supported Header gives the server capabilities instead of the capabilities related to the url. If the server capabilities are used then it is still easy for the client to know what pretains to the current session (as media capabilities will be subset of total capabilities). sunil bhargo --- Thomas Zeng wrote: > Hello Magnus: > > Merry Christmas. > > We have been looking at the subject of capability > handling which led us to RFC2326bis-08, Chapter 10, > where it is suggested that the server uses the > Supported header to advertise the list of feature > tags it is capable of handling. > > It is worth clarifying whether the list of tags in > the Supported header should be a function of the > request URL or not. > > For instance, if a client issues a DESCRIBE on a > audio only request URL, and the server in its 200 OK > response includes the feature tag > "com.A_company.video-bit-stream-switching". Is that > appropriate? > > Clearly video-bit-stream-switching does not apply to > an audio-only URL, but one could argue that > video-bit-stream-switching is one of the server's > capabilities and the client may choose to take > advantage of it later on. > > What is your interpretation? What does the group > think? > > Thanks, > -Thomas > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 26 06:02:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12105 for ; Sun, 26 Dec 2004 06:02:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiWKs-0007Bp-5t for mmusic-web-archive@ietf.org; Sun, 26 Dec 2004 06:13:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiW9Q-0005cF-7c; Sun, 26 Dec 2004 06:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiW70-0005Lf-CW for mmusic@megatron.ietf.org; Sun, 26 Dec 2004 05:58:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11911 for ; Sun, 26 Dec 2004 05:58:55 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiWHT-00076l-8w for mmusic@ietf.org; Sun, 26 Dec 2004 06:09:48 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBQAwoh5009935; Sun, 26 Dec 2004 11:58:50 +0100 (MET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Dec 2004 11:58:50 +0100 Received: from [153.88.8.99] ([153.88.8.99]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Dec 2004 11:58:49 +0100 Message-ID: <41CD8B87.7030109@ericsson.com> Date: Sat, 25 Dec 2004 16:47:19 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng References: <758B5A159B385447B4F950DE72D7D7AD678BD0@srsdmail01.PVNS.COM> In-Reply-To: <758B5A159B385447B4F950DE72D7D7AD678BD0@srsdmail01.PVNS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2004 10:58:49.0666 (UTC) FILETIME=[E12C5A20:01C4EB39] X-Spam-Score: 0.4 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Question on the Usage of Feature Tags in draft-ietf-mmusic-rfc2326bis-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hi Thomas, My intention with "Supported" is that these are not linked to the URI, and instead describe features supported by the client and server depending on the direction of the message. In the case one has features that are media type specific, the ones understanding the features, knows that it is media specific. Also the definer of a feature must consider if further negotiation of the functionality is needed. The Supported mechanism is really only a mechanism for intial discovery of support of features. It has the meaning like: Hey, here is what I support, please send me what you can. So I could see that one clarifies this in the next version, I would propose to make the following change in the section 14.43, see last sentencte of paragraph 2: The Supported header field enumerates all the extensions supported by the client or server using feature tags. The header carries the extensions supported by the message sending entity. The Supported header MAY be included in any request. When present in a request, the receiver MUST respond with its corresponding Supported header. Note, also in 4xx and 5xx responses is the supported header included. The Supported header field contains a list of feature-tags, described in Section 3.7, that are understood by the client or server. The list is not depending on the request URI context, and describes the client and server capabilities in general. What do you say? Merry Chrismtas and a Happy new Year Magnus Thomas Zeng wrote: > Hello Magnus: > > Merry Christmas. > > We have been looking at the subject of capability handling which led us > to RFC2326bis-08, Chapter 10, where it is suggested that the server uses > the Supported header to advertise the list of feature tags it is capable > of handling. > > It is worth clarifying whether the list of tags in the Supported > header should be a function of the request URL or not. > > For instance, if a client issues a DESCRIBE on a audio only request URL, > and the server in its 200 OK response includes the feature tag > "com.A_company.video-bit-stream-switching". Is that appropriate? > > Clearly video-bit-stream-switching does not apply to an audio-only URL, > but one could argue that video-bit-stream-switching is one of the > server's capabilities and the client may choose to take advantage of it > later on. > > What is your interpretation? What does the group think? > > Thanks, > -Thomas -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Dec 26 14:17:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11364 for ; Sun, 26 Dec 2004 14:17:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cie3j-0001LX-Hp for mmusic-web-archive@ietf.org; Sun, 26 Dec 2004 14:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CidpU-0005QJ-Dc; Sun, 26 Dec 2004 14:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cidin-0004uP-IW; Sun, 26 Dec 2004 14:06:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10242; Sun, 26 Dec 2004 14:06:27 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CidtL-00011x-Sx; Sun, 26 Dec 2004 14:17:24 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Dec 2004 11:12:10 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBQJ5sHn013784; Sun, 26 Dec 2004 11:05:54 -0800 (PST) Received: from [192.168.1.101] (sjc-vpn4-227.cisco.com [10.21.80.227]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA22183; Sun, 26 Dec 2004 11:05:51 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 26 Dec 2004 11:13:08 -0700 Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern From: Cullen Jennings To: Peter Ridler , "'Joerg Ott'" , "'Colin Perkins'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" , "mmusic@ietf.org" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit What will your two SDP parse engines do differently? On 12/18/04 7:16 AM, "Peter Ridler" wrote: > > I also agree with Colin and Joerg. > > I will also have two SDP parse engines (one for RTP and another for MSRP). > This will complicate the code. Computers do not care about ugly formatting > --- overall performance should be the concern (I think all text formatted > protocols are a waste of network bandwidth and memory resources -- but I'm > stuck with them). > > We should follow the standards as best we can. If the standard does not > meet your requirements then define/use another. > > Another text based protocol is draft-ietf-sipping-toip-00.txt This fits the > SIP/SDP model nicely. > > Peter > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Joerg Ott >> Sent: Sunday, December 12, 2004 6:58 AM >> To: Colin Perkins >> Cc: Simple WG; mmusic@ietf.org >> Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern >> >> I agree with Colin on the ugliness issue of decomposing URLs >> into c= and m= lines. But this is the way SDP has worked and >> works today. >> >> The present discussion we are having here is about changing >> SDP to for address/URL handling in one particular case. This >> does not strike me as something MSRP should be concerned with. >> >> I would like to make one thing clear: we are either using >> existing tools in another document or we are building new >> ones. There is nothing much in between. >> >> Changing c=/m= semantics means changing SDP. Just because >> the syntax still looks the same does not mean that it is >> still the same protocol. >> Any entity or generic protocol engine used to dealing with >> SDP m=/c= would no longer do the right thing. >> >> We see this kind of approach quite often -- by far too often >> -- over the past years (just think the many "uses" of SIP >> defined elsewhere, usually resulting in something "a little >> but not entirely unlike" SIP). >> >> What I would like avoid is having special treatment of SDP >> depending on what the media type is (or other attributes signify). >> >> Therefore, I strongly agree with Colin's conclusion: take SDP >> as is or leave it altogether and pursue a different path. >> >> Joerg >> >> >> Colin Perkins wrote: >> >>> On 10 Dec 2004, at 21:41, Ben Campbell wrote: >>> >>>> I really need to get closure on this, so I'd appreciate people >>>> agreeing or disagreeing. >>>> >>>> I have had off-list correspondence indicating both >> positions. In summary: >>>> >>>> In favor of the change, I had a comment to the effect that >> changing >>>> SDP semantics to ignore the C line and the port field on >> the M line >>>> really changes it to something that is no longer SDP, and >> that such >>>> deviations are in general bad for interop. >>>> >>>> In favor of leaving things as currently specified, I had >> two comments >>>> that decomposing URLs into the C and M lines is ugly, and >> that having >>>> a different mechanism to communicate endpoint addresses vs relay >>>> addresses is really ugly. >>>> >>>> So, do people agree with one or the other position? >>> >>> >>> Decomposing the URL into the "c=" and "m=" lines is very ugly. >>> Unfortunately, that ugliness is required if you want to use >> SDP. This >>> is why the SDPng work was started, to try to move to something less >>> horrible... >>> >>> Colin >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > 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-bounces@ietf.org Sun Dec 26 21:23:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13510 for ; Sun, 26 Dec 2004 21:23:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ciki5-00037w-4S for mmusic-web-archive@ietf.org; Sun, 26 Dec 2004 21:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CikVT-0001Rz-2Y; Sun, 26 Dec 2004 21:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CikV5-0001N2-HY for mmusic@megatron.ietf.org; Sun, 26 Dec 2004 21:20:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13331 for ; Sun, 26 Dec 2004 21:20:45 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cikfg-00034f-Sp for mmusic@ietf.org; Sun, 26 Dec 2004 21:31:46 -0500 Received: from razor.cs.columbia.edu (IDENT:9PuvtITjF8VcmUP9Igfn2FdUlPkom7fn@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBR2KFir021359 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 26 Dec 2004 21:20:29 -0500 (EST) Received: from [127.0.0.1] (IDENT:ZI47NNEvBhJg1tUucN9hg2nFPggwWHzg@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBR2K5iw022734; Sun, 26 Dec 2004 21:20:09 -0500 Message-ID: <41CF7154.5050600@cs.columbia.edu> Date: Sun, 26 Dec 2004 21:20:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] Maximum non-scaled image size References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> <41C71F30.1080302@vs.informatik.uni-ulm.de> <41C9D6DE.9090306@ericsson.com> In-Reply-To: <41C9D6DE.9090306@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.12.25.47 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Teodora Guenkova-Luy , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit One basic question is whether this shouldn't be defined for all video codecs, rather than having each codec do this slightly differently. Once this is clearer, we can then decide whether this is one parameter or possibly more. So far, all variations, whether motivated by frame buffer size or display size, seem to have the same effect: limit what the receiver is willing to receive or indicate what the sender will send, where the former seems somewhat more important. Magnus, I'm not sure where you perceive the difference in semantics to my earlier description. Magnus Westerlund wrote: > Hi, > > I would like to point out that 3GPP has defined in TS 26.234 a SDP > attribute a=framesize. It has the following definition: > > The following media level SDP field is defined for PSS: > > - "a=framesize: -" > > This gives the largest video frame size of H.263 streams. > The frame size field in SDP is needed by the client in order to properly > allocate frame buffer memory. For MPEG-4 Visual streams, the frame size > shall be extracted from the "config" information in the SDP. For H.264 > (AVC) streams, the frame size shall be extracted from the > sprop-parameters-sets information in the SDP. For H.263 streams, a PSS > server shall include the "a=framesize" field at the media level for each > stream in SDP, and a PSS client should interpret this field, if present. > Clients should be ready to receive SDP descriptions without this attribute. > > If this attribute is present, the frame size parameters shall exactly > match the largest frame size defined in the video stream. The width and > height values shall be expressed in pixels. > > However, to my understanding, this attribute is not what Henning is > seeking. I only like to warn you at an early stage about the potential > name conflict. I am sorry that I haven't had time yet to write the SDP > registration draft for the PSS specification. > > But on the point Henning is asking about, in the 3GPP Packet-based > Streaming Service, the servers can use UAProf to determine the clients > screen resolution. > > > Cheers > > Magnus > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 27 12:35:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01279 for ; Mon, 27 Dec 2004 12:35:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ciywf-0000by-C7 for mmusic-web-archive@ietf.org; Mon, 27 Dec 2004 12:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiydW-0001t2-OI; Mon, 27 Dec 2004 12:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiyXc-0000ag-2V for mmusic@megatron.ietf.org; Mon, 27 Dec 2004 12:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00044 for ; Mon, 27 Dec 2004 12:20:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiyiB-00009l-9Y for mmusic@ietf.org; Mon, 27 Dec 2004 12:31:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Dec 2004 10:28:44 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBRHJUdP006650; Mon, 27 Dec 2004 09:19:30 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn4-798.cisco.com [10.21.83.29]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBRHHUlD030411; Mon, 27 Dec 2004 09:17:30 -0800 In-Reply-To: <772BCEF88A1DD91191F80011856715F3245BA7@zin24exm01.ap.mot.com> References: <772BCEF88A1DD91191F80011856715F3245BA7@zin24exm01.ap.mot.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7950C465-582B-11D9-BAD6-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Mon, 27 Dec 2004 09:19:32 -0800 To: Vavilapalli Srikanth-A19563 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1104167850.438180"; x:"432200"; a:"rsa-sha1"; b:"nofws:726"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KBYgwetn3C6WGqvCtgrUx7ubAaBz0cfhi5vJrosJmoz6g1PaeHHoU8+oln8bi" "PbviC/9p3L8MhXyRHn7RWKarV92DYJr4MIlIWe5Oxgo0Vct4QAmea3WNMiRIs" "3x/km1U5826yiHlMn54qSM/Ji05baCJjzm9UYj9lCCE+H3mj4="; c:"From: Mark Baugher "; c:"Subject: Re: SDP Support for exchanging different auth tag length for " "SRTP and SRTCP"; c:"Date: Mon, 27 Dec 2004 09:19:32 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "'mmusic@ietf.org'" Subject: [MMUSIC] Re: SDP Support for exchanging different auth tag length for SRTP and SRTCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit This question has been answered, has it not? Mark On Dec 22, 2004, at 12:51 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > Ref: > > In this draft, I did not find a way to exchange the both SRTP and SRTCP > authentication tag lengths using SDP secure attributes. > > i.e. if a SRTP application wishes to use 32-bit weak authentication > for SRTP > packets and 80-bit strong authentication for SRTCP packets and has > chosen > the mechanism described in the above draft to communicate between > sender and > receiver, How can a offerer/answerer include this information in the > a=crypto line of SDP offer or answer respectively? > > Regards > Srikanth > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 27 13:37:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07460 for ; Mon, 27 Dec 2004 13:37:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cizus-0002YY-UA for mmusic-web-archive@ietf.org; Mon, 27 Dec 2004 13:48:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cizj9-0006lf-Q0; Mon, 27 Dec 2004 13:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CizZq-0005FX-9N for mmusic@megatron.ietf.org; Mon, 27 Dec 2004 13:26:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05700 for ; Mon, 27 Dec 2004 13:26:39 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CizkZ-00026N-Ss for mmusic@ietf.org; Mon, 27 Dec 2004 13:37:49 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBRIQ5O6018739; Mon, 27 Dec 2004 19:26:05 +0100 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Dec 2004 19:26:02 +0100 Received: from [153.88.9.124] ([153.88.9.124]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Dec 2004 19:26:00 +0100 Message-ID: <41D053B4.8030103@ericsson.com> Date: Mon, 27 Dec 2004 19:25:56 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [MMUSIC] Maximum non-scaled image size References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> <41C71F30.1080302@vs.informatik.uni-ulm.de> <41C9D6DE.9090306@ericsson.com> <41CF7154.5050600@cs.columbia.edu> In-Reply-To: <41CF7154.5050600@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Dec 2004 18:26:01.0620 (UTC) FILETIME=[84AD5D40:01C4EC41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Teodora Guenkova-Luy , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Hi Henning, See my comments below. I have restructured your paragraphs to try to answer your question as well as possible. > Magnus, I'm not sure where you perceive the difference in semantics to > my earlier description. > Based on the following Sentence: "Do any video payload formats specify, as SDP format attributes or otherwise, the maximum image size supported natively (i.e., without downscaling)?" It talks about native support of image size, which I interpreted to mean actual screen size. As the actual amount of macroblock, size of frame buffer, that a receiver is capable of decoding is different from what it natively can display. Thus I think there is clear reasons to separate the capability for decoding from that of displaying. However I don't necessarily think that it is appropriate to consider display resolution capabilities in SDP, and definitely not in any overlapping parameter. There are good reasons to differentiate the two capabilities. However if your not interested in the terminal display capabilities, but rather decoding capabilities, then see below. Henning Schulzrinne wrote: > One basic question is whether this shouldn't be defined for all video > codecs, rather than having each codec do this slightly differently. > The problem is that the video codecs do all provide some profiles and levels describing decoding capabilities. However of course the evolution of video encoding has resulted in that they are not described using a common profile and level description. Also as the profiles and levels describe more than simple image sizes, the profile and levels parameter would still be needed if a common frame size parameter existed. So if you simple want to determine the decoders capability to handle a screen size, then I think the profile and level system included in the H.26x and MPEG codec are quite sufficient. > Once this is clearer, we can then decide whether this is one parameter > or possibly more. So far, all variations, whether motivated by frame > buffer size or display size, seem to have the same effect: limit what > the receiver is willing to receive or indicate what the sender will > send, where the former seems somewhat more important. > I think one needs to make clear separation between frame-rate and frame-size. However I do not think that this is sufficient at all. There are so many other parameters in relation to decoding capabilities that are to be considered. A few of these are: number of reference frames, bit-rate according to the buffer model, number of macro blocks possible to decode in a certain time interval, codec features. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 27 13:47:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08353 for ; Mon, 27 Dec 2004 13:47:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj04q-0002qc-Fz for mmusic-web-archive@ietf.org; Mon, 27 Dec 2004 13:58:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cizjq-0006wB-Mm; Mon, 27 Dec 2004 13:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cizgk-0006HU-71 for mmusic@megatron.ietf.org; Mon, 27 Dec 2004 13:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06510 for ; Mon, 27 Dec 2004 13:33:47 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CizrU-0002MB-QO for mmusic@ietf.org; Mon, 27 Dec 2004 13:44:57 -0500 Received: from razor.cs.columbia.edu (IDENT:oBV81m33VOEdMMMN+XlkibPJ9ENXuqzN@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBRIXcir016380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 27 Dec 2004 13:33:39 -0500 (EST) Received: from [127.0.0.1] (IDENT:UeFz8S0wRcUj1c4qZZ6I4BqJuDRsZaBZ@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iBRIXciw026800; Mon, 27 Dec 2004 13:33:38 -0500 Message-ID: <41D05582.6040503@cs.columbia.edu> Date: Mon, 27 Dec 2004 13:33:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] Maximum non-scaled image size References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> <41C71F30.1080302@vs.informatik.uni-ulm.de> <41C9D6DE.9090306@ericsson.com> <41CF7154.5050600@cs.columbia.edu> <41D053B4.8030103@ericsson.com> In-Reply-To: <41D053B4.8030103@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.12.27.3 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CHILD_PORN_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Teodora Guenkova-Luy , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit > Based on the following Sentence: > "Do any video payload formats specify, as SDP format attributes or > otherwise, the maximum image size supported natively (i.e., without > downscaling)?" > > It talks about native support of image size, which I interpreted to mean > actual screen size. As the actual amount of macroblock, size of frame > buffer, that a receiver is capable of decoding is different from what it > natively can display. Thus I think there is clear reasons to separate > the capability for decoding from that of displaying. However I don't > necessarily think that it is appropriate to consider display resolution > capabilities in SDP, and definitely not in any overlapping parameter. > There are good reasons to differentiate the two capabilities. Fully agreed. Among other differences, the display size is likely a "soft" limit, i.e., something that the sender can exceed if you don't care about wasting bits. The frame buffer size seems more of a hard limit. > The problem is that the video codecs do all provide some profiles and > levels describing decoding capabilities. However of course the evolution > of video encoding has resulted in that they are not described using a > common profile and level description. Also as the profiles and levels > describe more than simple image sizes, the profile and levels parameter > would still be needed if a common frame size parameter existed. > > So if you simple want to determine the decoders capability to handle a > screen size, then I think the profile and level system included in the > H.26x and MPEG codec are quite sufficient. > >> Once this is clearer, we can then decide whether this is one parameter >> or possibly more. So far, all variations, whether motivated by frame >> buffer size or display size, seem to have the same effect: limit what >> the receiver is willing to receive or indicate what the sender will >> send, where the former seems somewhat more important. >> > > I think one needs to make clear separation between frame-rate and > frame-size. However I do not think that this is sufficient at all. There > are so many other parameters in relation to decoding capabilities that > are to be considered. A few of these are: number of reference frames, > bit-rate according to the buffer model, number of macro blocks possible > to decode in a certain time interval, codec features. I'm trying to find a common, useful subset that has high impact on either interoperability or efficiency. Clearly, there will always be codec-specific parameters, such as the ones you mention. Maximum display size and maximum frame buffer size, however, seem pretty universal. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 27 16:35:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02387 for ; Mon, 27 Dec 2004 16:35:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj2h8-0001re-Kv for mmusic-web-archive@ietf.org; Mon, 27 Dec 2004 16:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1hr-0004Nj-0z; Mon, 27 Dec 2004 15:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1dR-00028b-5p; Mon, 27 Dec 2004 15:38:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19962; Mon, 27 Dec 2004 15:38:31 -0500 (EST) Message-Id: <200412272038.PAA19962@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 27 Dec 2004 15:38:31 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --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 : Session Description Protocol Security Descriptions for Media Streams Author(s) : F. Andreasen, et al. Filename : draft-ietf-mmusic-sdescriptions-08.txt Pages : 39 Date : 2004-12-27 This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdescriptions-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-27154906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-27154906.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Dec 28 07:51:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21968 for ; Tue, 28 Dec 2004 07:51:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjGzV-0000yK-1D for mmusic-web-archive@ietf.org; Tue, 28 Dec 2004 08:02:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjGkx-00081d-Kv; Tue, 28 Dec 2004 07:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj3wM-0006iK-CQ; Mon, 27 Dec 2004 18:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15224; Mon, 27 Dec 2004 18:06:12 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj479-00068D-Gq; Mon, 27 Dec 2004 18:17:24 -0500 Received: from [192.168.0.108] (adsl-209-30-64-8.dsl.rcsntx.swbell.net [209.30.64.8]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBRN63OX014214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Dec 2004 17:06:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <41D0955B.2080704@nostrum.com> Date: Mon, 27 Dec 2004 17:06:03 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [MMUSIC] Re: [Simple] MSRP: SDP usage concern References: <3604A854-4AF4-11D9-91F3-000D93B0AE1A@nostrum.com> <6709D884-4B70-11D9-8877-000A957FC5F2@csperkins.org> <41BC325D.4010808@tzi.uni-bremen.de> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Dec 2004 07:47:18 -0500 Cc: Simple WG , Joerg Ott , mmusic@ietf.org, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > I have a question to SDP stack implementers that plan to implement > MSRP: Does the current way MSRP specifies the use of SDP (ignore the c > line address and the m line port and instead use the attribute a=path) > cause problems to you and requires you to do some hacking in your SDP > stack? If so, is that acceptable or do you prefer for your MSRP > implementation to implement two ways of contructing an MSRP URL > depending on the what the next hop is? Having implemented an SDP parser before, I can comfortably assert that the design I employed would require no modification at all to accommodate the usage proposed in MSRP. Users of the SDP parser would need to know to look in the a= lines for address information -- but this requires no stack changes. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 28 13:13:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14721 for ; Tue, 28 Dec 2004 13:13:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjM1t-0000x2-EA for mmusic-web-archive@ietf.org; Tue, 28 Dec 2004 13:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjLjr-00073i-Ev; Tue, 28 Dec 2004 13:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjLds-00063a-G7 for mmusic@megatron.ietf.org; Tue, 28 Dec 2004 13:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13732 for ; Tue, 28 Dec 2004 13:00:17 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjLop-0000a3-KU for mmusic@ietf.org; Tue, 28 Dec 2004 13:11:40 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBSI0IO6018313 for ; Tue, 28 Dec 2004 19:00:18 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Dec 2004 19:00:18 +0100 Received: from ericsson.com (rvi2-94-23.sw.ericsson.se [153.88.94.23]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YDRKG3J8; Tue, 28 Dec 2004 19:00:17 +0100 Message-ID: <41D19F2F.5060803@ericsson.com> Date: Tue, 28 Dec 2004 20:00:15 +0200 X-Sybari-Trust: 5732df32 a5e9b67f fd179718 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Dec 2004 18:00:18.0053 (UTC) FILETIME=[170D7B50:01C4ED07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Joerg Ott , Keith Drage Subject: [MMUSIC] Floor-media stream mappings X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Folks, I am working on a new version of the draft below, which will be an MMUSIC WG item as agreed in our last meeting in DC. http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sdp-bfcp-00.txt We need a means to provide clients with the Floor IDs to be used in the conference and with the mapping of each Floor ID with one or more media streams. For example, floor ID 123 maps to the media stream whose media label is 456. a=floorid:123 m-stream:456 We would like to get feedback on a couple of issues: 1) Do we want to include human readable information about the floors encoded in the SDP? (e.g., "request this floor if you want to make a comment on the issue being discussed" or "request this floor if you want to bring up a new issue to be discussed") 2) Do we want to allow the syntax of the 'floorid' attribute to express Floor IDs that do not map to any media stream? If the answer to both 1) and 2) is yes, we could use the floor control protocol to moderate face-to-face meetings where the media does not traverse any mixer, for example. Of course, both 1) and 2) are interesting features that will probably need to be supported by the conference policy. The question here is whether or not we want systems using solely SDP to have access to these features. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 28 16:30:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02356 for ; Tue, 28 Dec 2004 16:30:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjP6A-0007Nh-Eb for mmusic-web-archive@ietf.org; Tue, 28 Dec 2004 16:41:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOMl-00047t-HG; Tue, 28 Dec 2004 15:54:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjOJV-00028Q-KM; Tue, 28 Dec 2004 15:51:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25487; Tue, 28 Dec 2004 15:51:26 -0500 (EST) Message-Id: <200412282051.PAA25487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 28 Dec 2004 15:51:26 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) for Media Loopback Author(s) : K. Hedayat, et al. Filename : draft-ietf-mmusic-media-loopback-00.txt Pages : 14 Date : 2004-12-28 The wide deployment of VoIP and Video over IP services has introduced new challenges in managing and maintaining voice/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP or Video over IP service. Today in networks that deliver real-time media, short of running ' ping' and ' traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP and Video Over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-media-loopback-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-media-loopback-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: <2004-12-28152725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-media-loopback-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-media-loopback-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-28152725.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Dec 29 16:57:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24455 for ; Wed, 29 Dec 2004 16:57:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjm0H-000547-4f for mmusic-web-archive@ietf.org; Wed, 29 Dec 2004 17:09:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjlas-0005i1-Dd; Wed, 29 Dec 2004 16:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjkog-0000DN-5S for mmusic@megatron.ietf.org; Wed, 29 Dec 2004 15:53:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10427 for ; Wed, 29 Dec 2004 15:53:08 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjkzr-0000EC-2Y for mmusic@ietf.org; Wed, 29 Dec 2004 16:04:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Dec 2004 12:59:27 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBTKqVl2009683; Wed, 29 Dec 2004 12:52:31 -0800 (PST) Received: from [192.168.1.102] (sjc-vpn1-430.cisco.com [10.21.97.174]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVB81437; Wed, 29 Dec 2004 12:52:33 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 29 Dec 2004 13:52:33 -0700 Subject: Re: [MMUSIC] Floor-media stream mappings From: Cullen Jennings To: "gonzalo.camarillo@ericsson.com" , "mmusic@ietf.org" Message-ID: In-Reply-To: <41D19F2F.5060803@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Joerg Ott , Keith Drage X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit On 12/28/04 11:00 AM, "Gonzalo Camarillo" wrote: > Folks, > > I am working on a new version of the draft below, which will be an > MMUSIC WG item as agreed in our last meeting in DC. > > http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sdp-bfcp-00.txt > > We need a means to provide clients with the Floor IDs to be used in the > conference and with the mapping of each Floor ID with one or more media > streams. For example, floor ID 123 maps to the media stream whose media > label is 456. > > a=floorid:123 m-stream:456 > Just to make sure I understand - I assume that several floors could map to one media stream and a single floor could also map to multiple media stream (like audio and video). > We would like to get feedback on a couple of issues: > > 1) Do we want to include human readable information about the floors > encoded in the SDP? (e.g., "request this floor if you want to make a > comment on the issue being discussed" or "request this floor if you want > to bring up a new issue to be discussed") > no - the human language issues make me not want to do this. I'm fine with a a convention that if their is a floor, you probably need to request it if you want anyone to pay intention to your media. Clearly your second example would not follow this but I think there are many ways other that SDP that users could get the idea of what to floor was used for. I don't find these human readable things in SDP very useful in practice. That said, I don't feel strongly about this - it the human readable description is never used, it does no harm. It could also be added later if it was needed. > 2) Do we want to allow the syntax of the 'floorid' attribute to express > Floor IDs that do not map to any media stream? If the answer to both 1) > and 2) is yes, we could use the floor control protocol to moderate > face-to-face meetings where the media does not traverse any mixer, for > example. > yes And would also like to consider being able to specify a floor id when no media stream exists but where the media stream and association to floor will be added in a future SDP. It may be the requesting of the floor that causes the creation of the media stream. > Of course, both 1) and 2) are interesting features that will probably > need to be supported by the conference policy. The question here is > whether or not we want systems using solely SDP to have access to these > features. > > Thanks, > > Gonzalo > > > _______________________________________________ > 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