From magnus.westerlund@ericsson.com Fri Feb 1 00:16:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62521F891D for ; Fri, 1 Feb 2013 00:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.23 X-Spam-Level: X-Spam-Status: No, score=-105.23 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckauH3xvkJmc for ; Fri, 1 Feb 2013 00:16:10 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 325DF21F890E for ; Fri, 1 Feb 2013 00:16:10 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-2d-510b79c8b59c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 28.8D.19728.8C97B015; Fri, 1 Feb 2013 09:16:08 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 09:16:07 +0100 Message-ID: <510B79C7.9080500@ericsson.com> Date: Fri, 1 Feb 2013 09:16:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20130201080200.10072.73695.idtracker@ietfa.amsl.com> In-Reply-To: <20130201080200.10072.73695.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130201080200.10072.73695.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------030003080708070709070205" X-Brightmail-Tracker: H4sIAAAAAAAAA12SfSzUYRzA99z97vycXR7n7RtTJkUsiVpmafRqmU1qpf6I2/rNS7rpTm+a DRNCshzjNKQbnRVC8/ZHkV3eZjfz0oVbIlKqWXGIye/33B/Wf5/nu8/3Zd/vQ/MlIwIHOlaW yMhl0ngXoYgqiVhP3td91+Ks90yus19h9RQViILV6hVeGLosOnKViY+9xcj3H40Sxag+eSSs +d/Jev5RkILUvtnInAZ8EEbqsgWE7UBnqBNmIxEtwT0I2rMGKfKoQtBrbOOxlhh7wmr5Y44p 7AqGIq2QZSH2A/1yKse2+BzUd9SYfCvoKZmmWLbBbnC/MW+zG01b4xCo+y5mwxIcBDmftZxi jo+B0ThAsQpge3gxT5PZQmG8/jc3Jx+HwWKmEpFUT0hJyxLkIyvVlmaqLRphL1AOp5t4JzT/ eMInHAN/ehr/i4s2OQ1B5kwOT8X1jgJ9m54rKsGtCCaqAlTcWuoR6DoaKJVpkU9HSwVEakPQ NGlNpEIE3ROvKPZB4XU+fF1Wm8p6QHXvKMcU3gsb2gwByWhCMKZMERDJHYo1us0B2XVYwsvO XQTtoHiNIYYY+pTvhYTvQeXbd3xSRo+g7MMvHpmoEUHVnETFHcoZvi1ozNg6NtgR+r5YsmFr fAoaDKWI1LGBn8OTfJXpV8zWGARkvUHQr13gs6ns7ZfGAoniAhsZBWYVyLcGmV2XxsZH3/Zp QJt/s6Pp7+4WND5g04kcacrFXnzxpC5MgqOlicw1hklg5JHym/GMohPxaHOHFKS8FJdeknfG bVuzV0vZ1I38ylKdkzIgbrl1+4M0iFyxyFQEVoTuWeyKLBvomfFpVwy516Lcadmj05rzbzTH y5dkssHatvFnD/ttk4bCTywmOa8WHlZ3ameTd/hXhDTqXi+4XlnTB3d1h0akiifm2sMLDNLc ohXjfKAxeOTCISdvF0oRIz3gwZcrpP8A/KgnL2kDAAA= Subject: [MMUSIC] Fwd: I-D Action: draft-burman-rtcweb-mmusic-media-structure-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 08:16:14 -0000 --------------030003080708070709070205 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MMUSIC, This draft is intended as supporting material for next weeks interim meeting. Its main focus is on commonalities that exist between WebRTC and CLUE when it comes to identify and handle concepts in the multimedia transport. It also looks explicit at some by the authors perceived shortcomings and issues. There is also some discussion on the potential impact of the SDP evolution that is currently ongoing. I do hope you have time to review it. Cheers Magnus Westerlund --------------030003080708070709070205 Content-Type: message/rfc822; name="I-D Action: draft-burman-rtcweb-mmusic-media-structure-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-burman-rtcweb-mmusic-media-structure-00_tx"; filename*1="t.eml" X-Mozilla-Keys: Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by ESESSHC002.ericsson.se (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 1 Feb 2013 09:02:14 +0100 Received: from sessmg11.ericsson.net (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.86) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 09:02:11 +0100 X-AuditID: c1b4fb3d-b7f646d0000028e4-d8-510b7683d3df Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 11.1B.10468.3867B015; Fri, 1 Feb 2013 09:02:12 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B2E21F886D; Fri, 1 Feb 2013 00:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1359705723; bh=DZVYdGUK9aF9xM0hTFo4V0xXqnOgVdNSjA1QaydVyE8=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Hhsi24hdKcMYzNGJGEpCvy74E2luVCJK0OPW3xlgSTNagADBRnbOjyybXOP+KrGRu 2l+8yY/tfUHUJdO2Ih5Ml44edQGWJET+uYSNICshGp5WXJ2SKxKnSwJLGUiCmCEldb k8HE+DH0fzBLV8yWo1NTfzn2dUH8/tK82+Q8S5zw= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622AD21F8887 for ; Fri, 1 Feb 2013 00:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrKg6RQpLR91 for ; Fri, 1 Feb 2013 00:02:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9921F8698 for ; Fri, 1 Feb 2013 00:02:00 -0800 (PST) From: To: Subject: I-D Action: draft-burman-rtcweb-mmusic-media-structure-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130201080200.10072.73695.idtracker@ietfa.amsl.com> Date: Fri, 1 Feb 2013 00:02:00 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHfXe2nePc0dd5e5xd6FiWXTQr6FAaZVASlFrhByFq5asbzWk7 s6wg0tQPg67SNK1hYUazC9RAzYhaUZZCJoaFtajU1krRKLGr7exol2+/l///+T/P8/IwlKZZ qWVIsYWYTTojp1TJVzq2T1tQtjsoc6FnWM2XvnTSfMmLtzK+pFTgG/tX811X3TJ+wPZDyffa X9B89emvNF9VnsKPtV5SrFSlffvyVJmBslXJOcRo2E3MiSu2qfSvz3nowobg4q9dNuoguh1k RYEM4CVwtqdWIXEkdLqvKq1IxWhwM4L3TU5aelQhOF/ZLxcfcvyTAs9YvUwqmQsXHvX4WY7j Yfx+hUKqcCIY7z2hlExzoPpiJ7IixschcNkVK2EkVP8gkiMYnnjGJiL3w7nbdykpphfBaL11 YqTrCAarTvldLA6Fh6f65CIr8TRo9NqQyOE4Gmo6ztAih+E1cM1di6TUcBh6+pqa3POdw62Q clZBx/0RSlpgFnQMHJn4Cw7GKyppiaPBerjPzxhjsNe3+GfQ+Dw223N/vhqnwpkht0wcVI0P ISitsSvELdW+BmXfsyRPPDx/bJ/wrwBHlZM+hmbV/LOOyBSeD3Wtn5QST4emwdNUHaIcKEIg gpCfl5SUQMyGHYJQYEowEcs15DuXO87vKc2o7cpSF4pmZFwEu8USlKkJ3l6Qs1evE/RbzUVG IrhQDCPnotiW3voMDc7TWchOQgqJeVKdwjAcsBFFvspQM8kjxbkGo+WvLGMCXQgYNRfOhoge VijU5QuGPEl/hGZoo9gEUcCioC8y/amdPOguNFUbxqKAgACN2tc332D5X/eiKAZxYSwWU9QG k+VPutfXWOZrvKiCFhtbdH8l7UFEllVm7dq57sDN5PUj3d0nF9Marmn2yFjupgeOV8/iAm+1 q2MLPbHZo9rED2lvQhvaNsZtjDLat8QdMSUk7uuJXtu9nKobnFkw5LkyLzVo3wbvaPnn47nb qksbyD3ZjV/xe86ntt0YirtzYpgeeBDYvjnm6BTVp/Qs90dXS3Knx5sew8kFvS5pLmUWdL8B KVRtC8sDAAA= Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: esessmw0191.eemea.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Media Concepts and Relations Author(s) : Bo Burman Magnus Westerlund Filename : draft-burman-rtcweb-mmusic-media-structure-00.txt Pages : 22 Date : 2013-02-01 Abstract: There are currently significant efforts ongoing in IETF regarding more advanced multi-media functionalities, such as the work related to RTCWEB and CLUE. This work includes use cases for both multi- party communication and multiple media streams from an individual end-point. The usage of scalable encoding or simulcast encoding as well as different types of transport mechanisms have created additional needs to correctly identify different types of resources and describe their relations to achieve intended functionalities. The different usages have both commonalities and differences in needs and behavior. This document attempts to review some usages and identify commonalities and needs. It then continues to highlight important aspects that need to be considered in the definition of these usages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-burman-rtcweb-mmusic-media-structure There's also a htmlized version available at: http://tools.ietf.org/html/draft-burman-rtcweb-mmusic-media-structure-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030003080708070709070205-- From worley@shell01.TheWorld.com Fri Feb 1 15:37:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB22421F8849 for ; Fri, 1 Feb 2013 15:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZboMhZVp6M5 for ; Fri, 1 Feb 2013 15:37:21 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9B21F81FE for ; Fri, 1 Feb 2013 15:37:06 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r11NaPRW027612 for ; Fri, 1 Feb 2013 18:36:27 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r11NaPEF1017680 for ; Fri, 1 Feb 2013 18:36:25 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r11NaMnt1017265; Fri, 1 Feb 2013 18:36:22 -0500 (EST) Date: Fri, 1 Feb 2013 18:36:22 -0500 (EST) Message-Id: <201302012336.r11NaMnt1017265@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Comments on draft-alvestrand-one-rtp-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:37:21 -0000 general I think the concept is that the various media streams are demultiplexed out of the common RTP scheme by the fact that each payload type (codec type number) appears in at most one m= line of the bundle. But that isn't stated explicitly anywhere. In any case, the method for demultiplexing the RTP should be stated explicitly. section 4 If the answerer wishes to refuse an entire m= section, while accepting the RTP session otherwise, he MAY indicate this by setting the port number of the relevant section to zero. ... and remove that m= line's mid value from the group attribute. RFC 5888 section 9.2 section 7 In regard to RTCP, it appears that RTCP reports on each SSRC separately. I would expect that the bandwidth for the RTCP reports on a stream would be limited to 5% of the bandwidth for that stream. This keeps the total RTCP bandwidth below 5% of the total stream bandwidth; indeed it is what you would get if you simply merged the RTCP streams for the various media streams considered as separate RTP streams. In this configuration, the RTCP for an audio stream would never exceed the RTP for the audio stream. Although it does result in the frequency of reports differing between the various streams. Dale From worley@shell01.TheWorld.com Fri Feb 1 15:38:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA721F8FA9 for ; Fri, 1 Feb 2013 15:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft4xNNppYhKN for ; Fri, 1 Feb 2013 15:38:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id F092B21F8F5F for ; Fri, 1 Feb 2013 15:38:01 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r11NbeaW030733 for ; Fri, 1 Feb 2013 18:37:42 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r11NbeMq1014308 for ; Fri, 1 Feb 2013 18:37:40 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r11Nbe6C1014772; Fri, 1 Feb 2013 18:37:40 -0500 (EST) Date: Fri, 1 Feb 2013 18:37:40 -0500 (EST) Message-Id: <201302012337.r11Nbe6C1014772@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:38:03 -0000 generally Conceptually, this draft looks on the task as being: we either establish a set of media streams defined by a set of m= lines, or we establish a RTP stream that contains multiple media types. I think this is slightly incorrect, the MMT RTP stream should be seen as a container that encapsulates several media streams -- the anymedia m= line describes the container and its properties, and the constituent m= lines describe the constituent media streams. (And it is possible that two constituent media streams have the same media type -- one can easily have more than one audio or video stream in a session.) Within that change, an answer that accepts the MMT m= line should be allowed to also accept/reject the constituent m= lines, to indicate whether or not it wants to process those particular media streams within the bundle. (The port numbers for the constituent m= lines in the answer would be dummies, only significant as to whether they are zero or not, just as the port numbers for the constituent m= lines in the offer become dummies if the MMT is accepted.) abstract "5-tuple" should be defined; it is not commonly used in RFCs. section 4 Is there any reason to restrict MMT from being used in non-O/A situations? Of course, there would have to be out-of-band knowledge that the interpreter of the SDP understands MMT, but out-of-band knowledge (e.g., of the media types and codecs supported) is required in non-O/A situations already. section 5.2.1 A "MMT" group MUST contain a "anymedia" SDP Media Description, and at ------------------------------^ should be "exactly one" least one SDP Media Description for a specific SDP Media Type (audio, video, etc). From a "MMT" group the SDP Answerer [RFC3264] will accept either the SDP Media Descriptions for the specific SDP Media Types, or the "anymedia" SDP Media Description. This doesn't allow the answerer to reject all of the media in the group. A more complete phrasing: From a "MMT" group, the SDP Answerer [RFC3264] will either (1) accept the "anymedia" SDP Media Description and reject the specific SDP media types, (2) reject the "anymedia" SDP Media Description and accept some or all of the specific SDP media types, or (3) reject both the "anymedia" SDP Media Description and the specific SDP media types (to reject all the media streams in any form). However, that would change if the answerer was allowed to accept/reject specific media streams even when they were bundled into the anymedia stream. section 5.2.2.1 1) Include a "anymedia" SDP Media Description; and --------------^ should be "exactly one" section 5.2.2.2 2) Reject the "anymedia" SDP Media Description, and accept some or all of the other SDP Media Descriptions associated with the MMT group. But the answerer must be allowed to reject *both* the anymedia m= line and all of the contained m= lines (if it doesn't like any of the media streams involved). So it would be easier to specify: When an SDP Answerer generates an SDP Answer, for each "MMT" group in the associated SDP Offer, if it accepts the "anymedia" SDP Media Description, it MUST reject all of the other SDP Media Descriptions associated with the MMT group. Within this dichotomy, it would be useful to spell out the consequences for the a=group:MMT line, viz.: 1) [...] Consequently, the mid values of the rejected lines are removed from the a=group:MMT line in the answer. Or, 2) [...] Consequently, the a=group:MMT line is removed from the answer. However, that would change if the answerer was allowed to accept/reject specific media streams even when they were bundled into the anymedia stream. NOTE: As described in [RFC3264], an SDP Media Description can be -------------------------------------------------------------^^^^^^ This probably should be "is", as there is no other way to reject a media description. rejected by setting the port value of the associated m- line to zero in the SDP Answer. ... and remove that m= line's mid value from the group attribute. RFC 5888 section 9.2 section 6.1 It allows, if both endpoints support the mechanism, multiple media typex to be multiplexed on a single 5-tuple. More exactly stated, it allows multiple media *streams* to be multiplexed on a single 5-tuple. (In some cases, all of the streams may have the same media *type*, but we still want to be able to distinguish them.) [...] the SDP mmtype attribute will be used to map each PT to a specific media type (e.g. audio, video, etc). ditto In addition, as it might not always be possible to retreive the media type from the "rtpmap" SDP Attribute value, [...] ---^^^^^^^^ I think "determine" is better here. section 6.3 NOTE: Additional extensions are needed in order to specify SDP Attribute values for individual media types, or individual media sources, associated with the "anymedia" SDP Media Description. Perhaps the attributes given on the constituent m= lines would specify the attributes for the constituent media streams. Alternatively, we could define: a=mmtattr::: to provide "a=:" for the constituent media stream identified by "a=mid:". section 7 If mmtype is to properly demultiplex received RTP, it has to specify which of the constituent m= lines that particular PT is mapped to -- just knowing the media type and codec name is not necessarily sufficient, since more than one constituent m= line use a single codec. Also, how is RTCP to be demultiplexed? (Probably throught SSRCs.) section 7.2 a=mmtype: format media Presumably the space after ":" is a typo. (Given the syntax rules of SDP, a space appearing in that location is significant.) A better syntax would be: a=mmtype: That would specify the mid value of the constituent media stream. But of course, once we know the mid value, we can determine the media type from the corresponding m= line. Which would suggest a syntax like: a=mmtype: Or all the formats for a single mid could be specified together: a=mmtype: ... It would be useful to mention here that the format number in the anymedia m= line does not have to be the same as the format number in the constituent m= line for the same codec, but that the codec does have to appear in the constituent m= line. (Or do we wish to require that the format numbers be the same, for sanity's sake?) section 9 SDP Answer (multiplexed media types accepted) [...] a=group:MMT foo bar This is backwards; it must be "a=group:MMT zoe" based on RFC 5888 section 9.2. (Though I'm proposing to change what this attribute value would be; see below.) SDP Answer (multiplexed media types not accepted) [...] a=group:MMT foo bar This attribute is incorrect, as the group does not contain one m= line for anymedia. This attribute should be omitted. Incorporating the above suggestions into the examples (changes indicated by ">"), the offer becomes: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:MMT foo bar zoe m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 20000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=anymedia 30000 RTP/AVP 0 8 97 31 32 a=mid:zoe a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 > a=mmtype:foo 0 8 97 > a=mmtype:bar 31 32 The answer accepting the MMT group (and both constituent streams) becomes: v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 > a=group:MMT foo bar zoe > m=audio 1 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 > m=video 1 RTP/AVP 32 a=mid:bar a=rtpmap:32 MPV/90000 m=anymedia 60000 RTP/AVP 0 32 a=mid:zoe a=rtpmap:0 PCMU/8000 a=rtpmap:32 MPV/90000 > a=mmtype:foo 0 > a=mmtype:bar 32 The answer rejecting the MMT group (but accepting both constituent streams independently) becomes: v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 > [a=group:MMT omitted] m=audio 40000 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 m=video 50000 RTP/AVP 32 a=mid:bar a=rtpmap:32 MPV/90000 m=anymedia 0 RTP/AVP 0 32 a=mid:zoe [The a=mid attributes may be missing if the answerer does not understand SDP grouping.] Dale From worley@shell01.TheWorld.com Fri Feb 1 15:39:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED8221F8FAA for ; Fri, 1 Feb 2013 15:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifm1XLP8oO5m for ; Fri, 1 Feb 2013 15:39:06 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2721F8849 for ; Fri, 1 Feb 2013 15:39:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r11Nc55P031543 for ; Fri, 1 Feb 2013 18:38:09 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r11Nc5Bv999001 for ; Fri, 1 Feb 2013 18:38:05 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r11Nc5R81012849; Fri, 1 Feb 2013 18:38:05 -0500 (EST) Date: Fri, 1 Feb 2013 18:38:05 -0500 (EST) Message-Id: <201302012338.r11Nc5R81012849@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:39:06 -0000 general I think the concept is that the various media streams are demultiplexed out of the common RTP scheme by the fact that each payload type (codec number) appears in at most one m= line of the bundle. (If so, the payload type values on each m= line must be distinct, not just the *dynamic* payload type values. section 7.2) But that isn't stated explicitly anywhere. In any case, the method for demultiplexing the bundle should be stated explicitly. Also, how the RTCP reports are to be demultiplexed needs to be made explicit. (Though I suspect that is via SSRCs.) If one or more of the m= lines specifies encryption, how is encryption coordinated between the various media streams? What is the fallback if the offerer uses BUNDLE but the answerer does not understand it? RFC 4566 says that the use of multiple m= lines with the same address/port is undefined, which means that a non-understanding the answerer is allowed to reject the offer as malformed. section 1 "5-tuple" should be defined the group will share a single port number value The group will also share a single address, so it would be clearer to say "share a single address and port value". Or you could phrase it as simply "share a single port". But saying "a single port number value" suggests that the addresses might be different even though the port numbers are the same. there is no grouping defined by such means I assume this means that sharing the port number does not imply grouping. Better to phrase this "sharing a port number does not imply grouping". section 6.1 assign SDP media- level 'mid' attribute values to each "m=" line associated with the "BUNDLE" group. 'mid' attributes are required for all the m= lines. RFC 5888 section 6 NOTE: If an entity wants to disable specific media ("m=" line) associated with a "BUNDLE" group, it will use a zero port number value for the "m=" line associated with the media. ... and remove that m= line's mid value from the group attribute. RFC 5888 section 9.2 section 6.2 If the SDP Answererer should be "Answerer" If the SDP Answererer indicates that it will not use bundled media, the SDP Offerer will still use the single port number value for each "m= line" associated with the offered "BUNDLE" group, and it will -------------------------------------------------------------^^ normally be able to separate each individual media. should probably be specified as "the Offerer" The default mechanism for separating media received on a single IP address and port doing this is by using a 5-tuple based mapping for each individual media. This would be clearer if it was phrased "The default mechanism for separating media received on a single IP address and port is by using the sending address/port to identify each media stream." Although the possibility of this requires symmetric media, which is very common, but not required by RFC 326[1-5]. What do we do if symmetric media isn't in use? If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has ----------------------------------------------^ reasons to believe that the rejection is due to the usage of a single I think you intended to insert "is rejected" here. section 6.2 says: If the SDP Offerer is aware of the Synchronization Source (SSRC) [RFC3550] values that the SDP Answerer will use in the media it sends, and the SSRC values will be unique for each media, the SDP Offerer can separate media based on the SSRC values. but section 7.2 says: When a single RTP Session is used, media associated with all "m=" lines part of a bundle group share a single SSRC [RFC3550] numbering space. Is multiple SSRC supported or not? Or is the intention that the SSRC values have to be different from each other? Sometimes that is the implication of "sharing a space". But by their very nature (RFC 3550 section 8), all SSRCs are from a single numbering space of unsigned 32-bit integers. section 7.2 If transmission of multiple media types are done with time overlap RTP and RTCP fails to function. I don't understand this sentence. I suspect some words are missing. Dale From worley@shell01.TheWorld.com Fri Feb 1 15:39:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041F821F8849 for ; Fri, 1 Feb 2013 15:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-1.519, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN2BMv0fKCzc for ; Fri, 1 Feb 2013 15:39:06 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 140B121F8F3A for ; Fri, 1 Feb 2013 15:39:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r11NcgY2000345 for ; Fri, 1 Feb 2013 18:38:44 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r11NcgUZ1018297 for ; Fri, 1 Feb 2013 18:38:42 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r11NcgY31009097; Fri, 1 Feb 2013 18:38:42 -0500 (EST) Date: Fri, 1 Feb 2013 18:38:42 -0500 (EST) Message-Id: <201302012338.r11NcgY31009097@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Thoughts on bundling mechanisms X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:39:07 -0000 After reading draft-alvestrand-one-rtp-01 draft-holmberg-mmusic-sdp-mmt-negotiation-00 draft-ietf-mmusic-sdp-bundle-negotiation-00 draft-nandakumar-rtcweb-sdp-00 here are my thoughts on bundling: 1. Concept Overall, we need to fix the concept that a bundle is a container for a group of media streams, media streams as they are specified by m= lines. We need to be able to bundle multiple media streams in a way that allows them to be demultiplexed accurately, even if different streams share the same media types, codecs, etc. In this regard, the transport protocol, transport ports, encryption specifications, ICE specifications, and (less obviously) payload type numbers are considered to be part of the transport mechanism and not part of the media stream properties. The m= line for a bundle should have all the "transport" attribues needed for the bundle, while the m= lines for the constituent media streams would have the attributes that describe the media stream itself. (This distinction gets undermined if we use payload types to demultiplex the media streams, as the bundle m= line has to list the payload types, and thus probably the codec names and parameters, which are really constituent-level information. One solution would be to require that if a bundle payload type is demultiplexed to a particular m= line, then that m= line must have the same payload type with the same codec. Indeed, there's no particular reason for the bundle m= line to have a=fmtp attributes at all, though the m= line should probably list all the payload types the bundle RTP is going to use.) 2. Configuration of m= lines There needs to be a fallback mechanism if the answerer does not understand the bundling mechanism. draft-ietf-mmusic-sdp-bundle-negotiation (BUNDLE) specifies that a bundle of m= lines all specify the same port number. That is OK if the answerer understands BUNDLE, but if the answerer does not understand BUNDLE, the SDP is malformed (per RFC 4566 section 5.14), and the answerer may reject it as such. Because of this, we need to adopt the mechanism of draft-alvestrand-one-rtp (TOGETHER), where each m= line in the offer has a distinct port number. There also needs to be a way for the answerer to individually accept or reject media streams within the bundle, that is, the m= lines within the bundle. TOGETHER does not accomplish that, because the first m= line in the bundle is the one used to send/receive media (if the bundle is accepted), and so it cannot be rejected. As draft-alvestrand-one-rtp says The answerer cannot refuse the first m= section and establish the call. [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE is in use, or saying that the first non-zero port number is used. Both lead to nonobvious edge cases. Is the extra complexity worth it?]] draft-holmberg-mmusic-sdp-mmt-negotiation (MMT) avoids this problem by associating with each bundle a "master" m= line with media type "anymedia". If the bundle is accepted, this m= line provides the transport information. If the bundle is rejected, then the answerer accepts or rejects each constituent m= line separately, and that m= lines attributes determine the transport mechanism. However, MMT needs to be updated to match the concept that the anymedia RTP stream multiplexes what would be the RTP streams of one or more constituent media streams. Currently, it assumes that identifying the media type of an incoming RTP packet is sufficient demultiplexing. As a consequence of this, it needs to be modified so that if the answerer accepts the MTT bundle (and thus, the anymedia m= line), it still must accept or reject each constituent m= line individually. 3. Demultiplexing RTP MMT envisions that the media data is demultiplexed based on the payload types: The m=anymedia description contains a set of a=mmttype attributes that (I think should) provide the mapping from the payload types to the mid values of the constituent m= lines. (The codec for each payload type is provided by a=fmtp attributes of the m=anymedia description as normal.) Note that this does not allow recovery of the payload types that would have been used for that codec and m= line (if multiple payload types for that m= line have the same codec). But we assume that payload types are a transport matter and are of no interest to the higher layers of media processing. But perhaps instead, we should require that there be a matching payload type for the constituent m= line and use its a=fmtp attribute. That allows us to not duplicate any codec specifications from the constituent m= lines into the m=anymedia line, and does allow recovering the "original" payload types. 4. RTCP My knowledge of RTCP is very thin. But it's clear that incoming RTCP over the bundle transport must be demultiplexable to the point that we can separate which RTCP information is applicable to which constituent media stream. My understanding is that RTCP information is identified by the SSRC of the media source it is reporting on, and that it is paired with the right media stream by examining the SSRC value in the RTP packet headers. If so, demultiplexing RTCP requires no new protocol facilities. In regard to bandwidth consumption, I assume that the bundle's RTCP stream is essentially the union of the RTCP streams (or rather, the RCTP packets thereof, which are packed into the transport-level RTCP packets) that would be generated for each constituent m= line. In particular, the frequency of the RTCP packets for a particular media stream is scaled to the needs of that media stream, rather than there being RTCP reports at same frequency for all media streams. Thus, as long as the RTCP reports on each media stream are less than 5% of the RTP bandwidth for that media stream, the aggregate RTCP bandwidth is less then 5% of the aggregate RTP bandwidth. 5. Examples Incorporating these suggestions into draft-holmberg-mmusic-sdp-mmt-negotiation, I get this example: SDP Offer (MMT offered) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:MMT foo bar zoe m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 20000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=anymedia 30000 RTP/AVP 0 8 97 31 32 a=mid:zoe a=mmtype:foo 0 8 97 a=mmtype:bar 31 32 SDP Answer (MMT accepted, including both constituent streams) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 a=group:MMT foo bar zoe m=audio 1 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 m=video 1 RTP/AVP 32 a=mid:bar a=rtpmap:32 MPV/90000 m=anymedia 60000 RTP/AVP 0 32 a=mid:zoe a=mmtype:foo 0 a=mmtype:bar 32 SDP Answer (MMT not accepted, but both constituent streams accepted) v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.com s= c=IN IP4 host.biloxi.com t=0 0 m=audio 40000 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 m=video 50000 RTP/AVP 32 a=mid:bar a=rtpmap:32 MPV/90000 m=anymedia 0 RTP/AVP 0 a=mid:zoe [The a=mid attributes may be missing if the answerer does not understand SDP grouping.] SDP Offer with ICE (multiplexed media types offered) v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.com s= c=IN IP4 host.atlanta.com t=0 0 a=group:MMT foo bar zoe m=audio 10000 RTP/AVP 0 8 97 a=mid:foo b=AS:200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host m=video 20000 RTP/AVP 31 32 a=mid:bar b=AS:1000 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:1 1 UDP 1694498815 host.atlanta.com 20000 typ host m=anymedia 30000 RTP/AVP 0 8 97 31 32 a=mid:zoe a=mmtype:foo 0 8 97 a=mmtype:bar 31 32 a=candidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host Dale From harald@alvestrand.no Sat Feb 2 08:54:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8121F8629 for ; Sat, 2 Feb 2013 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.64 X-Spam-Level: X-Spam-Status: No, score=-108.64 tagged_above=-999 required=5 tests=[AWL=-1.641, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ZTccELQVGI for ; Sat, 2 Feb 2013 08:54:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E506D21F84BA for ; Sat, 2 Feb 2013 08:54:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 93B4D39E140; Sat, 2 Feb 2013 17:54:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk1Mci-4M5NG; Sat, 2 Feb 2013 17:54:12 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1] (unknown [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2B39139E070; Sat, 2 Feb 2013 17:54:12 +0100 (CET) Message-ID: <510D44B1.5050707@alvestrand.no> Date: Sat, 02 Feb 2013 17:54:09 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dale R. Worley" References: <201302012338.r11NcgY31009097@shell01.TheWorld.com> In-Reply-To: <201302012338.r11NcgY31009097@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Thoughts on bundling mechanisms X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 16:54:18 -0000 On 02/02/2013 12:38 AM, Dale R. Worley wrote: > After reading > draft-alvestrand-one-rtp-01 > draft-holmberg-mmusic-sdp-mmt-negotiation-00 > draft-ietf-mmusic-sdp-bundle-negotiation-00 > draft-nandakumar-rtcweb-sdp-00 > here are my thoughts on bundling: > > 1. Concept > > Overall, we need to fix the concept that a bundle is a container for a > group of media streams, media streams as they are specified by m= > lines. We need to be able to bundle multiple media streams in a way > that allows them to be demultiplexed accurately, even if different > streams share the same media types, codecs, etc. > > In this regard, the transport protocol, transport ports, encryption > specifications, ICE specifications, and (less obviously) payload type > numbers are considered to be part of the transport mechanism and not > part of the media stream properties. > > The m= line for a bundle should have all the "transport" attribues > needed for the bundle, while the m= lines for the constituent media > streams would have the attributes that describe the media stream > itself. This is an interesting concept - if I understand you correctly, you say that instead of having an m-line describe one or more media streams + a set of transport attributes, you have two kinds of m-lines, one of which describes transport attributes and the other one of which specifies media information. This is a new concept - I think it would be an interesting evolution of SDP - but I have problems seeing how to make any kind of one-exchange compatibility mode function with this model. I may be misunderstanding your suggestion. > > (This distinction gets undermined if we use payload types to > demultiplex the media streams, as the bundle m= line has to list the > payload types, and thus probably the codec names and parameters, which > are really constituent-level information. One solution would be to > require that if a bundle payload type is demultiplexed to a particular > m= line, then that m= line must have the same payload type with the > same codec. Indeed, there's no particular reason for the bundle m= > line to have a=fmtp attributes at all, though the m= line should > probably list all the payload types the bundle RTP is going to use.) I think we all agree that multiplexing different media streams using payload type is a horrible idea, and nobody should do that. > > 2. Configuration of m= lines > > There needs to be a fallback mechanism if the answerer does not > understand the bundling mechanism. > draft-ietf-mmusic-sdp-bundle-negotiation (BUNDLE) specifies that a > bundle of m= lines all specify the same port number. That is OK if > the answerer understands BUNDLE, but if the answerer does not > understand BUNDLE, the SDP is malformed (per RFC 4566 section 5.14), > and the answerer may reject it as such. Because of this, we need to > adopt the mechanism of draft-alvestrand-one-rtp (TOGETHER), where each > m= line in the offer has a distinct port number. > > There also needs to be a way for the answerer to individually accept > or reject media streams within the bundle, that is, the m= lines > within the bundle. TOGETHER does not accomplish that, because the > first m= line in the bundle is the one used to send/receive media (if > the bundle is accepted), and so it cannot be rejected. As > draft-alvestrand-one-rtp says > > The answerer cannot refuse the first m= section and establish the > call. [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE > is in use, or saying that the first non-zero port number is used. > Both lead to nonobvious edge cases. Is the extra complexity worth > it?]] > > draft-holmberg-mmusic-sdp-mmt-negotiation (MMT) avoids this problem by > associating with each bundle a "master" m= line with media type > "anymedia". If the bundle is accepted, this m= line provides the > transport information. If the bundle is rejected, then the answerer > accepts or rejects each constituent m= line separately, and that m= > lines attributes determine the transport mechanism. > > However, MMT needs to be updated to match the concept that the > anymedia RTP stream multiplexes what would be the RTP streams of one > or more constituent media streams. Currently, it assumes that > identifying the media type of an incoming RTP packet is sufficient > demultiplexing. As a consequence of this, it needs to be modified so > that if the answerer accepts the MTT bundle (and thus, the anymedia m= > line), it still must accept or reject each constituent m= line > individually. > > 3. Demultiplexing RTP > > MMT envisions that the media data is demultiplexed based on the > payload types: The m=anymedia description contains a set of a=mmttype > attributes that (I think should) provide the mapping from the payload > types to the mid values of the constituent m= lines. (The codec for > each payload type is provided by a=fmtp attributes of the m=anymedia > description as normal.) I disagree with that characterization. All of MMT, BUNDLE and TOGETHER agree that demultiplexing is based on SSRC. The payload type tells you what type the payload is. > > Note that this does not allow recovery of the payload types that would > have been used for that codec and m= line (if multiple payload types > for that m= line have the same codec). But we assume that payload > types are a transport matter and are of no interest to the higher > layers of media processing. I don't understand this sentence. The payload type is "recovered" by looking at the 7-bit field called "payload type" in the RTP header of each RTP packet. It's hardly a transport matter at all. > > But perhaps instead, we should require that there be a matching > payload type for the constituent m= line and use its a=fmtp > attribute. That allows us to not duplicate any codec specifications > from the constituent m= lines into the m=anymedia line, and does allow > recovering the "original" payload types. > > 4. RTCP > > My knowledge of RTCP is very thin. But it's clear that incoming RTCP > over the bundle transport must be demultiplexable to the point that we > can separate which RTCP information is applicable to which constituent > media stream. My understanding is that RTCP information is identified > by the SSRC of the media source it is reporting on, and that it is > paired with the right media stream by examining the SSRC value in the > RTP packet headers. If so, demultiplexing RTCP requires no new > protocol facilities. > > In regard to bandwidth consumption, I assume that the bundle's RTCP > stream is essentially the union of the RTCP streams (or rather, the > RCTP packets thereof, which are packed into the transport-level RTCP > packets) that would be generated for each constituent m= line. In > particular, the frequency of the RTCP packets for a particular media > stream is scaled to the needs of that media stream, rather than there > being RTCP reports at same frequency for all media streams. Thus, as > long as the RTCP reports on each media stream are less than 5% of the > RTP bandwidth for that media stream, the aggregate RTCP bandwidth is > less then 5% of the aggregate RTP bandwidth. > > 5. Examples > > Incorporating these suggestions into > draft-holmberg-mmusic-sdp-mmt-negotiation, I get this example: > > SDP Offer (MMT offered) > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > s= > c=IN IP4 host.atlanta.com > t=0 0 > a=group:MMT foo bar zoe > m=audio 10000 RTP/AVP 0 8 97 > a=mid:foo > b=AS:200 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:97 iLBC/8000 > m=video 20000 RTP/AVP 31 32 > a=mid:bar > b=AS:1000 > a=rtpmap:31 H261/90000 > a=rtpmap:32 MPV/90000 > m=anymedia 30000 RTP/AVP 0 8 97 31 32 > a=mid:zoe > a=mmtype:foo 0 8 97 > a=mmtype:bar 31 32 This seems to indicate that zoe "incorporates by reference" the foo and bar m-lines. A better name in this case might be "m=transport" rather than "m=anymedia". > > SDP Answer (MMT accepted, including both constituent streams) > > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.com > s= > c=IN IP4 host.biloxi.com > t=0 0 > a=group:MMT foo bar zoe > m=audio 1 RTP/AVP 0 > a=mid:foo > a=rtpmap:0 PCMU/8000 > m=video 1 RTP/AVP 32 > a=mid:bar > a=rtpmap:32 MPV/90000 > m=anymedia 60000 RTP/AVP 0 32 > a=mid:zoe > a=mmtype:foo 0 > a=mmtype:bar 32 Query: Are you making the port number 1 in the m=audio and m=video lines carry special meaning? > > SDP Answer (MMT not accepted, but both constituent streams accepted) > > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.com > s= > c=IN IP4 host.biloxi.com > t=0 0 > m=audio 40000 RTP/AVP 0 > a=mid:foo > a=rtpmap:0 PCMU/8000 > m=video 50000 RTP/AVP 32 > a=mid:bar > a=rtpmap:32 MPV/90000 > m=anymedia 0 RTP/AVP 0 > a=mid:zoe > [The a=mid attributes may be missing if the answerer does not > understand SDP grouping.] > > SDP Offer with ICE (multiplexed media types offered) > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.com > s= > c=IN IP4 host.atlanta.com > t=0 0 > a=group:MMT foo bar zoe > m=audio 10000 RTP/AVP 0 8 97 > a=mid:foo > b=AS:200 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:97 iLBC/8000 > a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host > m=video 20000 RTP/AVP 31 32 > a=mid:bar > b=AS:1000 > a=rtpmap:31 H261/90000 > a=rtpmap:32 MPV/90000 > a=candidate:1 1 UDP 1694498815 host.atlanta.com 20000 typ host > m=anymedia 30000 RTP/AVP 0 8 97 31 32 > a=mid:zoe > a=mmtype:foo 0 8 97 > a=mmtype:bar 31 32 > a=candidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host Based on this offer, I don't quite see what this offer buys you above the MMT proposal. From harald@alvestrand.no Sat Feb 2 10:38:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3154321F853E for ; Sat, 2 Feb 2013 10:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.303 X-Spam-Level: X-Spam-Status: No, score=-110.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW5L6CJd-iZQ for ; Sat, 2 Feb 2013 10:38:57 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD1D21F84E6 for ; Sat, 2 Feb 2013 10:38:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D471139E140 for ; Sat, 2 Feb 2013 19:38:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpEqAXF432Ka for ; Sat, 2 Feb 2013 19:38:53 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1] (unknown [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AC08A39E070 for ; Sat, 2 Feb 2013 19:38:53 +0100 (CET) Message-ID: <510D5D3C.1060103@alvestrand.no> Date: Sat, 02 Feb 2013 19:38:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <201302012336.r11NaMnt1017265@shell01.TheWorld.com> In-Reply-To: <201302012336.r11NaMnt1017265@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Comments on draft-alvestrand-one-rtp-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 18:38:58 -0000 On 02/02/2013 12:36 AM, Dale R. Worley wrote: > general > > I think the concept is that the various media streams are > demultiplexed out of the common RTP scheme by the fact that each > payload type (codec type number) appears in at most one m= line of the > bundle. But that isn't stated explicitly anywhere. In any case, the > method for demultiplexing the RTP should be stated explicitly. This is incorrect. Media streams are demultiplexed by SSRC. Payload types are specified in at most one m= line because if the same payload type value appeared in two different m= lines, it would be impossible to tell from the incoming RTP packet which type it was intended to be. > > section 4 > > If the answerer wishes to refuse an entire m= section, while > accepting the RTP session otherwise, he MAY indicate this by setting > the port number of the relevant section to zero. > > ... and remove that m= line's mid value from the group attribute. > RFC 5888 section 9.2 Good catch. > > section 7 > > In regard to RTCP, it appears that RTCP reports on each SSRC > separately. I would expect that the bandwidth for the RTCP reports on > a stream would be limited to 5% of the bandwidth for that stream. > This keeps the total RTCP bandwidth below 5% of the total stream > bandwidth; indeed it is what you would get if you simply merged the > RTCP streams for the various media streams considered as separate RTP > streams. In this configuration, the RTCP for an audio stream would > never exceed the RTP for the audio stream. Although it does result in > the frequency of reports differing between the various streams. This is incorrect (or I'm serioiusly misunderstanding something). An RTCP sender or receiver report (RFC 3550 section 6.4) is supposed to report on all SSRCs, and the transmission interval is set for the RTP session, not separately for each media stream. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Sat Feb 2 15:13:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7061021F85B8 for ; Sat, 2 Feb 2013 15:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL+T3b7K5MhN for ; Sat, 2 Feb 2013 15:13:14 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D787D21F8455 for ; Sat, 2 Feb 2013 15:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EEB439E151 for ; Sun, 3 Feb 2013 00:13:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-b3zZtJB5Y9 for ; Sun, 3 Feb 2013 00:13:08 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1] (unknown [IPv6:2001:470:de0a:27:700d:b80:cac1:2ae1]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1B8E239E070 for ; Sun, 3 Feb 2013 00:13:08 +0100 (CET) Message-ID: <510D9D82.1030202@alvestrand.no> Date: Sun, 03 Feb 2013 00:13:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <510B09A0.5040904@nostrum.com> In-Reply-To: <510B09A0.5040904@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Multicast and one-m-line-per-stream (Re: Thoughts on m= lines and media streams) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 23:13:14 -0000 Adam, I hate to play the multicast card, because I'm fundamentally uninterested in multicast at the moment, but.... in your scheme 2, how would you represent multicast and transport-mixer based sessions? On 02/01/2013 01:17 AM, Adam Roach wrote: > Based on the conversations we've had so far, I've put together the > following summary of my thoughts on the topic of whether we want to > put multiple media streams in a single m= line. > > http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt > > Sorry for the relatively short lead time before next week's meeting -- > I had meant to put this kind of summary together a week or two ago, > but have been far busier than I anticipated. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From juberti@google.com Sat Feb 2 22:05:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3FF21F84D0 for ; Sat, 2 Feb 2013 22:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcM5h+H4gKh0 for ; Sat, 2 Feb 2013 22:05:08 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53E21F84CC for ; Sat, 2 Feb 2013 22:05:08 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id t2so2319388qcq.0 for ; Sat, 02 Feb 2013 22:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=btkpxglgbs6GQAkduNfLgyLDWhnnL8WJ+9zQws0peBc=; b=SLkV/YrQdecl+Pp00N6AcuqZj/jGdAT0fqe8SbpdKK4Ckfjyk/4ZmkEVuU9KZx49Xb cXe3GTU65X2yS8IB6OX+nEPZeKhBtF9Tt8VyGN+lgyjFRkO9i3tNwjIY4KktXHPXfK7x 7w5cSAFB1KrXbA5GbKxhxa8UZLgSfwDSHzpqdP9cnoy3s4ykhw2AaM1I+oJamKfQdP7a uB+Dc2YtE0c1DoJr9QhR/S4YVtzYhTYpOL/w3ofx1TDlaaljFzc8JCP1HwIs/XblG1rn AdkhpI72QRFGQq8dJakU4Dk/ko2WzlwX1r1YA+ooUY2PDaBidRxy5bgvd1RRV75e1BDb shDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=btkpxglgbs6GQAkduNfLgyLDWhnnL8WJ+9zQws0peBc=; b=pL/wps3uX5Kf8IL3WZgPiBR2kQGqTppf3CxuUyymQCQfY3ztlQ8pq1SrXHJCSjvGUf f4HgvzvjVE1E4S/E3JZWOF5mAfnt4+tQwDXqOmMtHEgZgfyyXZrB0sjE/jCivOVddbEe x1rqvhTN7bu5iGiBnY1foTv/DZm86tgxXRhzYe3zlr7ryttz4lv2wEJ8z3BD7SlH75b6 gr2DZJ0z+DY11TjmT2FDf+dUG8ESzI5ez0dHZ/XbJML8J9BUJ//NxpZbP1jxLrZOQ1uC H1p7mrpkmusGF7bCivi5GvhB/5FenU8DhOEZTBidLM90lF7jXJRAMUQ3dtSJAzi/x1Md gT5A== X-Received: by 10.229.176.216 with SMTP id bf24mr4117412qcb.21.1359871507351; Sat, 02 Feb 2013 22:05:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.180.19 with HTTP; Sat, 2 Feb 2013 22:04:47 -0800 (PST) In-Reply-To: References: <510B09A0.5040904@nostrum.com> From: Justin Uberti Date: Sat, 2 Feb 2013 22:04:47 -0800 Message-ID: To: "Stach, Thomas" , Peter Thatcher Content-Type: multipart/alternative; boundary=0016369f9b5422ca4004d4cbc248 X-Gm-Message-State: ALoCoQlY0QpX2U4WLpSEfwrWC6YLfVPLERA7ra0J0tVllvD6o+z5sYY5BXFrbPi9l7VK5ES3gz9XfXauDBr2JN5zmiQH3TpnrbrIpR9bm6VgDegfa6dVXzEILu8n+FXr8GnUKm/IUenB9FMTM+Y7+Xt4l2HgZtjErPjm1WMGOLBNoz7Y1e6zMtKqBjoYm+otyUBn4kOFcJwJ Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 06:05:09 -0000 --0016369f9b5422ca4004d4cbc248 Content-Type: text/plain; charset=UTF-8 The prior commenters captured some of my concerns already, but here's a quick summary of issues I noticed while reading over this draft: 1) "1a" and "2", as described, have fatal problems if the receiver rejects the m= line that contains all the attributes (e.g. a=ice-ufrag, a=crypto, etc) 2) In "1b", it's not clear what the purpose of the "a=group:MMT foo bar zoe" line is. 3) Proposal "2" does not include the needed a=ssrc lines for demultiplexing the received streams. IOW, proposal 2 requires RFC 5576 just like 1a and 1b. 4) The codec selection argument in Section 2.3.1 feels like a "Red Herring" to me. Practically speaking, I think there are few, if any, real-world settings where one might want to use a codec prioritization mechanism to ask for a low-bitrate codec for stream A and a high-bitrate codec for stream B (where the codecs used are different). A more realistic example would be where one might want a lower bitrate for a specific multi-rate codec (e.g. Opus) to be used for stream A, and higher bitrate for stream B. This of course can be handled with the per-ssrc fmtp attributes that are specified in RFC 5576. However, I think in almost all cases, the receiver is in a much worse position to make these decisions that the sender; the sender, aware of the estimated bandwidth to the receiver, and the relative value/complexity of its streams, can make more informed decisions about bandwidth allocation, and perform them without any signaling delay. 5) The directional attribute discussion in Section 4 omits one important consequence of the fact that a=ssrc indications are unidirectional, namely that streams could be added or removed by both endpoints simultaneously without causing a glare condition. m= lines, on the other hand, since they are identified by their index, do not have this property; if both sides decide to add a m= line at the same time, bad things happen. 6) The legacy interop argument in Section 4 feels a bit hand-wavy. Aside from the one case of having video + presentation streams, I have not yet heard of widely deployed equipment that uses multiple audio or video m= lines, and certainly any such equipment will not understand BUNDLE or MMT. Therefore a gateway is required, and any gateway that was performing BUNDLE or MMT could certainly do the minor additional work to package the SDP as 1 m= line (remember, it already needs to add the a=ssrc attributes). Ergo, I don't agree that the general case of N m= lines needs to be handled by all RTCWEB implementations. In summary, I see option "2" as a "1b" variant that comes with a more verbose and redundant syntax, several shortcomings (#1 and #5 above), and questionable upside. -j- On Thu, Jan 31, 2013 at 11:48 PM, Stach, Thomas < thomas.stach@siemens-enterprise.com> wrote: > > Adam, > > thanks for analysing the various proposals and putting the draft together. > From a quick read I have some issues with backward compatibility of your > proposal to include > "common" attributes only in the first m-section. > Assuming that the examples in the draft are offers, an answerer that > didn't implement any of the mechanisms would probably show the > following behavior. > > Alternativ 1a and 2 have ICE candidates only for the first m-section. > An answerer that doesn't understand the grouping semantics could - > dependent on the network topology - end up having audio, but no video > connectivity. > With having other attributes only in the first m-section we could get > other issues. > > > Alternative 1b doesn't have this problem, but the offer would most likely > be rejected resulting in no media at all. > I preferred the original mmt proposal as it had additional m-sections, > that could be accepted by a legacy answerer without the need for a GW that > performs complex SDP operations. > > > Regards > Thomas > > > Adam Roach wrote: > > Based on the conversations we've had so far, I've put together the > > following summary of my thoughts on the topic of whether we > > want to put > > multiple media streams in a single m= line. > > > > http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt > > > > Sorry for the relatively short lead time before next week's > > meeting -- I > > had meant to put this kind of summary together a week or two ago, but > > have been far busier than I anticipated. > > > > /a > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --0016369f9b5422ca4004d4cbc248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The prior commenters captured some of my concerns already,= but here's a quick summary of issues I noticed while reading over this= draft:

1) "1a" and "2",= as described, have fatal problems if the receiver rejects the m=3D line th= at contains all the attributes (e.g. a=3Dice-ufrag, a=3Dcrypto, etc)

2) In "1b", it's not clear wh= at the purpose of the "a=3Dgroup:MMT foo bar zoe" line is.

3) Proposal "2" does not include the needed a=3Dssrc lines= for demultiplexing the received streams. IOW, proposal 2 requires RFC 5576= just like 1a and 1b.

4) The codec selection argument in Section = 2.3.1 feels like a "Red Herring" to me. Practically speaking, I t= hink there are few, if any, real-world settings where one might want to use= a codec prioritization mechanism to ask for a low-bitrate codec for stream= A and a high-bitrate codec for stream B (where the codecs used are differe= nt). A more realistic example would be where one might want a lower bitrate= =C2=A0for a specific multi-rate codec (e.g. Opus) to be used for stream A,= and higher bitrate for stream B. This of course can be handled with the pe= r-ssrc fmtp attributes that are specified in RFC 5576. However, I think in = almost all cases, the receiver is in a much worse position to make these de= cisions that the sender; the sender, aware of the estimated bandwidth to th= e receiver, and the relative value/complexity of its streams, can make more= informed decisions about bandwidth allocation, and perform them without an= y signaling delay.

5) The directional attribute discussion in = Section 4 omits one important consequence of the fact that a=3Dssrc indicat= ions are unidirectional, namely that streams could be added or removed by b= oth endpoints simultaneously without causing a glare condition. m=3D lines,= on the other hand, since they are identified by their index, do not have t= his property; if both sides decide to add a m=3D line at the same time, bad= things happen.

6) The legacy interop argument in Section 4= feels a bit hand-wavy. Aside from the one case of having video + presentat= ion streams, I have not yet heard of widely deployed equipment that uses mu= ltiple audio or video m=3D lines, and certainly any such equipment will not= understand BUNDLE or MMT. Therefore a gateway is required, and any gateway= that was performing BUNDLE or MMT could certainly do the minor additional = work to package the SDP as 1 m=3D line (remember, it already needs to add t= he a=3Dssrc attributes). Ergo, I don't agree that the general case of N= m=3D lines needs to be handled by all RTCWEB implementations.

In summary, I see option "2" as a= "1b" variant that comes with a more verbose and redundant syntax= , several shortcomings (#1 and #5 above), and questionable upside.

-j-



On Thu, Jan 31, 2013 at 11:48 PM, Stach, Thomas <thomas= .stach@siemens-enterprise.com> wrote:

Adam,

thanks for analysing the various proposals and putting the draft together.<= br> >From a quick read I have some issues with backward compatibility of your pr= oposal to include
"common" attributes only in the first m-section.
Assuming that the examples in the draft are offers, an answerer that
didn't implement any of the mechanisms would probably show the
following behavior.

Alternativ 1a and 2 have ICE candidates only for the first m-section.
An answerer that doesn't understand the grouping semantics could -
dependent on the network topology - end up having audio, but no video
connectivity.
With having other attributes only in the first m-section we could get other= issues.


Alternative 1b doesn't have this problem, but the offer would most like= ly
be rejected resulting in no media at all.
I preferred the original mmt proposal as it had additional m-sections,
that could be accepted by a legacy answerer without the need for a GW that = performs complex SDP operations.


Regards
Thomas


Adam Roach wrote:
> Based on the conversations we've had so far, I've put together= the
> following summary of my thoughts on the topic of whether we
> want to put
> multiple media streams in a single m=3D line.
>
> http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt=
>
> Sorry for the relatively short lead time before next week's
> meeting -- I
> had meant to put this kind of summary together a week or two ago, but<= br> > have been far busier than I anticipated.
>
> /a
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--0016369f9b5422ca4004d4cbc248-- From juberti@google.com Sun Feb 3 23:46:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE0121F84DA for ; Sun, 3 Feb 2013 23:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do7T2-PCoryQ for ; Sun, 3 Feb 2013 23:46:06 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id CA8C721F8472 for ; Sun, 3 Feb 2013 23:46:05 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so1143777qah.14 for ; Sun, 03 Feb 2013 23:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=+PbAaTrYWm2Zdc0wWYKm8FrFmccKHOyW1y2kJmjLCK8=; b=LIyA0n2ZTbeJW1O6MUO1RQbaxkWG9Y13OpaoGnKzgXs0bynssP7a7LtuI95bm+uF55 TvqI3AbOS3skvgBAlziTqKXsc4iXfJ/Wjl+93TUwuEpTkuM5niL0nn+Z4bSAPACJkPzz z7OoyVyr/LcAvspRX1ZFwmgdcvPS4sJ88qHeBOyKRzTfNHYVxIMDW5y9IkHM97JTSWsO yu211SCd9dSDviEzlvwAN/G34R+HekdVt23w8P41VkP+i8/exC5N16Zk+VALQLg5mTth bphhwS6mdT27mChS07Bpbxlu0YuAVDOwYP+u5/O9wJkyk4ctcDBOoBaqyIaeXuTITkFM QiaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=+PbAaTrYWm2Zdc0wWYKm8FrFmccKHOyW1y2kJmjLCK8=; b=kuPI4T3ucQPUpPUGFk7sWbiEXRzBvUZG5AbdPr4q6jpG/u6FuAuCZ0nZokkT5Stx5Z ZKFaiGGhdd7fbIC3wmHqqxDoKHE/lIF7pnP5EuyIlKxrcTWVIDFk6OOSykuA0ym6v2XN w1wyCo1MzZNKQUnywgGbhVBMjJmTyatDZgzY5V4XFiL+RMNXnc/lBX2IbHPzU4LjSI89 SGRNRTzApwgQBJokWrU69vCmeyfJBiDAvlFSoXl1qd5zjXXYkf2aq/6az+erunmMGVKh kNjNoa0wlIjkTgpvrjXVmJC5eyoq3EzmUr3Bp9fu88JXVLBnR1mhWgQzLqFtoPrxNbyp JvaA== X-Received: by 10.49.96.33 with SMTP id dp1mr21018628qeb.60.1359963965208; Sun, 03 Feb 2013 23:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.180.19 with HTTP; Sun, 3 Feb 2013 23:45:44 -0800 (PST) From: Justin Uberti Date: Sun, 3 Feb 2013 23:45:44 -0800 Message-ID: To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6da40c0db7a204d4e14973 X-Gm-Message-State: ALoCoQnG/Rqsuh0dRp/mh+pBeEDkoUuhOfswXHLONETu7PltEJw4YbR//S+3D0NFalmYt2dynWbEL1FcNL7xArGW2WB83z6VfZtyXa+QzdJGyj5F5Ano3DU+GBYJvQVVBWHxxTVGNMseAXIbJmeVHubyExm1Mzcy0PfVKCNv8H+hECB3g/emXlvvdmUj//KhhADpi2NxHLGu Subject: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 07:46:06 -0000 --047d7b6da40c0db7a204d4e14973 Content-Type: text/plain; charset=UTF-8 Sorry for the short lead time, but here's a quick read for the plane. Peter Thatcher and I have put together a writeup of our thoughts on the advantages of putting multiple media streams in a single m= line. http://www.ietf.org/id/draft-pthatcher-mmusic-many-sources-00.txt We look forward to discussing in more detail at the interim. --047d7b6da40c0db7a204d4e14973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the short lead time, but here's a quick read= for the plane.

Peter Thatcher and I have put together a= writeup of our thoughts on the advantages of putting multiple media stream= s in a single m=3D line.


We look forward to dis= cussing in more detail at the interim.
--047d7b6da40c0db7a204d4e14973-- From ron.even.tlv@gmail.com Mon Feb 4 06:39:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB69D21F872C for ; Mon, 4 Feb 2013 06:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=1.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAZ+ejRtxLnz for ; Mon, 4 Feb 2013 06:39:05 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC021F8722 for ; Mon, 4 Feb 2013 06:39:04 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3443525eei.21 for ; Mon, 04 Feb 2013 06:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=l2z36vywUizzD8rMZEm6JGUMPzF0aye6aqZsZgKj88A=; b=I1aI44GutPGf7qQxwMLNM2TK1zeatRkc3CzjSM9dmn0Q5LTQ9ymN2UlRp+/FlepXE9 5imvaJRFfCWScfFNqhqVlZCVjO8KNOVFbJ6KiCBmMDV3ZzZkBCVSiIzHfmJqSmpZBexH QneDcRG6FKHTjpv3+5yyHqLUX9ISWsG+pDdx1QkT2trZhJiIUxeXJ4vgzsUzBQDnE31z VEHAHgXiQBEVjYTpYNGMXOTe1BgeGfvWvlXml5SdOOn4qfQc19B0rUjpWISvFUtvZY9r h0H9fUlhD+mFwsE92dYvfPndnKLvgm3UlonEpKpMj7qtjBdDvAprvZRLTbQn/bY8lWN1 0YZg== X-Received: by 10.14.225.72 with SMTP id y48mr72129253eep.46.1359988743662; Mon, 04 Feb 2013 06:39:03 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id h5sm27577213eem.1.2013.02.04.06.39.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 06:39:02 -0800 (PST) From: "Roni Even" To: Date: Mon, 4 Feb 2013 16:36:10 +0200 Message-ID: <039f01ce02e4$fbb7d150$f32773f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4C5PQd/UXdaGeDTJ+geVATctO66w== Content-Language: en-us Subject: [MMUSIC] Some more about SDP support for multiple streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 14:39:06 -0000 Hi, Sorry for the last minute but here are more thoughts on the subject. I will not be able to attend the interim meeting and am not sure if can join this topic since it may be too late at night for me. Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, February 04, 2013 4:30 PM To: Roni Even Cc: jonathan@vidyo.com; bill.wu@huawei.com Subject: New Version Notification for draft-even-mmusic-multiple-streams-00.txt A new version of I-D, draft-even-mmusic-multiple-streams-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-multiple-streams Revision: 00 Title: Describing multiple RTP media streams in SDP Creation date: 2013-02-04 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-multiple-streams-00.tx t Status: http://datatracker.ietf.org/doc/draft-even-mmusic-multiple-streams Htmlized: http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-00 Abstract: This document describes issues when describing multiple RTP streams in a single RTP session using SDP. The document looks at current solutions and provides directions to address the issues. The IETF Secretariat= From pkyzivat@alum.mit.edu Mon Feb 4 07:18:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53921F88AC for ; Mon, 4 Feb 2013 07:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HkI-VnBr1yq for ; Mon, 4 Feb 2013 07:18:21 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6942321F8432 for ; Mon, 4 Feb 2013 07:18:21 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id wBPW1k0061GhbT853FJLNM; Mon, 04 Feb 2013 15:18:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:c889:2409:dacd:ae16]) by omta07.westchester.pa.mail.comcast.net with comcast id wFJJ1k00E0tAQKE3TFJJ3f; Mon, 04 Feb 2013 15:18:20 +0000 Message-ID: <510FD138.7050005@alum.mit.edu> Date: Mon, 04 Feb 2013 10:18:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359991100; bh=2+R7aUqI4i0lQt1izhyx9S8cRg0W25tQgJhsPJJ6P7U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GDA6pfFQNVO6mA4RuL8McrijTLnHVoPH65EQpo12wrs1o3ojI3dM/KUwejWA1HzZG RnDecP+HsraJwSBx/owxFujaXmxCe31CPUq/WZQNdS1XCw/H9Ryjb6l3r2awrn2ajf fsP6i0Nk04o5DjhWKgqxpbuvrgmIRFtgJ6CAYIJgCouOsJwSLukiKXOiKgam7pYopZ I/E4s0NlLFJvoo7xFpQ1tNGq2txGSMkmpWug7cjMWBFZ8yCjtKsp5irs3QgRvFV3Yy TCb9l5gG0beAbbrEepL0X9RhVdp+xJh3SLmyDQZUTkMUkc8CfkbGbK/Har+pq0Q+Rx sr8KUee1KyTog== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:18:22 -0000 Is there a detailed agenda, with actual start times? I've looked but can't find one. Thanks, Paul On 1/18/13 2:33 PM, Hadriel Kaplan wrote: > Howdy, > We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at our Corporate Galactic Headquarters in Bedford, Massachusetts. > > Please register at the following page if you plan to attend: > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c > > The logistics/venue info page is here: > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics > > You should NOT register if you're only going to attend remotely. Details for remote participation will be sent out later on the relevant mailing lists. > > We hope to see you here! > And bring warm clothing - it's slightly chilly. ;) > > -hadriel > > p.s. We've tested the registration page on several browsers and it works generally, except for on Lynx, Links, or Elinks. (Lynx and Links because they don't support Javascript, but why it doesn't work on Elinks w/SpiderMonkey I haven't looked into) The logistics page seems to work on all browsers. > :) > > > From ron.even.tlv@gmail.com Mon Feb 4 08:56:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11FC21F88A6; Mon, 4 Feb 2013 08:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvX4CSAfI6EN; Mon, 4 Feb 2013 08:56:32 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A221F8648; Mon, 4 Feb 2013 08:56:31 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so3041034eaa.32 for ; Mon, 04 Feb 2013 08:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=hKkfxuYKcIOM9LH5T9rZ6R9IelUd1J9CRrFd1aBUsHY=; b=uFeza5dmSNYuT2kHGr0PvcypBjPgoQ8QOGgIBbwlkBUJyFYxZ53jZWg87Fathr+2jj hYVqFZdU0J/qGdFj7IAIVptvNVeZzM1/o+P+ULvF6xMdTUsd/FJgbcYuPHDU7m7Bqn2J 58n7nbSSSDPoMFlOUYvNUMO9Q71ixw+NZ44fz6O7/i9Rrf3ibivcrzvJGVK0GmTOA+cd +qrAFNAsJY5A1PaI45XVvB+W15pLNjijyCh5fOhEp88wR87r0E2M8a/dFuN8NmTTJ3fr 2RiweE4Q0rjdstdcVoX8ayFjLfkQyvsY/0DcTThCGGHzD1lQrzxMKP5ilro7b8qYUrTc JITQ== X-Received: by 10.14.215.131 with SMTP id e3mr9666855eep.32.1359996991002; Mon, 04 Feb 2013 08:56:31 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t4sm28167973eel.0.2013.02.04.08.56.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 08:56:29 -0800 (PST) From: "Roni Even" To: , References: <5108ED00.9090605@ericsson.com> In-Reply-To: <5108ED00.9090605@ericsson.com> Date: Mon, 4 Feb 2013 18:53:36 +0200 Message-ID: <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQKyoQBbe7ZUzYPbSQyQEvL2IxXs9pagrVNw Content-Language: en-us Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:56:33 -0000 Hi, Is there a final agenda with time schedule. There is no relation between the agenda here and i=the one for mmusic and rtcweb in the reference. I would like to attend from remote and since there is time difference it will be helpful to plan ahead. Thanks Roni Even who will try to attend from remote being 7 hours ahead of Boston -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan H?kansson LK Sent: 30 January, 2013 11:51 AM To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org; public-media-capture@w3.org Subject: [rtcweb] Boston meeting agenda All, below is a merged agenda covering both W3C and IETF parts of the meeting. Details are likely to change - the main message is that W3C meetings will be before lunch, and IETF after. Before lunch could mean 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard stop is planned for 17:00 on Feb 7th as many have planes to catch. (The sources used to assemble the agenda below are the W3C meeting wiki's, [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). --Stefan (for all involved chairs) Feb 5th ======= Morning session: W3C Media Capture TF ------------------------------------- * device enumeration * error handling * "immediate stream" gUM * Resource reservation Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Multiple Flow SDP representation * SDP for Data channels Feb 6th ======= Morning session: W3C Media Capture TF + WebRTC WG ------------------------------------------------- * Identity aspects of MediaStreams (MediaCap) * Settings/constraints (MediaCap) * Recording (MediaCap) * Call flow (WebRTC) Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * SDP Grouping (Bundle/MMT/one-rtp) * Mapping stream/track label concepts to SDP identifiers Feb 7th ======= Morning session: W3C WebRTC WG ------------------------------ * MediaStream and MediaStreamTrack - SDP interface * Error handling * Data channel * Stats Afternoon session: IETF mmusic and rtcweb WGs --------------------------------------------- * Trickle ICE * JSEP [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From btv1==7476154b17d==HKaplan@acmepacket.com Mon Feb 4 10:25:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C95C21F8A5F for ; Mon, 4 Feb 2013 10:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKokBDZNATNE for ; Mon, 4 Feb 2013 10:25:33 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 657FB21F8833 for ; Mon, 4 Feb 2013 10:25:33 -0800 (PST) X-ASG-Debug-ID: 1360002326-03fc207afd19e290001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id 4ekYM4DyNmVRHO9F (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 04 Feb 2013 13:25:26 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Mon, 4 Feb 2013 13:25:26 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: February Interim registration and logistics X-ASG-Orig-Subj: Re: February Interim registration and logistics Thread-Index: AQHOAwUAJlsqwRqOpESjXFiKxPyc6Q== Date: Mon, 4 Feb 2013 18:25:26 +0000 Message-ID: <5FC802B8-DE25-4B3C-87D7-3382B1FCD1D6@acmepacket.com> References: <510FD138.7050005@alum.mit.edu> In-Reply-To: <510FD138.7050005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1E4E760217CE284C998EB10E063089A0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1360002326 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.121804 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:26:46 -0000 Hi Paul, An email confirmation and with some logistics info was just sent out. The breakfast starts at 8am each day, with the meeting starting at 8:30-ish= . But I'm not the one handling detailed meeting agenda with presentations and= stuff - I assumed that was up to the Chairs. The last one I saw was this one: http://www.ietf.org/mail-archive/web/mmusic/current/msg10168.html -hadriel On Feb 4, 2013, at 10:18 AM, Paul Kyzivat wrote: > Is there a detailed agenda, with actual start times? > I've looked but can't find one. >=20 > Thanks, > Paul >=20 > On 1/18/13 2:33 PM, Hadriel Kaplan wrote: >> Howdy, >> We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF= MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at= our Corporate Galactic Headquarters in Bedford, Massachusetts. >>=20 >> Please register at the following page if you plan to attend: >> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c >>=20 >> The logistics/venue info page is here: >> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics >>=20 >> You should NOT register if you're only going to attend remotely. Detail= s for remote participation will be sent out later on the relevant mailing l= ists. >>=20 >> We hope to see you here! >> And bring warm clothing - it's slightly chilly. ;) >>=20 >> -hadriel >>=20 >> p.s. We've tested the registration page on several browsers and it works= generally, except for on Lynx, Links, or Elinks. (Lynx and Links because t= hey don't support Javascript, but why it doesn't work on Elinks w/SpiderMon= key I haven't looked into) The logistics page seems to work on all browser= s. >> :) >>=20 >>=20 >>=20 >=20 From roni.even@mail01.huawei.com Mon Feb 4 06:34:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B503721F86C8 for ; Mon, 4 Feb 2013 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtFp-mzXn46C for ; Mon, 4 Feb 2013 06:34:30 -0800 (PST) Received: from hwsga01-in.huaweimarine.com (unknown [119.145.15.223]) by ietfa.amsl.com (Postfix) with ESMTP id 134F021F8639 for ; Mon, 4 Feb 2013 06:34:29 -0800 (PST) Received: from 172.24.2.15 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.2.15]) by szxrg11-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id ADH21490; Mon, 04 Feb 2013 22:34:25 +0800 (CST) Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Feb 2013 22:34:19 +0800 Received: from SZXPML504-MBX.exmail.huawei.com ([169.254.3.128]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Mon, 4 Feb 2013 22:34:22 +0800 From: Roni Even To: "mmusic@ietf.org" Thread-Topic: Some more about SDP support for multiple streams Thread-Index: AQHOAuS4JTNGZUN1QkOqimA9NpZubg== Date: Mon, 4 Feb 2013 14:34:22 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B7E2B1@szxpml504-mbx.exmail.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Feb 2013 12:52:31 -0800 Subject: [MMUSIC] Some more about SDP support for multiple streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 14:34:31 -0000 Hi, Sorry for the last minute but here are more thoughts on the subject. I will not be able to attend the interim meeting and am not sure if can joi= n this topic since it may be too late at night for me. Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, February 04, 2013 4:30 PM To: Roni Even Cc: jonathan@vidyo.com; bill.wu@huawei.com Subject: New Version Notification for draft-even-mmusic-multiple-streams-00= .txt A new version of I-D, draft-even-mmusic-multiple-streams-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-multiple-streams Revision: 00 Title: Describing multiple RTP media streams in SDP Creation date: 2013-02-04 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-mult= iple-streams-00.txt Status: http://datatracker.ietf.org/doc/draft-even-mmusic-multiple= -streams Htmlized: http://tools.ietf.org/html/draft-even-mmusic-multiple-stre= ams-00 Abstract: This document describes issues when describing multiple RTP streams in a single RTP session using SDP. The document looks at current solutions and provides directions to address the issues. The IETF Secretariat= From vvucetic@cisco.com Mon Feb 4 07:34:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7521F8694; Mon, 4 Feb 2013 07:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkmV0PDlxaLD; Mon, 4 Feb 2013 07:34:13 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD821F86D3; Mon, 4 Feb 2013 07:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1731; q=dns/txt; s=iport; t=1359992050; x=1361201650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iLXdfWR6UHnBUePl/y6MFDWTM44pAe4MaseVrW4hL68=; b=AGzvUBNDvRIrQym7VR0GRkiJeyVKJgUlWDgYfbKE/ZbToC314oUroYVd TQ5i0/azYEATP4Hb5FKY+PcLSdGMR6IyMZNd+6w01QdKXHvAgodc+Ax8N i4MkrSujH0B/jvVkDem5lqicFizbdFvfkBLpytOn3a90itsMLz0MumsOH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACnUD1GtJV2a/2dsb2JhbABFDr8sFnOCHwEBAQQBAQE3NAsMBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIgJDLtZjSqDR2EDlzyPNII+PoFvNQ X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; d="scan'208";a="172764601" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 04 Feb 2013 15:34:10 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r14FY9si018980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 15:34:09 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.138]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 09:34:09 -0600 From: "Vojislav Vucetic (vvucetic)" To: Paul Kyzivat , Hadriel Kaplan Thread-Topic: [rtcweb] February Interim registration and logistics Thread-Index: AQHOAurjXno7/EtQakuKaNa0T35yUphp1CDQ Date: Mon, 4 Feb 2013 15:34:09 +0000 Message-ID: <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com> References: <510FD138.7050005@alum.mit.edu> In-Reply-To: <510FD138.7050005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.76.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Feb 2013 12:52:30 -0800 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:34:13 -0000 What about the remote access to the sessions? Thank you, vvv -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, February 04, 2013 10:18 AM To: Hadriel Kaplan Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail) Subject: Re: [rtcweb] February Interim registration and logistics Is there a detailed agenda, with actual start times? I've looked but can't find one. Thanks, Paul On 1/18/13 2:33 PM, Hadriel Kaplan wrote: > Howdy, > We're pleased to host the upcoming interim meetings of IETF RTCWeb, IETF = MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, at = our Corporate Galactic Headquarters in Bedford, Massachusetts. > > Please register at the following page if you plan to attend: > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c > > The logistics/venue info page is here: > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics > > You should NOT register if you're only going to attend remotely. Details= for remote participation will be sent out later on the relevant mailing li= sts. > > We hope to see you here! > And bring warm clothing - it's slightly chilly. ;) > > -hadriel > > p.s. We've tested the registration page on several browsers and it works = generally, except for on Lynx, Links, or Elinks. (Lynx and Links because th= ey don't support Javascript, but why it doesn't work on Elinks w/SpiderMonk= ey I haven't looked into) The logistics page seems to work on all browsers= . > :) > > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From spromano@unina.it Mon Feb 4 10:40:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34621F8A8E; Mon, 4 Feb 2013 10:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHb4P+sb63Mq; Mon, 4 Feb 2013 10:40:12 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53021F8A66; Mon, 4 Feb 2013 10:40:12 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r14IduXM012752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2013 19:39:56 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33" From: Simon Pietro Romano In-Reply-To: <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com> Date: Mon, 4 Feb 2013 19:39:56 +0100 Message-Id: <767E45D1-8A23-4236-AD56-D907187F4F6F@unina.it> References: <510FD138.7050005@alum.mit.edu> <23E4AF2696DFB44BBAE64F13EF9B3779153400E3@xmb-aln-x11.cisco.com> To: Vojislav Vucetic (vvucetic) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 04 Feb 2013 12:52:31 -0800 Cc: rtcweb@ietf.org, "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:40:13 -0000 --Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 for info about remote participation. Thanks, Simon Il giorno 04/feb/2013, alle ore 16:34, Vojislav Vucetic (vvucetic) ha = scritto: > What about the remote access to the sessions? >=20 > Thank you, >=20 > vvv >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Paul Kyzivat > Sent: Monday, February 04, 2013 10:18 AM > To: Hadriel Kaplan > Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail) > Subject: Re: [rtcweb] February Interim registration and logistics >=20 > Is there a detailed agenda, with actual start times? > I've looked but can't find one. >=20 > Thanks, > Paul >=20 > On 1/18/13 2:33 PM, Hadriel Kaplan wrote: >> Howdy, >> We're pleased to host the upcoming interim meetings of IETF RTCWeb, = IETF MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, = 2013, at our Corporate Galactic Headquarters in Bedford, Massachusetts. >>=20 >> Please register at the following page if you plan to attend: >> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c >>=20 >> The logistics/venue info page is here: >> http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics >>=20 >> You should NOT register if you're only going to attend remotely. = Details for remote participation will be sent out later on the relevant = mailing lists. >>=20 >> We hope to see you here! >> And bring warm clothing - it's slightly chilly. ;) >>=20 >> -hadriel >>=20 >> p.s. We've tested the registration page on several browsers and it = works generally, except for on Lynx, Links, or Elinks. (Lynx and Links = because they don't support Javascript, but why it doesn't work on Elinks = w/SpiderMonkey I haven't looked into) The logistics page seems to work = on all browsers. >> :) >>=20 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 +1 = for info about remote = participation.

Thanks,

Simon

Il giorno 04/feb/2013, alle ore 16:34, Vojislav = Vucetic (vvucetic) ha scritto:

What = about the remote access to the sessions?

Thank = you,

vvv

-----Original Message-----
From: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: = Monday, February 04, 2013 10:18 AM
To: Hadriel Kaplan
Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)
Subject: = Re: [rtcweb] February Interim registration and logistics

Is there = a detailed agenda, with actual start times?
I've looked but can't = find one.

= Thanks,
Paul

On 1/18/13 2:33 PM, = Hadriel Kaplan wrote:
Howdy,
We're = pleased to host the upcoming interim meetings of IETF RTCWeb, IETF = MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, = at our Corporate Galactic Headquarters in Bedford, = Massachusetts.

Please register = at the following page if you plan to attend:
http:= //info.acmepacket.com/acme-packet-hosting-ietf-and-w3c

The = logistics/venue info page is here:
http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics=

You should NOT = register if you're only going to attend remotely.  Details for = remote participation will be sent out later on the relevant mailing = lists.

We hope to see = you here!
And bring warm = clothing - it's slightly chilly. ;)

-hadriel

p.s. We've = tested the registration page on several browsers and it works generally, = except for on Lynx, Links, or Elinks. (Lynx and Links because they don't = support Javascript, but why it doesn't work on Elinks w/SpiderMonkey I = haven't looked into)  The logistics page seems to work on all = browsers.
:)




_______________________________________= ________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb
_____________________________________________= __
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_4BAF32B8-13CD-4832-8889-B9E53A744B33-- From worley@shell01.TheWorld.com Mon Feb 4 12:54:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB4321F8B3B for ; Mon, 4 Feb 2013 12:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm8UM0IJxqQI for ; Mon, 4 Feb 2013 12:54:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8655321F8B0C for ; Mon, 4 Feb 2013 12:54:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r14Krt5i010159 for ; Mon, 4 Feb 2013 15:53:57 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r14Krtab1204008 for ; Mon, 4 Feb 2013 15:53:55 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r14KrtwJ1202181; Mon, 4 Feb 2013 15:53:55 -0500 (EST) Date: Mon, 4 Feb 2013 15:53:55 -0500 (EST) Message-Id: <201302042053.r14KrtwJ1202181@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:54:03 -0000 A couple of nits about draft-ietf-mmusic-sctp-sdp-00: section 7 Examples contain "*" in m= lines instead of payload types. The resader will probably assume that "*" stands for a sequence of payload types, but it's best to have examples be valid. Replacing all the "*"s with "0 8" would suffice to make the examples valid: m=image 54111 SCTP 0 8 c=IN IP4 192.0.2.2 a=setup:actpass a=connection:new section 7.2 The text suggests that the intention is to reuse the existing SCTP connection, but the SDP offer and answer both contain "a=connection:new". Shouldn't these use "a=connection:existing"? Compare with RFC 4145 section 7.3. Dale From btv1==7476154b17d==HKaplan@acmepacket.com Mon Feb 4 13:11:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0814421F8A25 for ; Mon, 4 Feb 2013 13:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifWgZa3q3SEv for ; Mon, 4 Feb 2013 13:11:28 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 338A621F8935 for ; Mon, 4 Feb 2013 13:11:28 -0800 (PST) X-ASG-Debug-ID: 1360012285-03fc207afd1ae330001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id q78lgcKI0DDrxMRP (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 04 Feb 2013 16:11:25 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Mon, 4 Feb 2013 16:11:25 -0500 From: Hadriel Kaplan To: "Vojislav Vucetic (vvucetic)" Thread-Topic: [MMUSIC] [rtcweb] February Interim registration and logistics X-ASG-Orig-Subj: Re: [MMUSIC] [rtcweb] February Interim registration and logistics Thread-Index: AQHOAxwwYQi1WyU/Z0me6zlI3nt9Sw== Date: Mon, 4 Feb 2013 21:11:24 +0000 Message-ID: <7EDA53E2-625C-47E3-BFFE-77A450939B1C@acmepacket.com> References: <510FD138.7050005@alum.mit.edu> <1.657355dcbec592b63032@cisco.com> In-Reply-To: <1.657355dcbec592b63032@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <561FE227C9612D4F8E0A58ACA6CE1C7F@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1360012285 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.121816 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "fluffy@cisco.com \(fluffy\)" , "rtcweb@ietf.org" , "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] February Interim registration and logistics X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:11:29 -0000 It's a WebEx session, graciously offered/hosted by Cisco. I haven't seen w= hat the URL/dial-in info is for it yet. -hadriel On Feb 4, 2013, at 10:34 AM, Vojislav Vucetic (vvucetic) wrote: > What about the remote access to the sessions?=20 >=20 > Thank you,=20 >=20 > vvv=20 >=20 > -----Original Message-----=20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Paul Kyzivat=20 > Sent: Monday, February 04, 2013 10:18 AM=20 > To: Hadriel Kaplan=20 > Cc: rtcweb@ietf.org; mmusic@ietf.org (E-mail)=20 > Subject: Re: [rtcweb] February Interim registration and logistics=20 >=20 > Is there a detailed agenda, with actual start times?=20 > I've looked but can't find one.=20 >=20 > Thanks,=20 > Paul=20 >=20 > On 1/18/13 2:33 PM, Hadriel Kaplan wrote:=20 > > Howdy,=20 > > We're pleased to host the upcoming interim meetings of IETF RTCWeb, IET= F MMUSIC, W3C WebRTC and W3C Media Capture groups, on February 5-7, 2013, a= t our Corporate Galactic Headquarters in Bedford, Massachusetts.=20 > >=20 > > Please register at the following page if you plan to attend:=20 > > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c=20 > >=20 > > The logistics/venue info page is here:=20 > > http://info.acmepacket.com/acme-packet-hosting-ietf-and-w3c/logistics=20 > >=20 > > You should NOT register if you're only going to attend remotely. Detail= s for remote participation will be sent out later on the relevant mailing l= ists.=20 > >=20 > > We hope to see you here!=20 > > And bring warm clothing - it's slightly chilly. ;)=20 > >=20 > > -hadriel=20 > >=20 > > p.s. We've tested the registration page on several browsers and it work= s generally, except for on Lynx, Links, or Elinks. (Lynx and Links because = they don't support Javascript, but why it doesn't work on Elinks w/SpiderMo= nkey I haven't looked into) The logistics page seems to work on all browser= s.=20 > > :)=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________=20 > rtcweb mailing list=20 > rtcweb@ietf.org=20 > https://www.ietf.org/mailman/listinfo/rtcweb=20 > _______________________________________________=20 > mmusic mailing list=20 > mmusic@ietf.org=20 > https://www.ietf.org/mailman/listinfo/mmusic=20 From eckelcu@cisco.com Mon Feb 4 18:28:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065D21F8727; Mon, 4 Feb 2013 18:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+YMgPGomnb4; Mon, 4 Feb 2013 18:28:09 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B721F890D; Mon, 4 Feb 2013 18:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2275; q=dns/txt; s=iport; t=1360031289; x=1361240889; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iWpRYVqGPk+ouYle0tdGJo3gMkNVesZznllK1Od3tyg=; b=IWH0oXuzwZ2CxpDAyb55HucQ71KEQS3evQr+Zkk5TYj4usqTOxGcdrhO J3EEg/kxkBJORGYEXRrxrjMVvXAuMe+FV8Ots0gRgT+wYky6T1Nm47Mve aKGq54Wdf+8PlkPH71DVxbmLMBpApZWT271hZQ0Cp3UVzVHZ8aiiZUbnI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD5sEFGtJXG//2dsb2JhbABFv0QWc4IfAQEBBAxmEwICAgEIEQQBAQsdBxsXFAkIAgQBEgiICatvkA0EjSaDR2EDiDCeQIJvDYFvNQ X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173276458" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2013 02:28:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r152S9Rn021311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 02:28:09 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 20:28:08 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , "mmusic (E-mail)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Draft on Multimedia concepts and relations for Intermim Thread-Index: AQHN/6A+vrlehv19GUGvsxwr0HOEbJhqHUDA Date: Tue, 5 Feb 2013 02:28:08 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com> References: <510A4B7C.3000009@ericsson.com> In-Reply-To: <510A4B7C.3000009@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.254] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] [rtcweb] Draft on Multimedia concepts and relations for Intermim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 02:28:10 -0000 Hi Magnus and Bo, Thanks for putting this together, and more importantly, for attaching a cop= y in the e-mail so I was able to access it on the plane without internet. I agree with most of the reasoning in the various sections; however, there = are a couple related concepts for which I'd like more clarification. 1) MediaStream Is a MediaStream restricted to a single source? I did not think it was, but= the description on page 8 seems to imply this restriction. For example, co= uld I have a single MediaStream with the following 4 MediaStreamTracks, whe= re source 1 and source 2 are two video cameras from the same endpoint, or a= mic and an camera from the same endpoint: Source 1 - encoding 1 Source 1 - encoding 2 Source 2 - encoding 1 Source 2 - encoding 2 2) PeerConnection Later, on page 18, a related restriction of a single encoding per PC is sug= gested. In the case of a layered encoding, this seems to imply each layer b= eing in its own PC. Is that the recommendation being suggested? Thanks, Charles=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Thursday, January 31, 2013 2:46 AM > To: mmusic (E-mail); rtcweb@ietf.org > Subject: [rtcweb] Draft on Multimedia concepts and relations for Intermim >=20 > Hi, >=20 > Attached is a draft on multimedia concepts and relations that we believe > relevant for the upcoming interim. This includes commonalties between > WebRTC and CLUE and other RTP usages. >=20 > Sorry for the late submission, i do hope you have time to review it. At > will also be properly submitted to IETF as soon as we figure out why the > submission tools refuses to process it. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From worley@shell01.TheWorld.com Mon Feb 4 19:28:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A7B21F8953 for ; Mon, 4 Feb 2013 19:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7QjU0nxDFn5 for ; Mon, 4 Feb 2013 19:28:05 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1E32C21F8512 for ; Mon, 4 Feb 2013 19:28:05 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r153R7Qv011292 for ; Mon, 4 Feb 2013 22:27:10 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r153R6wF1193506 for ; Mon, 4 Feb 2013 22:27:06 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r153R6Yw1217343; Mon, 4 Feb 2013 22:27:06 -0500 (EST) Date: Mon, 4 Feb 2013 22:27:06 -0500 (EST) Message-Id: <201302050327.r153R6Yw1217343@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <510D5D3C.1060103@alvestrand.no> (harald@alvestrand.no) References: <201302012336.r11NaMnt1017265@shell01.TheWorld.com> <510D5D3C.1060103@alvestrand.no> Subject: Re: [MMUSIC] Comments on draft-alvestrand-one-rtp-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:28:06 -0000 > From: Harald Alvestrand > > > I think the concept is that the various media streams are > > demultiplexed out of the common RTP scheme by the fact that each > > payload type (codec type number) appears in at most one m= line of the > > bundle. But that isn't stated explicitly anywhere. In any case, the > > method for demultiplexing the RTP should be stated explicitly. > > This is incorrect. Media streams are demultiplexed by SSRC. This is more complex than it first appears, including ambiguity in the term "media stream". I'm considering the problem of attributing each incoming RTP packet to a particular m= line in the SDP. But that is based on an assumption that identifying the correct m= line is important to the application layer above. More about that later... > > In regard to RTCP, it appears that RTCP reports on each SSRC > > separately. I would expect that the bandwidth for the RTCP reports on > > a stream would be limited to 5% of the bandwidth for that stream. > > This keeps the total RTCP bandwidth below 5% of the total stream > > bandwidth; indeed it is what you would get if you simply merged the > > RTCP streams for the various media streams considered as separate RTP > > streams. In this configuration, the RTCP for an audio stream would > > never exceed the RTP for the audio stream. Although it does result in > > the frequency of reports differing between the various streams. > > This is incorrect (or I'm serioiusly misunderstanding something). An > RTCP sender or receiver report (RFC 3550 section 6.4) is supposed to > report on all SSRCs, and the transmission interval is set for the RTP > session, not separately for each media stream. Your understanding is much more likely to be correct than mine, and RFC 3550 section 6.4 supports your statement. But as somebody noted, if there is both an audio and video stream, RTCP reports should be sent sufficiently frequently for the video stream that the information contained in them for the audio stream approaches the bandwidth of the audio stream itself. We may not need to care, given the RTCP is still a small fraction of the overall bandwidth demand, but it may desirable to modify the rules in section 6.4 to allow less frequent reports for sources that are producing packets less frequently. Dale From fluffy@cisco.com Mon Feb 4 19:35:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FA021F8A47; Mon, 4 Feb 2013 19:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.182 X-Spam-Level: X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM8p0S7px4P4; Mon, 4 Feb 2013 19:35:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0621F852B; Mon, 4 Feb 2013 19:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8134; q=dns/txt; s=iport; t=1360035355; x=1361244955; h=from:to:subject:date:message-id:references:mime-version; bh=xUXU2EkJ+L6aE+lXsscvaeeZ16Zs8Uzwhh5Tym+IZRs=; b=L8r1HFsQiTDdaoPSqfy6gzBc6FcTJR5IBWSAY0eJJcPF1n8LiOgG6wjN IPy+miZV/UzkIH1OMityR4hMBtTMIs64EeyppP+KIvbLUHMrIEiuuNtfS m5/hn31yI5xYQapnM8IOJxwFCQBGEholohHdhW+KVlKPAbiASH6q5zBqa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAId8EFGtJV2c/2dsb2JhbAArFwO/UBZzgiABAQRmAiECARwOCgQMAwcyFBABAgEDARIIiAkMLKtGgU+OP40aG28HgkZhA5c8jzSCLEMNgW81 X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208,217";a="173275162" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2013 03:35:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r153ZsZU030549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 03:35:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 21:35:54 -0600 From: "Cullen Jennings (fluffy)" To: "" , "public-webrtc@w3.org" , mmusic WG Thread-Topic: Webex for WebRTC / RTCWeb / MMusic interim meeting Thread-Index: AQHOA1Hnb0mXRjeshEmbqUcNz+ZEDw== Date: Tue, 5 Feb 2013 03:35:05 +0000 Message-ID: References: <287030554.79219.1360034826664.JavaMail.nobody@jsj6tc002.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.1.35] Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [MMUSIC] Webex for WebRTC / RTCWeb / MMusic interim meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:35:56 -0000 --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the dial in information for the interim meeting for WebRTC, RTCWeb,= and MMUSIC over the next few day. It is the same conference for all the me= etings on all days to avoid the need to switch back and forth. I find the easiest way to use this is join the web page, but then have it d= ial you back to phone a PSTN phone line. Please mute yourself when not speaking. (Note the bridge is starting up at 8:00 but the meeting does not start unti= l 8:30 ) Hello , Cullen Jennings invites you to attend this online meeting. Topic: WebRTC / RTCWeb / MMusic Date: Every 1 day, from Tuesday, February 5, 2013 to Thursday, February 7, = 2013 Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 200 160 998 Meeting Password: acme ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW= =3DNN2I3YzUxYjJk&RT=3DMiMxMQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: acme 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=3DNN2I3Y= zUxYjJk&ORT=3DMiMxMQ%3D%3D ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: fluffy@cisco.com To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkgeSvE1NzcP1FAQFi0Kzp6vvYe1NCey7X109lhs/gVs&= RT=3DMiMxMQ%3D%3D --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2B4D0BA1CF5D5C4D8114892C36FE77EA@cisco.com> Content-Transfer-Encoding: quoted-printable

Here is the dial in information for the interim meeting for WebRTC, RT= CWeb, and MMUSIC over the next few day. It is the same conference for all t= he meetings on all days to avoid the need to switch back and forth. 

I find the easiest way to use this is join the web page, but then have= it dial you back to phone a PSTN phone line. 

Please mute yourself when not speaking. 

(Note the bridge is starting up at 8:00 but the meeting does not start= until 8:30 )




Hello ,

Cullen Jennings invites you to attend this online meeting.

Topic: WebRTC / RTCWeb / MMusic
Date: Every 1 day, from Tuesday, February 5, 2013 to Thursday, February 7, = 2013
Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)
Meeting Number: 200 160 998
Meeting Password: acme


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW= =3DNN2I3YzUxYjJk&RT=3DMiMxMQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: acme
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https= ://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&PW=3DNN2= I3YzUxYjJk&ORT=3DMiMxMQ%3D%3D

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
fluffy@cisco.com


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D216374677&UID=3D0&I= CS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkgeSvE1NzcP1FAQFi0= Kzp6vvYe1NCey7X109lhs/gVs&RT=3DMiMxMQ%3D%3D

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133ABA13xmbalnx02ciscoc_-- From worley@shell01.TheWorld.com Mon Feb 4 19:28:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FC421F8953 for ; Mon, 4 Feb 2013 19:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKxTfVzE9RsI for ; Mon, 4 Feb 2013 19:28:04 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 78F1321F8512 for ; Mon, 4 Feb 2013 19:28:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r153RqcP013660 for ; Mon, 4 Feb 2013 22:27:54 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r153RqVq1217673 for ; Mon, 4 Feb 2013 22:27:52 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r153RqDq1172136; Mon, 4 Feb 2013 22:27:52 -0500 (EST) Date: Mon, 4 Feb 2013 22:27:52 -0500 (EST) Message-Id: <201302050327.r153RqDq1172136@shell01.TheWorld.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: mmusic@ietf.org X-Mailman-Approved-At: Mon, 04 Feb 2013 20:04:42 -0800 Subject: [MMUSIC] A conceptual model of SDP bundling and related desiderata X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:28:04 -0000 Here is the next edition of my thoughts about SDP bundling. (See y'all tomorrow!) * Terminology The important RFCs in this area use inconsistent terminology. Here, we use: - "transport association" and "5-tuple" A 5-tuple is the description of a particular transport association, such as a TCP connection. The components of the 5-tuple are the identity of the protocol being used and the addresses and transport ports of the two endpoints. - "media" We use this term for (1) media content, considered in an abstract way, that is, without consideration of its particular encoding or the framing information around it, and (2) the particular bits and bytes used to encode and transmit the abstract media content. - "multimedia session" We use this term for the totality of the media that is transmitted/received as described by a particular session description (i.e., SDP instance). This is taken from RFC 4566 section 2. - "RTP session" We use this term for the totality of the media that is transmitted/received as described by a particular media description (i.e., m= line) in a particular session description. Since each media description specifies one 5-tuple, RTP sessions correspond to transport associations. This is taken from RFC 3550 section 2.2. (In SIP usage (RFC 3264), this is called a "media stream", which term is used in RTP usage to refer to the RTP with a single SSRC.) It is understood that the RTP session can be dissected into "media streams" that have separate SSRCs, but that is not relevant in this analysis. E.g., in SIP telephony, various activities of the far endpoint can cause the ultimate source of the audio (and hence the SSRC) to change dynamically without warning, but each new source stands in for the previous one seamlessly in the user interface. (However, there is a way (RFC 4566 section 5.14) for an m= line to specify a set of ports and thus a set of related RTP sessions. We do not address that.) In general, further agreed terminology is needed to describe the aggregate of media possessing a particular SSRC, etc., but that is not needed for this discussion. * Conceptual structure The central idea of bundling is to multiplex the media that would be several RTP sessions into one RTP session, with particular emphasis on allowing one transport association to carry media that are presented to the higher, application layer, as multiple RTP sessions. At the interface between the SDP-configured layer and the lower, transport layer, we want the media organized into a single RTP session. The transport-related properties of the RTP session (e.g., transport 5-tuple, encryption, ICE) will be described by the transport-related attributes of a single media description. At the interface between the SDP-configured layer and the higher, application layer, we want to have the media organized into several RTP sessions. The application-related properties of the RTP session (e.g., media type and label) will be described by the application-related attributes of separate media descriptions. (There are some attributes (e.g., bandwidth limitation) that can apply separately to both the bundled RTP session and the constituent RTP sessions.) However, we do not include the payload type numbers as information available to the application; only the codec identity and its parameters are accessible to the application. This gives the bundling mechanism freedom to place constraints on the use of payload types. The application may distinguish between the media of each constituent RTP session in ways that are not determinable from the properties of the media themselves. (E.g., in telepresence systems or in systems where multiple video feeds are to be assembled into one large image, multiple video streams have non-trivial relationships that are specified by additional application-level SDP attributes. Or there may be several RTP sessions whose media types are the same but whose logical roles in the multimedia session are not interchangeable.) The application considers all media within a particular RTP session to be a single logical media stream, regardless of changes in codec (payload type) and SSRC (which often happen because the ultimate source of the media changes). E.g., a SIP telephone sends/receives SDP with one audio media description, and all RTP sent/received within that RTP session is connected to/from the telephone's user interface, despite that far-end call transfer events or audio conference processing may cause the payload type and SSRC of received RTP to change without warning. * Desiderata for a bundling mechanism (I use the term "desiderata" -- "things that are desired" -- rather than "requirements", because we may discover that we can't optimally satisfy all of these criteria.) DES 1: For each bundle, there is a group of media descriptions which describe the application-level RTP sessions. DES 2: For each bundle, there is a media description that describes the transport-level RTP session. These requirements do not specify whether the transport-level media description may or may not also be one of the application-level media descriptions. DES 3: Bundles may contain other bundles as constituents. Of course, no bundle may directly or indirectly contain itself. I don't expect any current implementation to implement bundles within bundles, but we should design the mechanism to allow this, as some day we will likely need it. DES 4: A bundle may contain zero constituents. A bundle with no constituents serves no purpose for the transport of media, but we are likely to someday need to describe such a bundle. (Compare that an SDP m= line is syntactically constrained to specify at least one payload type. When SDP was used only to specify multicast sessions, this constraint was common sense. But once SDP offer/answer was invented, when a media description was rejected, the natural construction would be an m= line with a zero port and no payload types. But a payload type was syntactically required, so we now have to provide at least one useless payload type for rejected m= lines.) DES 5: If an answerer that does not understand the bundle mechanism processes an offer that contains a bundle, it must interpret it as the collection of application-level media descriptions, and the offerer must be able to properly interpret the answer that it produces. DES 6: If an answerer that does understand the bundle mechanism processes an offer that contains a bundle, it must be able to (1) accept the bundle and selectively accept/reject each constituent RTP session within it, (2) reject the bundle as a whole, or (3) reject the bundling and selectively accept/reject each constituent RTP session as separate RTP sessions. Presumably answer (3) is like that which would be produced by an answerer that does not understand the bundling mechanism. DES 7: There must be a reliable way to demultiplex incoming RTP into the separate application-level RTP sessions. Similarly, there must be a reliable way to demultiplex the associated RTCP information. I know little about RTCP, but I believe that the RTCP information is tagged with the SSRC about which it reports, and the SSRC is used to correlate the RTCP reports with the RTP sessions containing media with the same SSRC. If so, RTCP demultiplexing requires no additional specification, as RTCP is understood in the same way as in non-bundled RTP. DES 8: The specification must specify any needed additional procedures for handling SSRC collisions between media sources within different application-level RTP sessions, as those can now collide. Dale From ron.even.tlv@gmail.com Mon Feb 4 23:25:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D454621F8A47; Mon, 4 Feb 2013 23:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=1.388, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV2+IxIFuNKK; Mon, 4 Feb 2013 23:25:49 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B921F8A2F; Mon, 4 Feb 2013 23:25:42 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so3149350eaa.4 for ; Mon, 04 Feb 2013 23:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=PJyHoTPt9Qnd/rlPNikQJ9QDLnuYAn4Ze9QzTkHrHsM=; b=iqcvIiiaNgeRqYD0KkTMQ1TXd0+n9/m4lD47c0PkakbGueYOk9P49Xas0f0RLA2rWZ sC9q+qft6MnzXVOA3QqXdppYcfMwm/bYbUX6rGN3OeJg6gbdCdNyzFScOTUTV1c8MT2Y NXvRW3/TkTxWUd4CUMEH7CQb2NSucMo2aJcV00nx5cpkFJanfFGcV+9KiY889982LvSL Gx26/5YKTbPTbAzrTETLCypOgn9g+uuyaRxqeYXGWF+up4zUggSzlwQnu8bqLTzkvxzw xGnB8+NxWxWtxBQsbhYpsnkvUNFFjQLiMXR+LbIagbD+zpOmbtX0HuDYQ8yrWn/0Qlal I8KA== X-Received: by 10.14.201.69 with SMTP id a45mr81012990eeo.43.1360049141987; Mon, 04 Feb 2013 23:25:41 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id o3sm30872559eem.15.2013.02.04.23.25.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 23:25:41 -0800 (PST) From: "Roni Even" To: Date: Tue, 5 Feb 2013 09:22:49 +0200 Message-ID: <03e701ce0371$9c8913a0$d59b3ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4DcYPYcPBQbgqnQMeh68L0xqSLFA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: [MMUSIC] New Version Notification for draft-even-mmusic-multiple-streams-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 07:25:49 -0000 Hi, Resubmitted with small editorial changes and some clarifying text Roni ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Tuesday, February 05, 2013 9:22 AM To: Roni Even Cc: jonathan@vidyo.com; bill.wu@huawei.com Subject: New Version Notification for draft-even-mmusic-multiple-streams-01.txt A new version of I-D, draft-even-mmusic-multiple-streams-01.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-multiple-streams Revision: 01 Title: Describing multiple RTP media streams in SDP Creation date: 2013-02-05 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-multiple-streams-01.tx t Status: http://datatracker.ietf.org/doc/draft-even-mmusic-multiple-streams Htmlized: http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-even-mmusic-multiple-streams-01 Abstract: This document describes issues when describing multiple RTP streams in a single RTP session using SDP. The document looks at current solutions and provides paths toward addressing the issues. The IETF Secretariat= From martin.thomson@gmail.com Tue Feb 5 04:29:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D68321F879A for ; Tue, 5 Feb 2013 04:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=-3.233, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rci5k9rGPCc5 for ; Tue, 5 Feb 2013 04:29:16 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E721F8797 for ; Tue, 5 Feb 2013 04:29:15 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so4093730wid.5 for ; Tue, 05 Feb 2013 04:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lagp33qdj6v60iaRPerXZhOCwN6ExFcMg3EMIvCjeR0=; b=XfVY3ny/CrhecLdl6IaY/pl6pBM2rpxGOv9XaaiYPhv4Ltp/DUJwhsbzjcyprlesmY dgZ4cHzNlaLsqgP07bCXL9oURBYlY4jMXRR8PNBsQHdX2zBrlH/+9p7dYneQWcuD3bYu hOA5jzwT6dRlm5GRs7N7fxRKMKCLmD2p4zmNr6PhSkBw3wsxJy3rpDzgGV9uC6ZYcNxC 89xtKIOSYxcqq6XfRSlpRaBYYIxf2Q3GOqiY5aRN4s8dZXs/ptEsDaU7i70b3Fgwi5nV u9YnWId0O3lDIsmUsN/v6WKjbP0iPr0dh0fxf8iN/sk6avhbfXvnzwYS9PrKWrGz5fNe Zpaw== MIME-Version: 1.0 X-Received: by 10.194.123.105 with SMTP id lz9mr42091450wjb.43.1360067354926; Tue, 05 Feb 2013 04:29:14 -0800 (PST) Received: by 10.194.5.135 with HTTP; Tue, 5 Feb 2013 04:29:14 -0800 (PST) In-Reply-To: <201302042053.r14KrtwJ1202181@shell01.TheWorld.com> References: <201302042053.r14KrtwJ1202181@shell01.TheWorld.com> Date: Tue, 5 Feb 2013 07:29:14 -0500 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 12:29:16 -0000 The * is valid. The part of the m= line that you know to contain payload types is defined as being specific to the type. Thus, m=rabbit 4995 BUNNIES * is valid SDP, assuming of course that someone has defined a top-level MIME type of 'rabbit' and so forth. On 04/02/2013, Dale R. Worley wrote: > A couple of nits about draft-ietf-mmusic-sctp-sdp-00: > > section 7 > > Examples contain "*" in m= lines instead of payload types. The > resader will probably assume that "*" stands for a sequence of payload > types, but it's best to have examples be valid. Replacing all the > "*"s with "0 8" would suffice to make the examples valid: > > m=image 54111 SCTP 0 8 > c=IN IP4 192.0.2.2 > a=setup:actpass > a=connection:new > > section 7.2 > > The text suggests that the intention is to reuse the existing SCTP > connection, but the SDP offer and answer both contain > "a=connection:new". Shouldn't these use "a=connection:existing"? > Compare with RFC 4145 section 7.3. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From adam@nostrum.com Tue Feb 5 06:33:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720DE21F8803 for ; Tue, 5 Feb 2013 06:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2rEA4pA608L for ; Tue, 5 Feb 2013 06:33:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1221F87D3 for ; Tue, 5 Feb 2013 06:33:02 -0800 (PST) Received: from Orochi.local (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r15EWvWx019722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 08:32:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <51111814.7010006@nostrum.com> Date: Tue, 05 Feb 2013 09:32:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Justin Uberti References: <510B09A0.5040904@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090208040409090104000804" Received-SPF: pass (shaman.nostrum.com: 155.212.214.60 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:33:41 -0000 This is a multi-part message in MIME format. --------------090208040409090104000804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/3/13 01:04, Justin Uberti wrote: > 1) "1a" and "2", as described, have fatal problems if the receiver > rejects the m= line that contains all the attributes (e.g. > a=ice-ufrag, a=crypto, etc) Yeah, this part of the solution was put together kind of off-the-cuff. I'd considered three approaches, and this one was the least verbose. My second choice, which has better backwards compatibility properties anyway, is mandating that the transport-level attributes are in all the m= sections to which they apply. You end up with redundant information, but it does get around issues with rejecting some sections. > 2) In "1b", it's not clear what the purpose of the "a=group:MMT foo > bar zoe" line is. Unfortunately, I really didn't have the time I wanted to put this draft together, and there's more than a little carelessness in the SDP examples. That shouldn't be there. > 3) Proposal "2" does not include the needed a=ssrc lines for > demultiplexing the received streams. IOW, proposal 2 requires RFC 5576 > just like 1a and 1b. And this is the sloppiness I referred to above. The different sections should have non-overlapping RTP payload types. > 4) The codec selection argument in Section 2.3.1 feels like a "Red > Herring" to me. Practically speaking, I think there are few, if any, > real-world settings where one might want to use a codec prioritization > mechanism to ask for a low-bitrate codec for stream A and a > high-bitrate codec for stream B (where the codecs used are different). > A more realistic example would be where one might want a lower bitrate > for a specific multi-rate codec (e.g. Opus) to be used for stream A, > and higher bitrate for stream B. This of course can be handled with > the per-ssrc fmtp attributes that are specified in RFC 5576. However, > I think in almost all cases, the receiver is in a much worse position > to make these decisions that the sender; the sender, aware of the > estimated bandwidth to the receiver, and the relative value/complexity > of its streams, can make more informed decisions about bandwidth > allocation, and perform them without any signaling delay. You're asserting that the person sending the media (to whom the quality has little or no impact) is a better party to select the quality of a stream than the person receiving it? I have nothing to say to that. It's sufficiently false on its face that I really have nowhere to start grappling with it. > 5) The directional attribute discussion in Section 4 omits one > important consequence of the fact that a=ssrc indications are > unidirectional, namely that streams could be added or removed by both > endpoints simultaneously without causing a glare condition. m= lines, > on the other hand, since they are identified by their index, do not > have this property; if both sides decide to add a m= line at the same > time, bad things happen. None of the three approaches avoids the necessity to handle glare. With a stateful offer/answer approach, there's simply no way around it. We would have to go back to the drawing board if we wanted to come up with a system that avoided glare (and even then, I don't think success is very likely). > 6) The legacy interop argument in Section 4 feels a bit hand-wavy. > Aside from the one case of having video + presentation streams, I have > not yet heard of widely deployed equipment that uses multiple audio or > video m= lines, and certainly any such equipment will not understand > BUNDLE or MMT. Therefore a gateway is required, and any gateway that > was performing BUNDLE or MMT could certainly do the minor additional > work to package the SDP as 1 m= line (remember, it already needs to > add the a=ssrc attributes). Ergo, I don't agree that the general case > of N m= lines needs to be handled by all RTCWEB implementations. Truth be told, even though I called this "legacy interop," it's more accurate to think of it as "interop with non-RTCWEB implementations that use SDP," of which legacy is an important subset. In any case, if we're jumping to needing a gateway to do substantial SDP rewrites, then I question the use of SDP at all in RTCWEB. The selection of SDP, to my understanding, was to provide simpler interop with non-RTCWEB implementations. Once we assume that you're necessarily rewriting it for such interop to work, we may as well abandon it altogether. /a --------------090208040409090104000804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2/3/13 01:04, Justin Uberti wrote:
1) "1a" and "2", as described, have fatal problems if the receiver rejects the m= line that contains all the attributes (e.g. a=ice-ufrag, a=crypto, etc)

Yeah, this part of the solution was put together kind of off-the-cuff. I'd considered three approaches, and this one was the least verbose. My second choice, which has better backwards compatibility properties anyway, is mandating that the transport-level attributes are in all the m= sections to which they apply. You end up with redundant information, but it does get around issues with rejecting some sections.

2) In "1b", it's not clear what the purpose of the "a=group:MMT foo bar zoe" line is.

Unfortunately, I really didn't have the time I wanted to put this draft together, and there's more than a little carelessness in the SDP examples. That shouldn't be there.

3) Proposal "2" does not include the needed a=ssrc lines for demultiplexing the received streams. IOW, proposal 2 requires RFC 5576 just like 1a and 1b.

And this is the sloppiness I referred to above. The different sections should have non-overlapping RTP payload types.

4) The codec selection argument in Section 2.3.1 feels like a "Red Herring" to me. Practically speaking, I think there are few, if any, real-world settings where one might want to use a codec prioritization mechanism to ask for a low-bitrate codec for stream A and a high-bitrate codec for stream B (where the codecs used are different). A more realistic example would be where one might want a lower bitrate  for a specific multi-rate codec (e.g. Opus) to be used for stream A, and higher bitrate for stream B. This of course can be handled with the per-ssrc fmtp attributes that are specified in RFC 5576. However, I think in almost all cases, the receiver is in a much worse position to make these decisions that the sender; the sender, aware of the estimated bandwidth to the receiver, and the relative value/complexity of its streams, can make more informed decisions about bandwidth allocation, and perform them without any signaling delay.

You're asserting that the person sending the media (to whom the quality has little or no impact) is a better party to select the quality of a stream than the person receiving it?

I have nothing to say to that. It's sufficiently false on its face that I really have nowhere to start grappling with it.

5) The directional attribute discussion in Section 4 omits one important consequence of the fact that a=ssrc indications are unidirectional, namely that streams could be added or removed by both endpoints simultaneously without causing a glare condition. m= lines, on the other hand, since they are identified by their index, do not have this property; if both sides decide to add a m= line at the same time, bad things happen.

None of the three approaches avoids the necessity to handle glare. With a stateful offer/answer approach, there's simply no way around it. We would have to go back to the drawing board if we wanted to come up with a system that avoided glare (and even then, I don't think success is very likely).

6) The legacy interop argument in Section 4 feels a bit hand-wavy. Aside from the one case of having video + presentation streams, I have not yet heard of widely deployed equipment that uses multiple audio or video m= lines, and certainly any such equipment will not understand BUNDLE or MMT. Therefore a gateway is required, and any gateway that was performing BUNDLE or MMT could certainly do the minor additional work to package the SDP as 1 m= line (remember, it already needs to add the a=ssrc attributes). Ergo, I don't agree that the general case of N m= lines needs to be handled by all RTCWEB implementations.

Truth be told, even though I called this "legacy interop," it's more accurate to think of it as "interop with non-RTCWEB implementations that use SDP," of which legacy is an important subset.

In any case, if we're jumping to needing a gateway to do substantial SDP rewrites, then I question the use of SDP at all in RTCWEB. The selection of SDP, to my understanding, was to provide simpler interop with non-RTCWEB implementations. Once we assume that you're necessarily rewriting it for such interop to work, we may as well abandon it altogether.

/a
--------------090208040409090104000804-- From adam@nostrum.com Tue Feb 5 07:26:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D4221F8552 for ; Tue, 5 Feb 2013 07:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHoCU8szfov8 for ; Tue, 5 Feb 2013 07:26:00 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 04BC521F8550 for ; Tue, 5 Feb 2013 07:25:58 -0800 (PST) Received: from Orochi.local (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r15FPrDt025652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 09:25:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <5111247B.8060904@nostrum.com> Date: Tue, 05 Feb 2013 10:25:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Justin Uberti References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030801030007050804020702" Received-SPF: pass (shaman.nostrum.com: 155.212.214.60 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:26:01 -0000 This is a multi-part message in MIME format. --------------030801030007050804020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/4/13 02:45, Justin Uberti wrote: > Sorry for the short lead time, but here's a quick read for the plane. I addressed several of the assertions made in this draft in my previous response (e.g. the need for glare resolution regardless of which solution we select). Some additional thoughts: > o Adding or removing a source requires sending a full list of all > sources, which doesn't scale well to 10s or 100s of sources, > especially when they are added or removed frequently. Realistically, this isn't how multiparty conferences are handled. It's unrealistic to think that my DSL connection is going to be sucking down hundreds of video streams just because I'm in a video conference with hundreds of people. In practice, the way existing conferencing systems handle this is to send a small, manageable number of streams to each participant, changing them out as necessary to have a reasonable user experience (either under the control of the user, its own algorithms, or a combination of the two). Which is to say: even with hundreds of source streams being fed into a conference system, you're really looking at a realistic upper bound on m= sections of a dozen or two, simply because you can't reasonably expect recipients to receive more than that many streams simultaneously. And really, if you're imagining hundreds of media streams flowing towards an endpoint, any arguments about the bits consumed by SDP go well beyond disingenuous. > o Because this solution requires BUNDLE, which is still not widely > supported, it can be deployed in fewer situations This is completely out of left field: the alternative is MMT, which is even less well developed than BUNDLE. > 4. The RFC5576-based approach has already been in use for many years > in a major video conferencing system (Google+ Hangouts), and has > worked very well. We feel that we have searched the "unknown" > space and solved all of the major issues. I think this actually does a good job of illustrating your blind spot: you're working within RTCWEB, but developing for a single, very precise use case. For example, this kind of experience doesn't translate well into the challenges that might arise from systems that are dealing with radically different user experiences. Google-hangout-type uses are certainly important, but they're not the only thing we're designing for. You need to think about systems with pre-encoded (stored) media; systems with radical imbalances in the processing power and device capabilities between the endpoints; systems with different stream control models, etc, etc. > On the other hand, the multi m= > section approach has never been tried by anyone, that we are > aware of Do a web search for "Marconi ViPr." /a --------------030801030007050804020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/4/13 02:45, Justin Uberti wrote:
Sorry for the short lead time, but here's a quick read for the plane.

I addressed several of the assertions made in this draft in my previous response (e.g. the need for glare resolution regardless of which solution we select). Some additional thoughts:

   o  Adding or removing a source requires sending a full list of all
      sources, which doesn't scale well to 10s or 100s of sources,
      especially when they are added or removed frequently.

Realistically, this isn't how multiparty conferences are handled. It's unrealistic to think that my DSL connection is going to be sucking down hundreds of video streams just because I'm in a video conference with hundreds of people.

In practice, the way existing conferencing systems handle this is to send a small, manageable number of streams to each participant, changing them out as necessary to have a reasonable user experience (either under the control of the user, its own algorithms, or a combination of the two).

Which is to say: even with hundreds of source streams being fed into a conference system, you're really looking at a realistic upper bound on m= sections of a dozen or two, simply because you can't reasonably expect recipients to receive more than that many streams simultaneously.

And really, if you're imagining hundreds of media streams flowing towards an endpoint, any arguments about the bits consumed by SDP go well beyond disingenuous.

   o  Because this solution requires BUNDLE, which is still not widely
      supported, it can be deployed in fewer situations

This is completely out of left field: the alternative is MMT, which is even less well developed than BUNDLE.

   4.  The RFC5576-based approach has already been in use for many years
       in a major video conferencing system (Google+ Hangouts), and has
       worked very well.  We feel that we have searched the "unknown"
       space and solved all of the major issues.

I think this actually does a good job of illustrating your blind spot: you're working within RTCWEB, but developing for a single, very precise use case. For example, this kind of experience doesn't translate well into the challenges that might arise from systems that are dealing with radically different user experiences. Google-hangout-type uses are certainly important, but they're not the only thing we're designing for. You need to think about systems with pre-encoded (stored) media; systems with radical imbalances in the processing power and device capabilities between the endpoints; systems with different stream control models, etc, etc.

       On the other hand, the multi m=
       section approach has never been tried by anyone, that we are
       aware of

Do a web search for "Marconi ViPr."

/a
--------------030801030007050804020702-- From adam@nostrum.com Tue Feb 5 07:52:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2F21F84C8 for ; Tue, 5 Feb 2013 07:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-e1kd7au4WJ for ; Tue, 5 Feb 2013 07:52:34 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5713521F84B9 for ; Tue, 5 Feb 2013 07:52:33 -0800 (PST) Received: from Orochi.local (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r15FqFuX028490 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 09:52:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <51112AA9.4070309@nostrum.com> Date: Tue, 05 Feb 2013 10:52:09 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <510B09A0.5040904@nostrum.com> <510D9D82.1030202@alvestrand.no> In-Reply-To: <510D9D82.1030202@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 155.212.214.60 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Multicast and one-m-line-per-stream (Re: Thoughts on m= lines and media streams) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:52:35 -0000 Before I respond, I do want to make sure that this is the same Harald Alvestrand who was proposing that we dismiss the vast majority of existing SDP attributes on the premise that they are of no interest to WEBRTC. /a On 2/2/13 18:13, Harald Alvestrand wrote: > Adam, > > I hate to play the multicast card, because I'm fundamentally > uninterested in multicast at the moment, but.... > > in your scheme 2, how would you represent multicast and > transport-mixer based sessions? > > > On 02/01/2013 01:17 AM, Adam Roach wrote: >> Based on the conversations we've had so far, I've put together the >> following summary of my thoughts on the topic of whether we want to >> put multiple media streams in a single m= line. >> >> http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt >> >> Sorry for the relatively short lead time before next week's meeting >> -- I had meant to put this kind of summary together a week or two >> ago, but have been far busier than I anticipated. >> >> /a >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Tue Feb 5 08:00:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0421F87A6 for ; Tue, 5 Feb 2013 08:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcM5XhWuuUEr for ; Tue, 5 Feb 2013 08:00:58 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 44BE321F8778 for ; Tue, 5 Feb 2013 08:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7740; q=dns/txt; s=iport; t=1360080058; x=1361289658; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kGtkBDq8vGrfzqmFdtmBIoJbBB8PQ4W+HDhN3m+2+Qc=; b=Ho6G4beL3neTzV0dDfGrtOs2mTN+I9RohuluQHoftjeWsmHVlFkovV+X inpz6UoCmPBKcTIjBOl0XfjT8Meeurxfxt8TaRIRFC8/bFdy6J9Oc5CEt lI1kcqGfEAlRMM9mQ/uRuLFlFbbeBq/s3wbUsDJKr2UQtqCLDXlWuIc/p c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABIsEVGtJXG//2dsb2JhbABFhki4IncWc4IfAQEBAwEjEUUMBAIBCBEEAQEBAgIGHQMCAgIwFAEICAIEAQ0FCBOHcAaoBYJAkC2BI4tvgzYyYQOmc4J+giQ X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173618312" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 05 Feb 2013 16:00:51 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r15G0oLF003569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 16:00:50 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 10:00:50 -0600 From: "Charles Eckel (eckelcu)" To: Adam Roach , Justin Uberti Thread-Topic: [MMUSIC] Thoughts on m= lines and media streams Thread-Index: AQHOABGcqHdo41Qt7E+/OUBDRVXw6ZhlBXCAgAMHvoCAA7KfAP//sUGQ Date: Tue, 5 Feb 2013 16:00:50 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280477E934@xmb-aln-x08.cisco.com> References: <510B09A0.5040904@nostrum.com> <51111814.7010006@nostrum.com> In-Reply-To: <51111814.7010006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:00:59 -0000 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4gQmVoYWxmIE9mIEFkYW0gUm9hY2gNCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkg MDUsIDIwMTMgOTozMyBBTQ0KPiBUbzogSnVzdGluIFViZXJ0aQ0KPiBDYzogbW11c2ljQGlldGYu b3JnOyBQZXRlciBUaGF0Y2hlcg0KPiBTdWJqZWN0OiBSZTogW01NVVNJQ10gVGhvdWdodHMgb24g bT0gbGluZXMgYW5kIG1lZGlhIHN0cmVhbXMNCj4gDQo+IE9uIDIvMy8xMyAwMTowNCwgSnVzdGlu IFViZXJ0aSB3cm90ZToNCj4gDQo+IA0KPiAJMSkgIjFhIiBhbmQgIjIiLCBhcyBkZXNjcmliZWQs IGhhdmUgZmF0YWwgcHJvYmxlbXMgaWYgdGhlIHJlY2VpdmVyDQo+IHJlamVjdHMgdGhlIG09IGxp bmUgdGhhdCBjb250YWlucyBhbGwgdGhlIGF0dHJpYnV0ZXMgKGUuZy4gYT1pY2UtdWZyYWcsDQo+ IGE9Y3J5cHRvLCBldGMpDQo+IA0KPiANCj4gWWVhaCwgdGhpcyBwYXJ0IG9mIHRoZSBzb2x1dGlv biB3YXMgcHV0IHRvZ2V0aGVyIGtpbmQgb2Ygb2ZmLXRoZS1jdWZmLiBJJ2QNCj4gY29uc2lkZXJl ZCB0aHJlZSBhcHByb2FjaGVzLCBhbmQgdGhpcyBvbmUgd2FzIHRoZSBsZWFzdCB2ZXJib3NlLiBN eQ0KPiBzZWNvbmQgY2hvaWNlLCB3aGljaCBoYXMgYmV0dGVyIGJhY2t3YXJkcyBjb21wYXRpYmls aXR5IHByb3BlcnRpZXMNCj4gYW55d2F5LCBpcyBtYW5kYXRpbmcgdGhhdCB0aGUgdHJhbnNwb3J0 LWxldmVsIGF0dHJpYnV0ZXMgYXJlIGluIGFsbCB0aGUgbT0NCj4gc2VjdGlvbnMgdG8gd2hpY2gg dGhleSBhcHBseS4gWW91IGVuZCB1cCB3aXRoIHJlZHVuZGFudCBpbmZvcm1hdGlvbiwgYnV0IGl0 DQo+IGRvZXMgZ2V0IGFyb3VuZCBpc3N1ZXMgd2l0aCByZWplY3Rpbmcgc29tZSBzZWN0aW9ucy4N Cg0KV2h5IG5vdCBzcGVjaWZ5IHN1Y2ggIHRyYW5zcG9ydCBhdHRyaWJ1dGVzIGF0IHRoZSBzZXNz aW9uIGxldmVsLiBGb3IgdGhvc2UgYXR0cmlidXRlcyB0aGF0IGFyZSBjdXJyZW50bHkgbWVkaWEg bGV2ZWwgb25seSwgZXh0ZW5kIHRoZW0gdG8gZGVmaW5lIGhvdyB0aGV5IHdvcmsgYXQgdGhlIHNl c3Npb24gbGV2ZWwuDQoNCkZvciBleGFtcGxlLCBiPSBhdCB0aGUgc2Vzc2lvbiBsZXZlbCBpcyBh bHJlYWR5IGRlZmluZWQgdG8gYmUgdGhlIG1heGltdW0gYmFuZHdpZHRoIGFjcm9zcyB0aGUgZW50 aXJlIHNlc3Npb24gd2hlcmVhcyBiPSBhdCB0aGUgbT1zZWN0aW9uIGxldmVsIGlzIGZvciB0aGF0 IG09c2VjdGlvbiBvbmx5Lg0KRm9yIG1lZGlhIGRpcmVjdGlvbi9tb2RlLCBhPXNlbmRvbmx5L3Nl bmRyZWN2L2luYWN0aXZlL3JlY3Zvbmx5IGNhbiBiZSBzcGVjaWZpZWQgYXQgdGhlIHNlc3Npb24g bGV2ZWwsIGluIHdoaWNoIGNhc2UgaXQgYXBwbGllcyB0byBhbGwgbT1zZWN0aW9ucyB1bmxlc3Mg dGhleSBzcGVjaWZ5IHRoZWlyIG93biB2YWx1ZS4NClNpbWlsYXJseSwgSUNFIGNhbmRpZGF0ZXMg Y291bGQgYmUgc3BlY2lmaWVkIGF0IHRoZSBzZXNzaW9uIGxldmVsIGFuZCBoYXZlIHRob3NlIGFw cGx5IGF0IGFsbCBtZWRpYSBsZXZlbHMsIHVubGVzcyB0aGUgbWVkaWEgbGV2ZWwgc3BlY2lmaWVz IGl0cyBvd24gdmFsdWUuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KPiANCj4gDQo+IAkyKSBJbiAi MWIiLCBpdCdzIG5vdCBjbGVhciB3aGF0IHRoZSBwdXJwb3NlIG9mIHRoZSAiYT1ncm91cDpNTVQg Zm9vDQo+IGJhciB6b2UiIGxpbmUgaXMuDQo+IA0KPiANCj4gDQo+IFVuZm9ydHVuYXRlbHksIEkg cmVhbGx5IGRpZG4ndCBoYXZlIHRoZSB0aW1lIEkgd2FudGVkIHRvIHB1dCB0aGlzIGRyYWZ0DQo+ IHRvZ2V0aGVyLCBhbmQgdGhlcmUncyBtb3JlIHRoYW4gYSBsaXR0bGUgY2FyZWxlc3NuZXNzIGlu IHRoZSBTRFAgZXhhbXBsZXMuDQo+IFRoYXQgc2hvdWxkbid0IGJlIHRoZXJlLg0KPiANCj4gDQo+ IA0KPiAJMykgUHJvcG9zYWwgIjIiIGRvZXMgbm90IGluY2x1ZGUgdGhlIG5lZWRlZCBhPXNzcmMg bGluZXMgZm9yDQo+IGRlbXVsdGlwbGV4aW5nIHRoZSByZWNlaXZlZCBzdHJlYW1zLiBJT1csIHBy b3Bvc2FsIDIgcmVxdWlyZXMgUkZDIDU1NzYNCj4ganVzdCBsaWtlIDFhIGFuZCAxYi4NCj4gDQo+ IA0KPiBBbmQgdGhpcyBpcyB0aGUgc2xvcHBpbmVzcyBJIHJlZmVycmVkIHRvIGFib3ZlLiBUaGUg ZGlmZmVyZW50IHNlY3Rpb25zIHNob3VsZA0KPiBoYXZlIG5vbi1vdmVybGFwcGluZyBSVFAgcGF5 bG9hZCB0eXBlcy4NCj4gDQo+IA0KPiANCj4gCTQpIFRoZSBjb2RlYyBzZWxlY3Rpb24gYXJndW1l bnQgaW4gU2VjdGlvbiAyLjMuMSBmZWVscyBsaWtlIGEgIlJlZA0KPiBIZXJyaW5nIiB0byBtZS4g UHJhY3RpY2FsbHkgc3BlYWtpbmcsIEkgdGhpbmsgdGhlcmUgYXJlIGZldywgaWYgYW55LCByZWFs LXdvcmxkDQo+IHNldHRpbmdzIHdoZXJlIG9uZSBtaWdodCB3YW50IHRvIHVzZSBhIGNvZGVjIHBy aW9yaXRpemF0aW9uIG1lY2hhbmlzbSB0bw0KPiBhc2sgZm9yIGEgbG93LWJpdHJhdGUgY29kZWMg Zm9yIHN0cmVhbSBBIGFuZCBhIGhpZ2gtYml0cmF0ZSBjb2RlYyBmb3Igc3RyZWFtDQo+IEIgKHdo ZXJlIHRoZSBjb2RlY3MgdXNlZCBhcmUgZGlmZmVyZW50KS4gQSBtb3JlIHJlYWxpc3RpYyBleGFt cGxlIHdvdWxkIGJlDQo+IHdoZXJlIG9uZSBtaWdodCB3YW50IGEgbG93ZXIgYml0cmF0ZSAgZm9y IGEgc3BlY2lmaWMgbXVsdGktcmF0ZSBjb2RlYyAoZS5nLg0KPiBPcHVzKSB0byBiZSB1c2VkIGZv ciBzdHJlYW0gQSwgYW5kIGhpZ2hlciBiaXRyYXRlIGZvciBzdHJlYW0gQi4gVGhpcyBvZg0KPiBj b3Vyc2UgY2FuIGJlIGhhbmRsZWQgd2l0aCB0aGUgcGVyLXNzcmMgZm10cCBhdHRyaWJ1dGVzIHRo YXQgYXJlIHNwZWNpZmllZCBpbg0KPiBSRkMgNTU3Ni4gSG93ZXZlciwgSSB0aGluayBpbiBhbG1v c3QgYWxsIGNhc2VzLCB0aGUgcmVjZWl2ZXIgaXMgaW4gYSBtdWNoDQo+IHdvcnNlIHBvc2l0aW9u IHRvIG1ha2UgdGhlc2UgZGVjaXNpb25zIHRoYXQgdGhlIHNlbmRlcjsgdGhlIHNlbmRlciwgYXdh cmUNCj4gb2YgdGhlIGVzdGltYXRlZCBiYW5kd2lkdGggdG8gdGhlIHJlY2VpdmVyLCBhbmQgdGhl IHJlbGF0aXZlDQo+IHZhbHVlL2NvbXBsZXhpdHkgb2YgaXRzIHN0cmVhbXMsIGNhbiBtYWtlIG1v cmUgaW5mb3JtZWQgZGVjaXNpb25zIGFib3V0DQo+IGJhbmR3aWR0aCBhbGxvY2F0aW9uLCBhbmQg cGVyZm9ybSB0aGVtIHdpdGhvdXQgYW55IHNpZ25hbGluZyBkZWxheS4NCj4gDQo+IA0KPiBZb3Un cmUgYXNzZXJ0aW5nIHRoYXQgdGhlIHBlcnNvbiBzZW5kaW5nIHRoZSBtZWRpYSAodG8gd2hvbSB0 aGUgcXVhbGl0eQ0KPiBoYXMgbGl0dGxlIG9yIG5vIGltcGFjdCkgaXMgYSBiZXR0ZXIgcGFydHkg dG8gc2VsZWN0IHRoZSBxdWFsaXR5IG9mIGEgc3RyZWFtIHRoYW4NCj4gdGhlIHBlcnNvbiByZWNl aXZpbmcgaXQ/DQo+IA0KPiBJIGhhdmUgbm90aGluZyB0byBzYXkgdG8gdGhhdC4gSXQncyBzdWZm aWNpZW50bHkgZmFsc2Ugb24gaXRzIGZhY2UgdGhhdCBJIHJlYWxseQ0KPiBoYXZlIG5vd2hlcmUg dG8gc3RhcnQgZ3JhcHBsaW5nIHdpdGggaXQuDQo+IA0KPiANCj4gDQo+IAk1KSBUaGUgZGlyZWN0 aW9uYWwgYXR0cmlidXRlIGRpc2N1c3Npb24gaW4gU2VjdGlvbiA0IG9taXRzIG9uZQ0KPiBpbXBv cnRhbnQgY29uc2VxdWVuY2Ugb2YgdGhlIGZhY3QgdGhhdCBhPXNzcmMgaW5kaWNhdGlvbnMgYXJl IHVuaWRpcmVjdGlvbmFsLA0KPiBuYW1lbHkgdGhhdCBzdHJlYW1zIGNvdWxkIGJlIGFkZGVkIG9y IHJlbW92ZWQgYnkgYm90aCBlbmRwb2ludHMNCj4gc2ltdWx0YW5lb3VzbHkgd2l0aG91dCBjYXVz aW5nIGEgZ2xhcmUgY29uZGl0aW9uLiBtPSBsaW5lcywgb24gdGhlIG90aGVyDQo+IGhhbmQsIHNp bmNlIHRoZXkgYXJlIGlkZW50aWZpZWQgYnkgdGhlaXIgaW5kZXgsIGRvIG5vdCBoYXZlIHRoaXMg cHJvcGVydHk7IGlmDQo+IGJvdGggc2lkZXMgZGVjaWRlIHRvIGFkZCBhIG09IGxpbmUgYXQgdGhl IHNhbWUgdGltZSwgYmFkIHRoaW5ncyBoYXBwZW4uDQo+IA0KPiANCj4gTm9uZSBvZiB0aGUgdGhy ZWUgYXBwcm9hY2hlcyBhdm9pZHMgdGhlIG5lY2Vzc2l0eSB0byBoYW5kbGUgZ2xhcmUuIFdpdGgg YQ0KPiBzdGF0ZWZ1bCBvZmZlci9hbnN3ZXIgYXBwcm9hY2gsIHRoZXJlJ3Mgc2ltcGx5IG5vIHdh eSBhcm91bmQgaXQuIFdlIHdvdWxkDQo+IGhhdmUgdG8gZ28gYmFjayB0byB0aGUgZHJhd2luZyBi b2FyZCBpZiB3ZSB3YW50ZWQgdG8gY29tZSB1cCB3aXRoIGENCj4gc3lzdGVtIHRoYXQgYXZvaWRl ZCBnbGFyZSAoYW5kIGV2ZW4gdGhlbiwgSSBkb24ndCB0aGluayBzdWNjZXNzIGlzIHZlcnkNCj4g bGlrZWx5KS4NCj4gDQo+IA0KPiANCj4gCTYpIFRoZSBsZWdhY3kgaW50ZXJvcCBhcmd1bWVudCBp biBTZWN0aW9uIDQgZmVlbHMgYSBiaXQgaGFuZC13YXZ5Lg0KPiBBc2lkZSBmcm9tIHRoZSBvbmUg Y2FzZSBvZiBoYXZpbmcgdmlkZW8gKyBwcmVzZW50YXRpb24gc3RyZWFtcywgSSBoYXZlIG5vdA0K PiB5ZXQgaGVhcmQgb2Ygd2lkZWx5IGRlcGxveWVkIGVxdWlwbWVudCB0aGF0IHVzZXMgbXVsdGlw bGUgYXVkaW8gb3IgdmlkZW8NCj4gbT0gbGluZXMsIGFuZCBjZXJ0YWlubHkgYW55IHN1Y2ggZXF1 aXBtZW50IHdpbGwgbm90IHVuZGVyc3RhbmQgQlVORExFIG9yDQo+IE1NVC4gVGhlcmVmb3JlIGEg Z2F0ZXdheSBpcyByZXF1aXJlZCwgYW5kIGFueSBnYXRld2F5IHRoYXQgd2FzDQo+IHBlcmZvcm1p bmcgQlVORExFIG9yIE1NVCBjb3VsZCBjZXJ0YWlubHkgZG8gdGhlIG1pbm9yIGFkZGl0aW9uYWwg d29yayB0bw0KPiBwYWNrYWdlIHRoZSBTRFAgYXMgMSBtPSBsaW5lIChyZW1lbWJlciwgaXQgYWxy ZWFkeSBuZWVkcyB0byBhZGQgdGhlIGE9c3NyYw0KPiBhdHRyaWJ1dGVzKS4gRXJnbywgSSBkb24n dCBhZ3JlZSB0aGF0IHRoZSBnZW5lcmFsIGNhc2Ugb2YgTiBtPSBsaW5lcyBuZWVkcyB0bw0KPiBi ZSBoYW5kbGVkIGJ5IGFsbCBSVENXRUIgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gDQo+IFRydXRo IGJlIHRvbGQsIGV2ZW4gdGhvdWdoIEkgY2FsbGVkIHRoaXMgImxlZ2FjeSBpbnRlcm9wLCIgaXQn cyBtb3JlIGFjY3VyYXRlDQo+IHRvIHRoaW5rIG9mIGl0IGFzICJpbnRlcm9wIHdpdGggbm9uLVJU Q1dFQiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2UgU0RQLCINCj4gb2Ygd2hpY2ggbGVnYWN5IGlz IGFuIGltcG9ydGFudCBzdWJzZXQuDQo+IA0KPiBJbiBhbnkgY2FzZSwgaWYgd2UncmUganVtcGlu ZyB0byBuZWVkaW5nIGEgZ2F0ZXdheSB0byBkbyBzdWJzdGFudGlhbCBTRFANCj4gcmV3cml0ZXMs IHRoZW4gSSBxdWVzdGlvbiB0aGUgdXNlIG9mIFNEUCBhdCBhbGwgaW4gUlRDV0VCLiBUaGUgc2Vs ZWN0aW9uIG9mDQo+IFNEUCwgdG8gbXkgdW5kZXJzdGFuZGluZywgd2FzIHRvIHByb3ZpZGUgc2lt cGxlciBpbnRlcm9wIHdpdGggbm9uLVJUQ1dFQg0KPiBpbXBsZW1lbnRhdGlvbnMuIE9uY2Ugd2Ug YXNzdW1lIHRoYXQgeW91J3JlIG5lY2Vzc2FyaWx5IHJld3JpdGluZyBpdCBmb3INCj4gc3VjaCBp bnRlcm9wIHRvIHdvcmssIHdlIG1heSBhcyB3ZWxsIGFiYW5kb24gaXQgYWx0b2dldGhlci4NCj4g DQo+IC9hDQoNCg== From christer.holmberg@ericsson.com Tue Feb 5 08:08:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7092E21F8903 for ; Tue, 5 Feb 2013 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr1pJCSRFO4J for ; Tue, 5 Feb 2013 08:08:44 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9021F8599 for ; Tue, 5 Feb 2013 08:08:44 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-c3-51112e8a060a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E8.0B.32353.A8E21115; Tue, 5 Feb 2013 17:08:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 17:08:42 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , Adam Roach , Justin Uberti Thread-Topic: [MMUSIC] Thoughts on m= lines and media streams Thread-Index: AQHOABGbpHhF1lwAyEyK/EQLPZFjjphkkBeAgAMHv4CAA7KeAIAAGJQAgAASiRQ= Date: Tue, 5 Feb 2013 16:08:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D402B@ESESSMB209.ericsson.se> References: <510B09A0.5040904@nostrum.com> <51111814.7010006@nostrum.com>, <92B7E61ADAC1BB4F941F943788C088280477E934@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280477E934@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW63nmCgQfMtXos9fxexW2ya9YXN YutUIYupyx+zWFxb/prVgdVjyu+NrB4LNpV6LFnyk8lj1s4nLAEsUVw2Kak5mWWpRfp2CVwZ 82ZPYi34yV3xZ+J6pgbG45xdjJwcEgImEltW3WWFsMUkLtxbz9bFyMUhJHCIUeL8ia+sEM5i Rom1LXtYuhg5ONgELCS6/2mDNIgIlEnMWPqCESTMLOAnsaFRFSQsLGAjsX3BRSaQsIiArcSp gy4Q1X4S3xduZAaxWQRUJFrOzmAHsXkFvCUeL2mB2jSDSaLp2B6wezgFfCVaPqwEK2IEuu37 qTVMIDazgLjErSfzmSBuFpBYsuc8M4QtKvHy8T+oXxQlPr7axwhRryOxYPcnNghbW2LZwtfM EIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWM7LmJmTnp5eabGIHxdHDLb4MdjJvuix1i lOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUV0v/WvzvtWZ5eceF3Nv5OCI Dftvc+5Mg+uzO34X0rcf+SST2uQcX2uYUiBwyIm9dNG5L2yRpdvmHjbVTJBZfkwpLf9Vc1nH JicR1s96PzYWsz04N63wYO/6yKmNpYU/Hf5FZkYX2j0Ql0gW3/eQ9VfJdC0u+eudEwU2uDFu E+C8kL68wWqaEktxRqKhFnNRcSIAesPDEXUCAAA= Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:08:45 -0000 Hi, >> 1) "1a" and "2", as described, have fatal problems if the receiver >> rejects the m=3D line that contains all the attributes (e.g. a=3Dice-ufr= ag, >> a=3Dcrypto, etc) >> >> >> Yeah, this part of the solution was put together kind of off-the-cuff. I= 'd >> considered three approaches, and this one was the least verbose. My >> second choice, which has better backwards compatibility properties >> anyway, is mandating that the transport-level attributes are in all the = m=3D >> sections to which they apply. You end up with redundant information, but= it >> does get around issues with rejecting some sections. > > Why not specify such transport attributes at the session level. For thos= e attributes that are currently media level only, extend them to define how= they work at the session level. > > For example, b=3D at the session level is already defined to be the maxim= um bandwidth across the entire session whereas b=3D at the m=3Dsection leve= l is for that m=3Dsection only. > For media direction/mode, a=3Dsendonly/sendrecv/inactive/recvonly can be = specified at the session level, in which case it applies to all m=3Dsection= s unless they specify their own value. > Similarly, ICE candidates could be specified at the session level and hav= e those apply at all media levels, unless the media level specifies its own= value. That has been considered, but how would it work if the remote endpoint does= n't support the mechanism? Regards, Christer From ron.even.tlv@gmail.com Tue Feb 5 08:17:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA821F855C for ; Tue, 5 Feb 2013 08:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=1.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7alJiGne9foL for ; Tue, 5 Feb 2013 08:17:21 -0800 (PST) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id CC00221F8550 for ; Tue, 5 Feb 2013 08:17:20 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id e51so199219eek.23 for ; Tue, 05 Feb 2013 08:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=N09VLUy4MP574bui07oGZXC+L09ZPXzXxbmpAjjWbTI=; b=sc5681wCfmmsK3tdZWGEXm6IcVGFFq5cZuTfpjr9o+SLDsNVC+zynt+i/NmkTTw0/K KI0cTykXv8mQWim0R7PatcQX2vMdvNb6yY/DViF4Q7vZri1kPPTzd6Yx+qAShQPLalSb 8pA5v06Zf6lCqmPWB0lEqb8Nqj7ZD5yxzgsLgzLl2Ee/8tvXE2UXOyekoDQxvHAeLm9v uNE9eKduzbMo3bvh2ppkAcY4rMfL5xZiVC+9Ay//yGI70XiCmjB4IwOzvftEHWH6sZsp R+krbHJWfanCbnjxzm+7nqk8KB9PPK6qsdgP+tUghpOF5ITFcsFi+U28GgUThITY8UIq pXKw== X-Received: by 10.14.194.195 with SMTP id m43mr85828542een.44.1360081039950; Tue, 05 Feb 2013 08:17:19 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id k7sm30093442een.8.2013.02.05.08.17.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Feb 2013 08:17:18 -0800 (PST) From: "Roni Even" To: "'Adam Roach'" , References: <510B09A0.5040904@nostrum.com> In-Reply-To: <510B09A0.5040904@nostrum.com> Date: Tue, 5 Feb 2013 18:14:27 +0200 Message-ID: <042701ce03bb$e0af0fe0$a20d2fa0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJMrhL1kxjNXjJe3zphznJf2EToepduGoTg Content-Language: en-us Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:17:22 -0000 Hi, One requirement that may be important for your analysis is if there must be one offer answer exchange or more for setting the call. Some of the current solutions are doing a second one in order to reflect the current state and prevent codec switching or new content without explicit signaling. This is because they are not capable of doing it. This can address the SBC issue that expect to have the correct SDP. BTW: this is also an issue in CLUE since the initial offer may have a minimal set and the actual SDP can only be specified after the CLUE negotitation. Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Adam Roach Sent: 01 February, 2013 2:18 AM To: mmusic@ietf.org Subject: [MMUSIC] Thoughts on m= lines and media streams Based on the conversations we've had so far, I've put together the following summary of my thoughts on the topic of whether we want to put multiple media streams in a single m= line. http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt Sorry for the relatively short lead time before next week's meeting -- I had meant to put this kind of summary together a week or two ago, but have been far busier than I anticipated. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Tue Feb 5 08:19:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3B21F8934 for ; Tue, 5 Feb 2013 08:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=3.310, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP4XoBEhDae1 for ; Tue, 5 Feb 2013 08:19:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 228AD21F8915 for ; Tue, 5 Feb 2013 08:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4663; q=dns/txt; s=iport; t=1360081191; x=1361290791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GRy9TVyduBBVcw+3PwLjkKCrt7lCKTcGi3Fjif6y8pU=; b=fMbzLrvZ99uVXC9T1VmVXPzDft+8PQlfgfvz5SM4p2xqerPowzBFKIob XWnBkeOL6xFXBCAUbeOlM9zh89bKCQftxuPhSGjLtr/3BurTiX0LUptV8 pFWF+SWjQwnBG2V+2zB1yBisr0SY3xw7Y49RcAyzkB5TN0hQsqqguNkyW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFEwEVGtJXG8/2dsb2JhbABFv2EWc4IfAQEBAwE6LhEMBAIBCBEEAQEBChQJBzIUCQgCBAENBQgTh3AGqjWQLo0kg1ZhA6Zzgn6CJA X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="170590932" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 05 Feb 2013 16:19:50 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r15GJo7j003886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 16:19:50 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 10:19:50 -0600 From: "Charles Eckel (eckelcu)" To: Adam Roach , Justin Uberti Thread-Topic: [MMUSIC] More thoughts on multiple media streams in a single m= line Thread-Index: AQHOAqu2LYA/ph/xo0SCEOgM5p8WMphryWKA//+mRaA= Date: Tue, 5 Feb 2013 16:19:50 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280477E994@xmb-aln-x08.cisco.com> References: <5111247B.8060904@nostrum.com> In-Reply-To: <5111247B.8060904@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:19:52 -0000 I think we are all in agreement that for a large conference (e.g. 100+ audi= o/video streams), we cannot require that each media stream have its own m= =3Dsection, nor can we require that each media stream's SSRC is signaled in= SDP. For the sake of example, let's assume a centralized conference server= is able to send up to 10 video streams, where each video stream may be any= of the 100 video streams at various points in time (e.g. active speakers s= witched in/out, specific sources requested, etc.), I think there are three = realistic alternatives: 1) Use 10 m=3Dsections to define the ten video streams, no multiplexing req= uired 2) Use 1 m=3Dsection to define a video stream, and indicate that up to 10 = video streams are multiplexed within it 3) Use 'n' m=3Dsections to define the video streams, where 1<=3Dn<=3D10 We already have all we need to do (1). There is a desire to improve on (1). If we define some additional syntax/semantics that enable (2), people can c= hoose to use (2) or (3) depending on works best for their scenario. There h= ave already been some drafts submitted along these lines, I suggest to take= a closer look at those and improve on them. Sounds reasonable? Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Tuesday, February 05, 2013 10:26 AM > To: Justin Uberti > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single > m=3D line >=20 > On 2/4/13 02:45, Justin Uberti wrote: >=20 >=20 > Sorry for the short lead time, but here's a quick read for the plane. >=20 >=20 > I addressed several of the assertions made in this draft in my previous > response (e.g. the need for glare resolution regardless of which solution= we > select). Some additional thoughts: >=20 >=20 >=20 > o Adding or removing a source requires sending a full list of all > sources, which doesn't scale well to 10s or 100s of sources, > especially when they are added or removed frequently. >=20 >=20 > Realistically, this isn't how multiparty conferences are handled. It's > unrealistic to think that my DSL connection is going to be sucking down > hundreds of video streams just because I'm in a video conference with > hundreds of people. >=20 > In practice, the way existing conferencing systems handle this is to send= a > small, manageable number of streams to each participant, changing them > out as necessary to have a reasonable user experience (either under the > control of the user, its own algorithms, or a combination of the two). >=20 > Which is to say: even with hundreds of source streams being fed into a > conference system, you're really looking at a realistic upper bound on m= =3D > sections of a dozen or two, simply because you can't reasonably expect > recipients to receive more than that many streams simultaneously. >=20 > And really, if you're imagining hundreds of media streams flowing towards > an endpoint, any arguments about the bits consumed by SDP go well > beyond disingenuous. >=20 >=20 >=20 > o Because this solution requires BUNDLE, which is still not widely > supported, it can be deployed in fewer situations >=20 >=20 > This is completely out of left field: the alternative is MMT, which is ev= en > less well developed than BUNDLE. >=20 >=20 >=20 > 4. The RFC5576-based approach has already been in use for many > years > in a major video conferencing system (Google+ Hangouts), and > has > worked very well. We feel that we have searched the > "unknown" > space and solved all of the major issues. >=20 >=20 > I think this actually does a good job of illustrating your blind spot: yo= u're > working within RTCWEB, but developing for a single, very precise use case= . > For example, this kind of experience doesn't translate well into the > challenges that might arise from systems that are dealing with radically > different user experiences. Google-hangout-type uses are certainly > important, but they're not the only thing we're designing for. You need t= o > think about systems with pre-encoded (stored) media; systems with radical > imbalances in the processing power and device capabilities between the > endpoints; systems with different stream control models, etc, etc. >=20 >=20 >=20 > On the other hand, the multi m=3D > section approach has never been tried by anyone, that we are > aware of >=20 >=20 > Do a web search for "Marconi ViPr." >=20 > /a From btv1==748279b0a2f==HKaplan@acmepacket.com Tue Feb 5 08:41:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68521F894C for ; Tue, 5 Feb 2013 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBbGV8GakS3s for ; Tue, 5 Feb 2013 08:41:40 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 91AEA21F8938 for ; Tue, 5 Feb 2013 08:41:40 -0800 (PST) X-ASG-Debug-ID: 1360082498-03fc21725f422510001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id owkddaMpKKPYNYag (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 05 Feb 2013 11:41:38 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.67]) by Mail1.acmepacket.com ([169.254.1.214]) with mapi id 14.02.0283.003; Tue, 5 Feb 2013 11:41:37 -0500 From: Hadriel Kaplan To: Flemming Andreasen Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt Thread-Index: AQHOA7+qo1u8CdrcbEusawlM8U7ClQ== Date: Tue, 5 Feb 2013 16:41:37 +0000 Message-ID: <3A88DFA6-527B-43CF-B366-BD0A64DC4362@acmepacket.com> References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> <5106B189.5090909@cisco.com> In-Reply-To: <5106B189.5090909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <461F18CE0FA8654FB801FD5B42724BE9@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1360082498 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.121894 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:42:00 -0000 On Jan 28, 2013, at 12:12 PM, Flemming Andreasen wrote= : > Thanks for taking a look and providing your comments Hadriel. As per prev= ious discussions, we wanted to first agree on the scope of the document and= whether there was still value in pursuing such a document. As per Gonzalo'= s e-mail starting this thread, do you have any comments/concerns on that pa= rt (if so, please let the authors know what those are) ? Sorry didn't respond to the above yet=85 I assumed that the WG already deci= ded to continue moving towards publishing it. Back in March last year I asked what the point/purpose of the draft was, he= re: http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html As chair you called for a WG Poll, here: http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html And provided your rationale for publishing it here: http://www.ietf.org/mail-archive/web/mmusic/current/msg09369.html The response to that was positive (5 people agreeing, none against). So I was just moving on to discussing what's in the draft, vs. why bother p= ublishing it. -hadriel From fandreas@cisco.com Tue Feb 5 08:50:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9600821F893E for ; Tue, 5 Feb 2013 08:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUmqr8KizgYx for ; Tue, 5 Feb 2013 08:50:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA5F21F8939 for ; Tue, 5 Feb 2013 08:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1360083020; x=1361292620; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PzhJcr1628VvdoJQjzFp7RF0CF2O0n2oUllXbdFIRtE=; b=OzkRMKWCELhL7wgssAKCFphsOzhVtfMz1js2Vx+ikWhTPvoflWpHTsRa OfQ7RiHVyMnb0G2XGWVgyDquAVS+KuUcKDa2euswRHkcYGuwPvoS/3eWf KTkdIifk9jxLOi0VlRhzt3QslGwQEaD9YzEPcimlw19LqcIjEFCwGAHdF Q=; X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173604909" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 05 Feb 2013 16:50:19 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.253.153]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r15GoIjM029061; Tue, 5 Feb 2013 16:50:19 GMT Message-ID: <51113849.4000208@cisco.com> Date: Tue, 05 Feb 2013 11:50:17 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> <5106B189.5090909@cisco.com> <3A88DFA6-527B-43CF-B366-BD0A64DC4362@acmepacket.com> In-Reply-To: <3A88DFA6-527B-43CF-B366-BD0A64DC4362@acmepacket.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org, mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:50:20 -0000 On 2/5/13 11:41 AM, Hadriel Kaplan wrote: > On Jan 28, 2013, at 12:12 PM, Flemming Andreasen wrote: > >> Thanks for taking a look and providing your comments Hadriel. As per previous discussions, we wanted to first agree on the scope of the document and whether there was still value in pursuing such a document. As per Gonzalo's e-mail starting this thread, do you have any comments/concerns on that part (if so, please let the authors know what those are) ? > > Sorry didn't respond to the above yet… I assumed that the WG already decided to continue moving towards publishing it. > > Back in March last year I asked what the point/purpose of the draft was, here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html > > As chair you called for a WG Poll, here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html > > And provided your rationale for publishing it here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09369.html > > The response to that was positive (5 people agreeing, none against). > > So I was just moving on to discussing what's in the draft, vs. why bother publishing it. Thanks Hadriel Based on that, let's continue with the technical issues you've raised. Authors: Please chime in and work on resolving the issues being raised. Thanks -- Flemming > -hadriel > > . > From eckelcu@cisco.com Tue Feb 5 09:05:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3F21F881C for ; Tue, 5 Feb 2013 09:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.989 X-Spam-Level: X-Spam-Status: No, score=-6.989 tagged_above=-999 required=5 tests=[AWL=1.810, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eli6FEnapP7r for ; Tue, 5 Feb 2013 09:05:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0B21F870C for ; Tue, 5 Feb 2013 09:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2375; q=dns/txt; s=iport; t=1360083927; x=1361293527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LLkVFYdwkMbfjCDl9xZ7NKAYHPt28qGseTaZ0weq3pU=; b=Uj38rZzgmXPfZCIMZPqcjkXmVd/H5txF/w7ci3cu3thdf0g7/+6vcGCy aJrnEjEHwkJovl4NXpqVKbSHVfpGGByGN8raYP9VP+40IP9AbU0Oam/Dc 56HBOZNW9PXzYQl0dpX2yULRWaJUPxGaQQgT+cuYVNW3nQdXX0Lj6f9af I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC47EVGtJV2b/2dsb2JhbABFv2EWc4IfAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIE4dwBgyqPZApBJB6YQOmc4J+giQ X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173395068" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 05 Feb 2013 17:05:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r15H5Q64004668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 17:05:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 11:05:26 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , Adam Roach , Justin Uberti Thread-Topic: [MMUSIC] Thoughts on m= lines and media streams Thread-Index: AQHOABGcqHdo41Qt7E+/OUBDRVXw6ZhlBXCAgAMHvoCAA7KfAP//sUGQgABphgD//6jrwA== Date: Tue, 5 Feb 2013 17:05:25 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280477EA76@xmb-aln-x08.cisco.com> References: <510B09A0.5040904@nostrum.com><51111814.7010006@nostrum.com>, <92B7E61ADAC1BB4F941F943788C088280477E934@xmb-aln-x08.cisco.com> <1.338d281849d6a3b40268@ericsson.com> In-Reply-To: <1.338d281849d6a3b40268@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:05:28 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, February 05, 2013 11:09 AM > To: Charles Eckel (eckelcu); Adam Roach; Justin Uberti > Cc: mmusic@ietf.org; Peter Thatcher > Subject: Re: [MMUSIC] Thoughts on m=3D lines and media streams >=20 >=20 > Hi, >=20 > >> 1) "1a" and "2", as described, have fatal problems if the receiver > >> rejects the m=3D line that contains all the attributes (e.g. a=3Dice-u= frag, > >> a=3Dcrypto, etc) > >> > >> > >> Yeah, this part of the solution was put together kind of off-the-cuff.= I'd > >> considered three approaches, and this one was the least verbose. My > >> second choice, which has better backwards compatibility properties > >> anyway, is mandating that the transport-level attributes are in all th= e m=3D > >> sections to which they apply. You end up with redundant information, > but it > >> does get around issues with rejecting some sections. > > > > Why not specify such transport attributes at the session level. For tho= se > attributes that are currently media level only, extend them to define how > they work at the session level. > > > > For example, b=3D at the session level is already defined to be the max= imum > bandwidth across the entire session whereas b=3D at the m=3Dsection level= is for > that m=3Dsection only. > > For media direction/mode, a=3Dsendonly/sendrecv/inactive/recvonly can b= e > specified at the session level, in which case it applies to all m=3Dsecti= ons > unless they specify their own value. > > Similarly, ICE candidates could be specified at the session level and h= ave > those apply at all media levels, unless the media level specifies its own > value. >=20 > That has been considered, but how would it work if the remote endpoint > doesn't support the mechanism? Crap. That said, I think you have that same concern with any approach. Usin= g ICE candidates as an example, how do you know if the remote endpoint supp= orts the same candidate existing in multiple m=3Dsections and will use them= as intended. Cheers, Charles =20 =20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From juberti@google.com Tue Feb 5 09:18:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0121F8933 for ; Tue, 5 Feb 2013 09:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFv2BwWcaFR7 for ; Tue, 5 Feb 2013 09:18:14 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C921F892C for ; Tue, 5 Feb 2013 09:18:10 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so155086qcs.13 for ; Tue, 05 Feb 2013 09:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RXkhN3SWtKC5oPzExQoJvvZs4ZRdN2zYpkMleD5KXSI=; b=RZSEZZODhRwYjORaLhmItzj+b6OE4vRcSWTjszdaoUh4jakVGekWI35BCfX0iYq0XH mnnVO/BMNirYCFQL6wVbEQ/n3tEZV7MCFMOd052OF7RncDPC43pSB9A54Ec1hyC0pHNR /6tBamRzmS60cX19pbOjbfmjYjN4OwRp6F4zANw2avLrZlr8fFdv3mmR5TREPZcfslcR RwkrWaDkjwrZZaYKYK3n9uFYyyh08LdKbwpNs2QzvMTu242I78+gPHrX+qIZueViv00r wDdQxW4VziE7BcpS0+3+7vZPX45w99+b5HqNYV2Ip7M0OwhznssRLMXvpGnEXjFDU4dN hQRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=RXkhN3SWtKC5oPzExQoJvvZs4ZRdN2zYpkMleD5KXSI=; b=CIRIdeNKfyqk1WZqF9r5NUTOa12UFGbW/tVCbhEH46gfyhSeeiZwBdHO6M+zLZOkFo ayN+aNpDsl49lBrYIjlW0lRVFQQzXQqjphozM9Hq/zj4ENPnMdIk6KWyFr3kiZV7HcYY YxINmRPwHpMbNs85SO/wZBA71RvH7vIkKImUGBfa/OW5VcbrOk25HmB8wbI42oO30Ogt oMkUL77Pil3bR+bY9OIXRA5gWgrU8w6a/wLp94t4xs3E3ajebPOiAzghOr5m1Qy80VOX U6VKYJ+oZs4CEZdwchmAkxglis1sefotV7ty7wPqKu5SFRqEbBSOqNp4Znw/TjtsdMjP 2P0Q== X-Received: by 10.224.31.196 with SMTP id z4mr20010364qac.20.1360084689454; Tue, 05 Feb 2013 09:18:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.202.220 with HTTP; Tue, 5 Feb 2013 09:17:49 -0800 (PST) In-Reply-To: <51111814.7010006@nostrum.com> References: <510B09A0.5040904@nostrum.com> <51111814.7010006@nostrum.com> From: Justin Uberti Date: Tue, 5 Feb 2013 09:17:49 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=20cf306f720cc786c604d4fd64cd X-Gm-Message-State: ALoCoQn5jzsUVjeZILtnEg4zwMdF8FedVjC5yuyZYq8JWr7ilBHBMO8PbspUOAjag0xJOqxJVUNQ2kwNctG4BKuqDOFsjaOVK7EipB8f44JAzgEf07t4pi0RFXXAZqlMmfwJmYmHUveMsvcV6TCG6S9C/yxNup9SQxqflKI3uezz00Vo4v5MFB1ROJioClGwvoo4JXQ49Mm7 Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:18:15 -0000 --20cf306f720cc786c604d4fd64cd Content-Type: text/plain; charset=UTF-8 On Tue, Feb 5, 2013 at 6:32 AM, Adam Roach wrote: > On 2/3/13 01:04, Justin Uberti wrote: > > 1) "1a" and "2", as described, have fatal problems if the receiver rejects > the m= line that contains all the attributes (e.g. a=ice-ufrag, a=crypto, > etc) > > > Yeah, this part of the solution was put together kind of off-the-cuff. I'd > considered three approaches, and this one was the least verbose. My second > choice, which has better backwards compatibility properties anyway, is > mandating that the transport-level attributes are in all the m= sections to > which they apply. You end up with redundant information, but it does get > around issues with rejecting some sections. > > > 2) In "1b", it's not clear what the purpose of the "a=group:MMT foo bar > zoe" line is. > > > Unfortunately, I really didn't have the time I wanted to put this draft > together, and there's more than a little carelessness in the SDP examples. > That shouldn't be there. > > > 3) Proposal "2" does not include the needed a=ssrc lines for > demultiplexing the received streams. IOW, proposal 2 requires RFC 5576 just > like 1a and 1b. > > > And this is the sloppiness I referred to above. The different sections > should have non-overlapping RTP payload types. > Alas, RTP payload types are not sufficient for demux, since RTCP packets don't include RTP PTs. > > > 4) The codec selection argument in Section 2.3.1 feels like a "Red > Herring" to me. Practically speaking, I think there are few, if any, > real-world settings where one might want to use a codec prioritization > mechanism to ask for a low-bitrate codec for stream A and a high-bitrate > codec for stream B (where the codecs used are different). A more realistic > example would be where one might want a lower bitrate for a specific > multi-rate codec (e.g. Opus) to be used for stream A, and higher bitrate > for stream B. This of course can be handled with the per-ssrc fmtp > attributes that are specified in RFC 5576. However, I think in almost all > cases, the receiver is in a much worse position to make these decisions > that the sender; the sender, aware of the estimated bandwidth to the > receiver, and the relative value/complexity of its streams, can make more > informed decisions about bandwidth allocation, and perform them without any > signaling delay. > > > You're asserting that the person sending the media (to whom the quality > has little or no impact) is a better party to select the quality of a > stream than the person receiving it? > > I have nothing to say to that. It's sufficiently false on its face that I > really have nowhere to start grappling with it. > I should have been more clear. Yes, the receiver is the one who needs to choose the relative priorities of streams, but the sender is in a better place to make actual decisions about how those preferences should be carried out (for example, what bitrate should be sent, or which layers of a layered codec should be used). Even if the receiver retains full control, the receiver could still ask for different bitrates given using the mechanisms I described above. > > > 5) The directional attribute discussion in Section 4 omits one important > consequence of the fact that a=ssrc indications are unidirectional, namely > that streams could be added or removed by both endpoints simultaneously > without causing a glare condition. m= lines, on the other hand, since they > are identified by their index, do not have this property; if both sides > decide to add a m= line at the same time, bad things happen. > > > None of the three approaches avoids the necessity to handle glare. With a > stateful offer/answer approach, there's simply no way around it. We would > have to go back to the drawing board if we wanted to come up with a system > that avoided glare (and even then, I don't think success is very likely). > Since WebRTC leaves the signaling up to the application, if your signaling system allows for partial updates, you can have "stream-add" and "stream-remove" operations that are glareless. > > > 6) The legacy interop argument in Section 4 feels a bit hand-wavy. Aside > from the one case of having video + presentation streams, I have not yet > heard of widely deployed equipment that uses multiple audio or video m= > lines, and certainly any such equipment will not understand BUNDLE or MMT. > Therefore a gateway is required, and any gateway that was performing BUNDLE > or MMT could certainly do the minor additional work to package the SDP as 1 > m= line (remember, it already needs to add the a=ssrc attributes). Ergo, I > don't agree that the general case of N m= lines needs to be handled by all > RTCWEB implementations. > > > Truth be told, even though I called this "legacy interop," it's more > accurate to think of it as "interop with non-RTCWEB implementations that > use SDP," of which legacy is an important subset. > > In any case, if we're jumping to needing a gateway to do substantial SDP > rewrites, then I question the use of SDP at all in RTCWEB. The selection of > SDP, to my understanding, was to provide simpler interop with non-RTCWEB > implementations. Once we assume that you're necessarily rewriting it for > such interop to work, we may as well abandon it altogether. > > /a > --20cf306f720cc786c604d4fd64cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 5, 2013 at 6:32 AM, Adam Roach <adam@nostrum.com>= ; wrote:
=20 =20 =20
On 2/3/13 01:04, Justin Uberti wrote:
1) "1a" and "2", as described, h= ave fatal problems if the receiver rejects the m=3D line that contains all the attributes (e.g. a=3Dice-ufrag, a=3Dcrypto, etc)

Yeah, this part of the solution was put together kind of off-the-cuff. I'd considered three approaches, and this one was the least verbose. My second choice, which has better backwards compatibility properties anyway, is mandating that the transport-level attributes are in all the m=3D sections to which they apply. You end up with redundant information, but it does get around issues with rejecting some sections.


2) In "1b", it's not clear what the purpose of t= he "a=3Dgroup:MMT foo bar zoe" line is.

Unfortunately, I really didn't have the time I wanted to put this draft together, and there's more than a little carelessness in the SDP examples. That shouldn't be there.


3) Proposal "2" does not include the needed a=3Dssrc lines= for demultiplexing the received streams. IOW, proposal 2 requires RFC 5576 just like 1a and 1b.

And this is the sloppiness I referred to above. The different sections should have non-overlapping RTP payload types.

Alas, RTP payload types are not sufficient for= demux, since RTCP packets don't include RTP PTs.=C2=A0


4) The codec selection argument in Section 2.3.1 feels like a "Red Herring" to me. Practically speaking,= I think there are few, if any, real-world settings where one might want to use a codec prioritization mechanism to ask for a low-bitrate codec for stream A and a high-bitrate codec for stream B (where the codecs used are different). A more realistic example would be where one might want a lower bitrate =C2=A0for a specific multi-rate codec (e.g. Opus) to be used for stream A, and higher bitrate for stream B. This of course can be handled with the per-ssrc fmtp attributes that are specified in RFC 5576. However, I think in almost all cases, the receiver is in a much worse position to make these decisions that the sender; the sender, aware of the estimated bandwidth to the receiver, and the relative value/complexity of its streams, can make more informed decisions about bandwidth allocation, and perform them without any signaling delay.

You're asserting that the person sending the media (to whom the quality has little or no impact) is a better party to select the quality of a stream than the person receiving it?

I have nothing to say to that. It's sufficiently false on its face that I really have nowhere to start grappling with it.

I should have been more clear. Yes, the receive= r is the one who needs to choose the relative priorities of streams, but th= e sender is in a better place to make actual decisions about how those pref= erences should be carried out (for example, what bitrate should be sent, or= which layers of a layered codec should be used).

Even if the receiver retains full control, = the receiver could still ask for different bitrates given using the mechani= sms I described above.
=C2=A0


5) The directional attribute discussion in Section 4 omits one important consequence of the fact that a=3Dssrc indications are unidirectional, namely that streams could be added or removed by both endpoints simultaneously without causing a glare condition. m=3D lines, on the other hand, since they are identified by their index, do not have this property; if both sides decide to add a m=3D line at the same time, bad things happen.

None of the three approaches avoids the necessity to handle glare. With a stateful offer/answer approach, there's simply no way around it. We would have to go back to the drawing board if we wanted to come up with a system that avoided glare (and even then, I don't think success is very likely).

Since WebRTC leaves the signaling up to the application, if your signal= ing system allows for partial updates, you can have "stream-add" = and "stream-remove" operations that are glareless.=C2=A0


6) The legacy interop argument in Section 4 feels a bit hand-wavy. Aside from the one case of having video + presentation streams, I have not yet heard of widely deployed equipment that uses multiple audio or video m=3D lines, and certainly any such equipment will not understand BUNDLE or MMT. Therefore a gateway is required, and any gateway that was performing BUNDLE or MMT could certainly do the minor additional work to package the SDP as 1 m=3D line (remember, it already needs to add the a=3Dssrc attributes). Ergo, I don't agree that the general case of N m=3D lines needs to be handled by all RTCWEB implementations.

Truth be told, even though I called this "legacy interop," it= 's more accurate to think of it as "interop with non-RTCWEB implementation= s that use SDP," of which legacy is an important subset.

In any case, if we're jumping to needing a gateway to do substantia= l SDP rewrites, then I question the use of SDP at all in RTCWEB. The selection of SDP, to my understanding, was to provide simpler interop with non-RTCWEB implementations. Once we assume that you're necessarily rewriting it for such interop to work, we may as well abandon it altogether.
/a

--20cf306f720cc786c604d4fd64cd-- From adam@nostrum.com Tue Feb 5 09:30:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE921F8A00 for ; Tue, 5 Feb 2013 09:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+cmSRTrrwSJ for ; Tue, 5 Feb 2013 09:30:35 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7F21F89F9 for ; Tue, 5 Feb 2013 09:30:35 -0800 (PST) Received: from Orochi.local (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r15HUUk8039493 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 11:30:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <511141B1.6080409@nostrum.com> Date: Tue, 05 Feb 2013 12:30:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Justin Uberti References: <510B09A0.5040904@nostrum.com> <51111814.7010006@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 155.212.214.60 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , Peter Thatcher Subject: Re: [MMUSIC] Thoughts on m= lines and media streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:30:36 -0000 On 2/5/13 12:17, Justin Uberti wrote: > Even if the receiver retains full control, the receiver could still > ask for different bitrates given using the mechanisms I described above. Ah, yes, I forgot to speak to those directly. You're making assumptions here that all the codecs we want to use will be one-size-fits-all (with all adjustments to all uses possible by parameters on those codecs) from now until this technology is obsolete. I think that's short-sighted. /a From ron.even.tlv@gmail.com Tue Feb 5 10:00:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82921F887F for ; Tue, 5 Feb 2013 10:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pqy7qqmCNwe for ; Tue, 5 Feb 2013 10:00:40 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 40BC321F87CE for ; Tue, 5 Feb 2013 10:00:40 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d4so244329eek.36 for ; Tue, 05 Feb 2013 10:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=vp4mj7YH23/+iQSZOPL8lu88bvLpn35GhAaiXKR+t6k=; b=IavbY4Gy+ayOqKTSh+sT2GtDpoxNcaGjHghSgUlyZwqkET4IniYygQ2xZtMUsYUEIv fQS3IabQ6dO3k/8JZQ1dLjAh7gMOlO6huX+ZoQnC3WPRVoGZOWr5b5UdZYU+7CNaKBhP Yi/JX46H3+HZt7WzhfmwArnWH3Uqa59/KNo4lfZOCATkpLcISA2Q6EUrluUN6RI2hRWa IjHnt//7GIkfLKkg+gFLY2h4xX/AwF/hbg49gjo+unOPHWnvxcrlTJI2B9eJYCWLocYT L6anTCr0VeQ6Xcx27KmHhlVlCBGYLFDEHXUxzl6jxgOzdx17Mv7Gy3FaImJvTGvto/Th j2XQ== X-Received: by 10.14.211.137 with SMTP id w9mr85960099eeo.39.1360087239365; Tue, 05 Feb 2013 10:00:39 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id b2sm33144246eep.9.2013.02.05.10.00.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Feb 2013 10:00:38 -0800 (PST) From: "Roni Even" To: "'Charles Eckel \(eckelcu\)'" , "'Adam Roach'" , "'Justin Uberti'" References: <5111247B.8060904@nostrum.com> <92B7E61ADAC1BB4F941F943788C088280477E994@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280477E994@xmb-aln-x08.cisco.com> Date: Tue, 5 Feb 2013 19:57:47 +0200 Message-ID: <042e01ce03ca$503af000$f0b0d000$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJvIytZRgs1P9YZREJhle3noIrn/AFm7fQ4AoDj2tKXCg990A== Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:00:41 -0000 Charles, Even for 1 you need maxssrc, you assume that one m-line means one RTP stream. Roni -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) Sent: 05 February, 2013 6:20 PM To: Adam Roach; Justin Uberti Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line I think we are all in agreement that for a large conference (e.g. 100+ audio/video streams), we cannot require that each media stream have its own m=section, nor can we require that each media stream's SSRC is signaled in SDP. For the sake of example, let's assume a centralized conference server is able to send up to 10 video streams, where each video stream may be any of the 100 video streams at various points in time (e.g. active speakers switched in/out, specific sources requested, etc.), I think there are three realistic alternatives: 1) Use 10 m=sections to define the ten video streams, no multiplexing required 2) Use 1 m=section to define a video stream, and indicate that up to 10 video streams are multiplexed within it 3) Use 'n' m=sections to define the video streams, where 1<=n<=10 We already have all we need to do (1). There is a desire to improve on (1). If we define some additional syntax/semantics that enable (2), people can choose to use (2) or (3) depending on works best for their scenario. There have already been some drafts submitted along these lines, I suggest to take a closer look at those and improve on them. Sounds reasonable? Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Tuesday, February 05, 2013 10:26 AM > To: Justin Uberti > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] More thoughts on multiple media streams in a > single m= line > > On 2/4/13 02:45, Justin Uberti wrote: > > > Sorry for the short lead time, but here's a quick read for the plane. > > > I addressed several of the assertions made in this draft in my > previous response (e.g. the need for glare resolution regardless of > which solution we select). Some additional thoughts: > > > > o Adding or removing a source requires sending a full list of all > sources, which doesn't scale well to 10s or 100s of sources, > especially when they are added or removed frequently. > > > Realistically, this isn't how multiparty conferences are handled. It's > unrealistic to think that my DSL connection is going to be sucking > down hundreds of video streams just because I'm in a video conference > with hundreds of people. > > In practice, the way existing conferencing systems handle this is to > send a small, manageable number of streams to each participant, > changing them out as necessary to have a reasonable user experience > (either under the control of the user, its own algorithms, or a combination of the two). > > Which is to say: even with hundreds of source streams being fed into a > conference system, you're really looking at a realistic upper bound on > m= sections of a dozen or two, simply because you can't reasonably > expect recipients to receive more than that many streams simultaneously. > > And really, if you're imagining hundreds of media streams flowing > towards an endpoint, any arguments about the bits consumed by SDP go > well beyond disingenuous. > > > > o Because this solution requires BUNDLE, which is still not widely > supported, it can be deployed in fewer situations > > > This is completely out of left field: the alternative is MMT, which is > even less well developed than BUNDLE. > > > > 4. The RFC5576-based approach has already been in use for many > years > in a major video conferencing system (Google+ Hangouts), and > has > worked very well. We feel that we have searched the "unknown" > space and solved all of the major issues. > > > I think this actually does a good job of illustrating your blind spot: > you're working within RTCWEB, but developing for a single, very precise use case. > For example, this kind of experience doesn't translate well into the > challenges that might arise from systems that are dealing with > radically different user experiences. Google-hangout-type uses are > certainly important, but they're not the only thing we're designing > for. You need to think about systems with pre-encoded (stored) media; > systems with radical imbalances in the processing power and device > capabilities between the endpoints; systems with different stream control models, etc, etc. > > > > On the other hand, the multi m= > section approach has never been tried by anyone, that we are > aware of > > > Do a web search for "Marconi ViPr." > > /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Tue Feb 5 10:55:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14AE21F85AE for ; Tue, 5 Feb 2013 10:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UURGhswiLk2y for ; Tue, 5 Feb 2013 10:55:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBB521F85AB for ; Tue, 5 Feb 2013 10:55:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A0DD39E130 for ; Tue, 5 Feb 2013 19:54:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BfV9b4iu8Ox for ; Tue, 5 Feb 2013 19:54:56 +0100 (CET) Received: from [192.168.2.15] (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 30F3B39E0C8 for ; Tue, 5 Feb 2013 19:54:56 +0100 (CET) Message-ID: <5111557E.3060305@alvestrand.no> Date: Tue, 05 Feb 2013 19:54:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <510B09A0.5040904@nostrum.com> <510D9D82.1030202@alvestrand.no> <1.581076994469ce232dbc@nostrum.com> In-Reply-To: <1.581076994469ce232dbc@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Multicast and one-m-line-per-stream (Re: Thoughts on m= lines and media streams) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:55:07 -0000 On 02/05/2013 04:52 PM, Adam Roach wrote: > Before I respond, I do want to make sure that this is the same Harald > Alvestrand who was proposing that we dismiss the vast majority of > existing SDP attributes on the premise that they are of no interest to > WEBRTC. Told you I hated to do this :-) > > /a > > On 2/2/13 18:13, Harald Alvestrand wrote: > > Adam, > > > > I hate to play the multicast card, because I'm fundamentally > > uninterested in multicast at the moment, but.... > > > > in your scheme 2, how would you represent multicast and > > transport-mixer based sessions? > > > > > > On 02/01/2013 01:17 AM, Adam Roach wrote: > >> Based on the conversations we've had so far, I've put together the > >> following summary of my thoughts on the topic of whether we want to > >> put multiple media streams in a single m= line. > >> > >> http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt > >> > >> Sorry for the relatively short lead time before next week's meeting > >> -- I had meant to put this kind of summary together a week or two > >> ago, but have been far busier than I anticipated. > >> > >> /a > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Tue Feb 5 11:44:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AD421F8523 for ; Tue, 5 Feb 2013 11:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=3.010, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaBOOWMzjVfF for ; Tue, 5 Feb 2013 11:43:59 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94B21F84F2 for ; Tue, 5 Feb 2013 11:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5818; q=dns/txt; s=iport; t=1360093439; x=1361303039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xx/M3nn3NzJty4hy++PydEMn5u7KRGFNaRE3EpcAqhA=; b=cmoLgFuQkTzczjGrQMGKdIQSJ3GSnW9+KJ44RIQP3ljtd8pVkS6EWpwr 9qs0eEfC/WjXqBCDyiZC9UsALn0aj1YUhJQLB8i/YvCF9t/azoLEgtTWv cJJl26ZrIBUsLdxOT/JkwMhFBv5W6QTWgB53vl6bJ4d8roejNsv8Pe4dY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKxgEVGtJV2a/2dsb2JhbABFv2IWc4IfAQEBBAEBATcuBgsMBAIBCA4DBAEBAQoUCQchBgsUCQgCBAENBQgTh2QDDwyqW4ZFDYlSBIwWgQ6DVmEDlEmNF4UTgn6CJA X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173677655" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2013 19:43:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r15JhwcJ010817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 19:43:58 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.207]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 13:43:58 -0600 From: "Charles Eckel (eckelcu)" To: Roni Even , "'Adam Roach'" , "'Justin Uberti'" Thread-Topic: [MMUSIC] More thoughts on multiple media streams in a single m= line Thread-Index: AQHOAqu2LYA/ph/xo0SCEOgM5p8WMphryWKA//+mRaCAAIQzgP//qkoQ Date: Tue, 5 Feb 2013 19:43:57 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280477EBCB@xmb-aln-x08.cisco.com> References: <5111247B.8060904@nostrum.com> <92B7E61ADAC1BB4F941F943788C088280477E994@xmb-aln-x08.cisco.com> <042e01ce03ca$503af000$f0b0d000$@gmail.com> In-Reply-To: <042e01ce03ca$503af000$f0b0d000$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:44:00 -0000 True, max-ssrc or something that provides similar functionality, would be u= seful in all three. Cheers, Charles > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, February 05, 2013 12:58 PM > To: Charles Eckel (eckelcu); 'Adam Roach'; 'Justin Uberti' > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] More thoughts on multiple media streams in a single > m=3D line >=20 > Charles, > Even for 1 you need maxssrc, you assume that one m-line means one RTP > stream. > Roni >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of > Charles Eckel (eckelcu) > Sent: 05 February, 2013 6:20 PM > To: Adam Roach; Justin Uberti > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single > m=3D > line >=20 > I think we are all in agreement that for a large conference (e.g. 100+ > audio/video streams), we cannot require that each media stream have its > own > m=3Dsection, nor can we require that each media stream's SSRC is signaled= in > SDP. For the sake of example, let's assume a centralized conference serve= r > is able to send up to 10 video streams, where each video stream may be an= y > of the 100 video streams at various points in time (e.g. active speakers > switched in/out, specific sources requested, etc.), I think there are thr= ee > realistic alternatives: >=20 > 1) Use 10 m=3Dsections to define the ten video streams, no multiplexing > required > 2) Use 1 m=3Dsection to define a video stream, and indicate that up to 1= 0 > video streams are multiplexed within it > 3) Use 'n' m=3Dsections to define the video streams, where 1<=3Dn<=3D10 >=20 > We already have all we need to do (1). There is a desire to improve on (1= ). > If we define some additional syntax/semantics that enable (2), people can > choose to use (2) or (3) depending on works best for their scenario. Ther= e > have already been some drafts submitted along these lines, I suggest to > take > a closer look at those and improve on them. Sounds reasonable? >=20 > Charles >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Adam Roach > > Sent: Tuesday, February 05, 2013 10:26 AM > > To: Justin Uberti > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] More thoughts on multiple media streams in a > > single m=3D line > > > > On 2/4/13 02:45, Justin Uberti wrote: > > > > > > Sorry for the short lead time, but here's a quick read for the > plane. > > > > > > I addressed several of the assertions made in this draft in my > > previous response (e.g. the need for glare resolution regardless of > > which solution we select). Some additional thoughts: > > > > > > > > o Adding or removing a source requires sending a full list of > all > > sources, which doesn't scale well to 10s or 100s of sources, > > especially when they are added or removed frequently. > > > > > > Realistically, this isn't how multiparty conferences are handled. It's > > unrealistic to think that my DSL connection is going to be sucking > > down hundreds of video streams just because I'm in a video conference > > with hundreds of people. > > > > In practice, the way existing conferencing systems handle this is to > > send a small, manageable number of streams to each participant, > > changing them out as necessary to have a reasonable user experience > > (either under the control of the user, its own algorithms, or a > combination of the two). > > > > Which is to say: even with hundreds of source streams being fed into a > > conference system, you're really looking at a realistic upper bound on > > m=3D sections of a dozen or two, simply because you can't reasonably > > expect recipients to receive more than that many streams simultaneously= . > > > > And really, if you're imagining hundreds of media streams flowing > > towards an endpoint, any arguments about the bits consumed by SDP go > > well beyond disingenuous. > > > > > > > > o Because this solution requires BUNDLE, which is still not > widely > > supported, it can be deployed in fewer situations > > > > > > This is completely out of left field: the alternative is MMT, which is > > even less well developed than BUNDLE. > > > > > > > > 4. The RFC5576-based approach has already been in use for many > > years > > in a major video conferencing system (Google+ Hangouts), and > > has > > worked very well. We feel that we have searched the > "unknown" > > space and solved all of the major issues. > > > > > > I think this actually does a good job of illustrating your blind spot: > > you're working within RTCWEB, but developing for a single, very precise > use case. > > For example, this kind of experience doesn't translate well into the > > challenges that might arise from systems that are dealing with > > radically different user experiences. Google-hangout-type uses are > > certainly important, but they're not the only thing we're designing > > for. You need to think about systems with pre-encoded (stored) media; > > systems with radical imbalances in the processing power and device > > capabilities between the endpoints; systems with different stream contr= ol > models, etc, etc. > > > > > > > > On the other hand, the multi m=3D > > section approach has never been tried by anyone, that we are > > aware of > > > > > > Do a web search for "Marconi ViPr." > > > > /a >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Tue Feb 5 20:28:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA021F8996; Tue, 5 Feb 2013 20:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4rhROcnBylN; Tue, 5 Feb 2013 20:28:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A221F8988; Tue, 5 Feb 2013 20:28:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDF4539E130; Wed, 6 Feb 2013 05:28:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw+-W7JA5fiO; Wed, 6 Feb 2013 05:28:32 +0100 (CET) Received: from [192.168.5.247] (216-206-165-162.dia.static.qwest.net [216.206.165.162]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A6EDF39E0C8; Wed, 6 Feb 2013 05:28:31 +0100 (CET) Message-ID: <5111DBEE.20501@alvestrand.no> Date: Wed, 06 Feb 2013 05:28:30 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------030404010108030502030206" Subject: [MMUSIC] The 171-attribute spreadsheet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 04:28:36 -0000 This is a multi-part message in MIME format. --------------030404010108030502030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just in case anyone else lost the link, the spreadsheet with all defined SDP attributes that an m-line can have is here: https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0 Everyone with the link should be able to edit. Harald --------------030404010108030502030206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just in case anyone else lost the link, the spreadsheet with all defined SDP attributes that an m-line can have is here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0

Everyone with the link should be able to edit.

            Harald

--------------030404010108030502030206-- From ari.keranen@ericsson.com Wed Feb 6 08:58:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDB21F855D; Wed, 6 Feb 2013 08:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyUQF91MIY+p; Wed, 6 Feb 2013 08:58:36 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 367F321F8569; Wed, 6 Feb 2013 08:58:36 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-93-51128bbaf91c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.BB.19728.ABB82115; Wed, 6 Feb 2013 17:58:35 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Feb 2013 17:58:34 +0100 Received: from As-MacBook-Air.local (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 450B5233F; Wed, 6 Feb 2013 18:58:33 +0200 (EET) Message-ID: <51128BB8.3080808@ericsson.com> Date: Wed, 6 Feb 2013 11:58:32 -0500 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> In-Reply-To: <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvre7ubqFAgwXvOCz+7U2ymLr8MYvF 33Zmizm7HjBZrP3Xzu7A6rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoErY+KcLtaC mRIVzc2z2RoY3wl3MXJySAiYSEyZ+p8RwhaTuHBvPVsXIxeHkMBJRokHuycxQTjrGSWar1xi hHC2MEp0dE9l72Lk4OAV0Ja4NNcJpJtFQEXiRsMlJhCbTcBe4uaE6+wgtqhAskTbrYMsIDav gKDEyZlPwGwRATWJ12s/s4HYzEA1D7d+BOsVBhq5eF4T2EVCAuESe7r7wGo4BSwk1s6bwAJR bytxYc51KFteYvvbOcwQ9aoSV/+9YpzAKDQLybpZSFpmIWlZwMi8ipE9NzEzJ73caBMjMKAP bvmtuoPxzjmRQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDOL5qZ/O5z ytS3Xrf/h58IDSn6/TfzQouhiOmUBytrbPur7+kY70lvvNrAkmXw1HHqp0nW5QvmPV9W/sDO PlT+dd5bnbv/bN523EnKXvtr8QqW9sk1ar/PmhY37ml3mPuluMh04ROde82qgg9sJv0zXPqG pWLJguM7Tb6s3f73nLh3k+062SJXJZbijERDLeai4kQAPiX2ITYCAAA= Cc: mmusic-chairs@tools.ietf.org, rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:58:37 -0000 Hi, The agenda is (roughly) still as shown below. The afternoon sessions (RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material (including chair slides with updated agenda) is available here: http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html Cheers, Ari On 2/4/13 11:53 AM, Roni Even wrote: > Hi, > Is there a final agenda with time schedule. There is no relation between the > agenda here and i=the one for mmusic and rtcweb in the reference. > I would like to attend from remote and since there is time difference it > will be helpful to plan ahead. > Thanks > Roni Even who will try to attend from remote being 7 hours ahead of Boston > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Stefan H?kansson LK > Sent: 30 January, 2013 11:51 AM > To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org; > public-media-capture@w3.org > Subject: [rtcweb] Boston meeting agenda > > All, > > below is a merged agenda covering both W3C and IETF parts of the meeting. > Details are likely to change - the main message is that W3C meetings will be > before lunch, and IETF after. Before lunch could mean > 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A hard > stop is planned for 17:00 on Feb 7th as many have planes to catch. > > (The sources used to assemble the agenda below are the W3C meeting wiki's, > [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). > > --Stefan (for all involved chairs) > > Feb 5th > ======= > Morning session: W3C Media Capture TF > ------------------------------------- > * device enumeration > * error handling > * "immediate stream" gUM > * Resource reservation > > Afternoon session: IETF mmusic and rtcweb WGs > --------------------------------------------- > * Multiple Flow SDP representation > * SDP for Data channels > > Feb 6th > ======= > Morning session: W3C Media Capture TF + WebRTC WG > ------------------------------------------------- > * Identity aspects of MediaStreams (MediaCap) > * Settings/constraints (MediaCap) > * Recording (MediaCap) > * Call flow (WebRTC) > > Afternoon session: IETF mmusic and rtcweb WGs > --------------------------------------------- > * SDP Grouping (Bundle/MMT/one-rtp) > * Mapping stream/track label concepts to SDP identifiers > > Feb 7th > ======= > Morning session: W3C WebRTC WG > ------------------------------ > * MediaStream and MediaStreamTrack - SDP interface > * Error handling > * Data channel > * Stats > > Afternoon session: IETF mmusic and rtcweb WGs > --------------------------------------------- > * Trickle ICE > * JSEP > > [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 > [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 > [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From keith.drage@alcatel-lucent.com Wed Feb 6 13:52:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AD321F856E; Wed, 6 Feb 2013 13:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.989 X-Spam-Level: X-Spam-Status: No, score=-106.989 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkH9wk-xKYtK; Wed, 6 Feb 2013 13:52:23 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id D44B521F855F; Wed, 6 Feb 2013 13:52:22 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r16Lq8Kn006161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Feb 2013 22:52:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Feb 2013 22:52:06 +0100 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , mmusic , "rtcweb@ietf.org" Date: Wed, 6 Feb 2013 22:51:57 +0100 Thread-Topic: [rtcweb] The 171-attribute spreadsheet Thread-Index: Ac4EInPfiio0UcNGTq+Gcc59EyknewAkIWzw Message-ID: References: <5111DBEE.20501@alvestrand.no> In-Reply-To: <5111DBEE.20501@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [MMUSIC] [rtcweb] The 171-attribute spreadsheet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 21:52:24 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is still missing any criteria for deciding whether something is in or = out. I assume importance to RTCWEB has only two values from what I can see = (1 =3D important, 0 =3D not important). I believe I could make a use case f= or all of these being supported, I'm sure all of them can be found in SDP w= hen interworking - the question is whether any of these cases are useful to= applications or not, and whether an otherwise successful communication wou= ld fail if an attribute was not understood, and therefore dropped. I can solve the problem of g.3gpp.cat and g.3gpp.crs for you. These are mis= registrations and are in fact values of the content attribute (which is mis= sing from your list because it has only just been inserted as a correction,= and probably is important to RTCWEB). It is in the process of being sorted= but requires some changes to the registration data in the references speci= fication to make things clear. Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 06 February 2013 04:29 To: mmusic; rtcweb@ietf.org Subject: [rtcweb] The 171-attribute spreadsheet Just in case anyone else lost the link, the spreadsheet with all defined SD= P attributes that an m-line can have is here: https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG= NV9lUFI3cHlIRFE#gid=3D0 Everyone with the link should be able to edit. Harald --_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is still missing any criteria for deciding whether something is in or out. I assume importance to RTCWEB has = only two values from what I can see (1 =3D important, 0 =3D not important). I be= lieve I could make a use case for all of these being supported, I’m sure all = of them can be found in SDP when interworking – the question is whether = any of these cases are useful to applications or not, and whether an otherwise successful communication would fail if an attribute was not understood, and therefore dropped.

 

I can solve the problem of g.3gpp.cat = and g.3gpp.crs for you. These are misregistrations and are in fact values of th= e content attribute (which is missing from your list because it has only just been inserted as a correction, and probably is important to RTCWEB). It is = in the process of being sorted but requires some changes to the registration d= ata in the references specification to make things clear.

 

Keith

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beh= alf Of Harald Alvestrand
Sent: 06 February 2013 04:29=
To: mmusic; rtcweb@ietf.org<= br> Subject: [rtcweb] The 171-attribute spreadsheet

=  

Just in case anyo= ne else lost the link, the spreadsheet with all defined SDP attributes that an m-li= ne can have is here:

https://docs.google.com/spreadsheet/ccc?ke= y=3D0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=3D0

Everyone with the link should be able to edit.

            Harald

--_000_EDC0A1AE77C57744B664A310A0B23AE20D97134B8BFRMRSSXCHMBSC_-- From tterriberry@mozilla.com Wed Feb 6 14:42:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919221E8041; Wed, 6 Feb 2013 14:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryq-PtAvTkP8; Wed, 6 Feb 2013 14:42:36 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 95B0821F8526; Wed, 6 Feb 2013 14:42:36 -0800 (PST) Received: from [192.168.2.33] (static-155-212-214-60.mas.onecommunications.net [155.212.214.60]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 22F20F218D; Wed, 6 Feb 2013 14:42:38 -0800 (PST) Message-ID: <5112DC51.30604@mozilla.com> Date: Wed, 06 Feb 2013 14:42:25 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Minutes from 6 Feb joint interim session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 22:42:37 -0000 BUNDLE, ONE-RTP, MMT: * Note - If we proceed with MMT, we should use m=application instead of m=anymedia * Decision - Are you generally okay with any of the approaches that reduce the number of long-lived flows to this level OR is there some other feature in one of the proposals you must have before this meets your needs? 6 for the former, 17 for the latter Cullen's plan to dig us out of this hole: * Proposed Superset of Requirement 2 - Should be able to interop with legacy without the JS doing anything special. * Proposed Relaxation of Requirement 2 - Should be able to interop with legacy, but not necessarily in one O/A exchange within a single dialog (without relying on failure cases). * Requirement 3 - Change video flows to media flows * Proposed Requirement - When we have a large conference with 1000's of people, we don't have to send new signaling to every participant of the conference. * Proposed Requirement - Must be able to configure a set of similar flows such that once established, the endpoints can add or remove flows without having to do an O/A cycle (i.e., without having to exchange SDP). * Proposed Requirement - Have this process terminate in some finite period of time. * Point of Discussion - Plan A: same port on each m-line or different candidate sets? * Action - Plan B: Write the drafts to extend SDP to explicitly describe multiple cameras with multiple streams from each camera under a single m-line. * Decision - Should we come up with a set of requirements and proceed with Plan A and Plan B with the timelines outlined here? 24 for, 5 against * Note - Mary Barnes refuses to go back to work until she gets her mini candy bars. DataChannel SDP * Action - Justin to draft API for SDP-only channel open * Decision (rtcweb hats) - 2a) In-band only - 6 2b) SDP & in-band - 10 2c) SDP-only - 15 Work on both will continue until a decision is reached. * Action - Martin believes he can send a proposal to the list which will change some minds. From harald@alvestrand.no Wed Feb 6 19:16:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2021F84E9; Wed, 6 Feb 2013 19:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.856 X-Spam-Level: X-Spam-Status: No, score=-109.856 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SEca8ixin4U; Wed, 6 Feb 2013 19:16:25 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3921E8034; Wed, 6 Feb 2013 19:16:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2973A39E0CE; Thu, 7 Feb 2013 04:16:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u1A1ENzTJEO; Thu, 7 Feb 2013 04:16:20 +0100 (CET) Received: from [192.168.5.247] (216-206-165-162.dia.static.qwest.net [216.206.165.162]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 093E639E03A; Thu, 7 Feb 2013 04:16:19 +0100 (CET) Message-ID: <51131C81.9080303@alvestrand.no> Date: Thu, 07 Feb 2013 04:16:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <5111DBEE.20501@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050505070305080005020008" Cc: "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] The 171-attribute spreadsheet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 03:16:27 -0000 This is a multi-part message in MIME format. --------------050505070305080005020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/06/2013 10:51 PM, DRAGE, Keith (Keith) wrote: > > This is still missing any criteria for deciding whether something is > in or out. I assume importance to RTCWEB has only two values from what > I can see (1 = important, 0 = not important). I believe I could make a > use case for all of these being supported, I'm sure all of them can be > found in SDP when interworking -- the question is whether any of these > cases are useful to applications or not, and whether an otherwise > successful communication would fail if an attribute was not > understood, and therefore dropped. > I don't think "in" or "out" is what we're looking for. It's either Transport, Flow or Media - which gives us a basis for seeing how bigthe problem is: - under BUNDLE, there must be new rules for Transport ("pick first", "sum values", or "other processing") - under "two M-lines" and MMT, theFlow attributes need to be redefined to be per-SSRC, or we have to decide to ignore them - I think the Media ones are OK with either proposal, unless some usage of them depends on there being only one flow in an M-line, in which case they're really Flow, even though they're marking Media I put in only 1 and 0 for RTCWEB because I started in on the easy cases- if you feel a more graded scale is useful, please suggest values! > I can solve the problem of g.3gpp.cat and g.3gpp.crs for you. These > are misregistrations and are in fact values of the content attribute > (which is missing from your list because it has only just been > inserted as a correction, and probably is important to RTCWEB). It is > in the process of being sorted but requires some changes to the > registration data in the references specification to make things clear. > values of a=content? That's good to know about. Hope you can put notes on those in the "notes" columns! > Keith > > ------------------------------------------------------------------------ > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Harald Alvestrand > *Sent:* 06 February 2013 04:29 > *To:* mmusic; rtcweb@ietf.org > *Subject:* [rtcweb] The 171-attribute spreadsheet > > Just in case anyone else lost the link, the spreadsheet with all > defined SDP attributes that an m-line can have is here: > > https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0 > > Everyone with the link should be able to edit. > > Harald > --------------050505070305080005020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/06/2013 10:51 PM, DRAGE, Keith (Keith) wrote:

This is still missing any criteria for deciding whether something is in or out. I assume importance to RTCWEB has only two values from what I can see (1 = important, 0 = not important). I believe I could make a use case for all of these being supported, I’m sure all of them can be found in SDP when interworking – the question is whether any of these cases are useful to applications or not, and whether an otherwise successful communication would fail if an attribute was not understood, and therefore dropped.

I don't think "in" or "out" is what we're looking for.
It's either Transport, Flow or Media - which gives us a basis for seeing how big the problem is:

- under BUNDLE, there must be new rules for Transport ("pick first", "sum values", or "other processing")
- under "two M-lines" and MMT, the Flow attributes need to be redefined to be per-SSRC, or we have to decide to ignore them
- I think the Media ones are OK with either proposal, unless some usage of them depends on there being only one flow in an M-line, in which case they're really Flow, even though they're marking Media

I put in only 1 and 0 for RTCWEB because I started in on the easy cases - if you feel a more graded scale is useful, please suggest values!

 

I can solve the problem of g.3gpp.cat and g.3gpp.crs for you. These are misregistrations and are in fact values of the content attribute (which is missing from your list because it has only just been inserted as a correction, and probably is important to RTCWEB). It is in the process of being sorted but requires some changes to the registration data in the references specification to make things clear.

values of a=content? That's good to know about. Hope you can put notes on those in the "notes" columns!

 

Keith

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 06 February 2013 04:29
To: mmusic; rtcweb@ietf.org
Subject: [rtcweb] The 171-attribute spreadsheet

 

Just in case anyone else lost the link, the spreadsheet with all defined SDP attributes that an m-line can have is here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE#gid=0

Everyone with the link should be able to edit.

            Harald


--------------050505070305080005020008-- From mperumal@cisco.com Wed Feb 6 22:22:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE721F841D; Wed, 6 Feb 2013 22:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y1cOvEa54Ih; Wed, 6 Feb 2013 22:22:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 034A121F841E; Wed, 6 Feb 2013 22:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3839; q=dns/txt; s=iport; t=1360218148; x=1361427748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gLx8ix6/2pPQE8eSrFfbvnRPgzheiF6Ym0zE9WeFTI0=; b=ITq9fLxJRUshlA72spbBKEdoJonwqKMLZIyz7bvhqU+U6BFdQccxwiM5 v4p4x1CxSCzlrv+W7/QRCoxPas3oM8ak9LEcfcyYY4SqMZPVqXc9X8Dvj RIjiEe23xh4WqrIX/Xu8Ll6S34RqXtNGuRkEV83Al/tsK4n3FyqJ4B2hQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKxHE1GtJXHA/2dsb2JhbAA8CcBQFnOCHwEBAQQBAQFrBAcMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAGICAy8c40YCYNXYQOIMJ5Dgn6BbzU X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="scan'208";a="174333883" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2013 06:22:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r176MQ6o021814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 06:22:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 00:22:26 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , Roni Even Thread-Topic: [MMUSIC] [rtcweb] Boston meeting agenda Thread-Index: AQHOBIs4IjrUXcS7SkKVAgPQPh30C5ht7QJw Date: Thu, 7 Feb 2013 06:22:26 +0000 Message-ID: References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com> In-Reply-To: <51128BB8.3080808@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 06:22:29 -0000 Are we recording these sessions? Will someone be sharing the URLs for the r= ecording? Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f Ari Ker=E4nen |Sent: Wednesday, February 06, 2013 10:29 PM |To: Roni Even |Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.iet= f.org; mmusic@ietf.org |Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda | |Hi, | |The agenda is (roughly) still as shown below. The afternoon sessions |(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material |(including chair slides with updated agenda) is available here: |http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.html | | |Cheers, |Ari | |On 2/4/13 11:53 AM, Roni Even wrote: |> Hi, |> Is there a final agenda with time schedule. There is no relation between= the |> agenda here and i=3Dthe one for mmusic and rtcweb in the reference. |> I would like to attend from remote and since there is time difference it |> will be helpful to plan ahead. |> Thanks |> Roni Even who will try to attend from remote being 7 hours ahead of Bost= on |> |> -----Original Message----- |> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of |> Stefan H?kansson LK |> Sent: 30 January, 2013 11:51 AM |> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org; |> public-media-capture@w3.org |> Subject: [rtcweb] Boston meeting agenda |> |> All, |> |> below is a merged agenda covering both W3C and IETF parts of the meeting= . |> Details are likely to change - the main message is that W3C meetings wil= l be |> before lunch, and IETF after. Before lunch could mean |> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. A = hard |> stop is planned for 17:00 on Feb 7th as many have planes to catch. |> |> (The sources used to assemble the agenda below are the W3C meeting wiki'= s, |> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). |> |> --Stefan (for all involved chairs) |> |> Feb 5th |> =3D=3D=3D=3D=3D=3D=3D |> Morning session: W3C Media Capture TF |> ------------------------------------- |> * device enumeration |> * error handling |> * "immediate stream" gUM |> * Resource reservation |> |> Afternoon session: IETF mmusic and rtcweb WGs |> --------------------------------------------- |> * Multiple Flow SDP representation |> * SDP for Data channels |> |> Feb 6th |> =3D=3D=3D=3D=3D=3D=3D |> Morning session: W3C Media Capture TF + WebRTC WG |> ------------------------------------------------- |> * Identity aspects of MediaStreams (MediaCap) |> * Settings/constraints (MediaCap) |> * Recording (MediaCap) |> * Call flow (WebRTC) |> |> Afternoon session: IETF mmusic and rtcweb WGs |> --------------------------------------------- |> * SDP Grouping (Bundle/MMT/one-rtp) |> * Mapping stream/track label concepts to SDP identifiers |> |> Feb 7th |> =3D=3D=3D=3D=3D=3D=3D |> Morning session: W3C WebRTC WG |> ------------------------------ |> * MediaStream and MediaStreamTrack - SDP interface |> * Error handling |> * Data channel |> * Stats |> |> Afternoon session: IETF mmusic and rtcweb WGs |> --------------------------------------------- |> * Trickle ICE |> * JSEP |> |> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 |> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 |> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html |> |> |> |> |> _______________________________________________ |> rtcweb mailing list |> rtcweb@ietf.org |> https://www.ietf.org/mailman/listinfo/rtcweb |> | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Thu Feb 7 04:44:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B721F854C; Thu, 7 Feb 2013 04:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNHe9ehrul2t; Thu, 7 Feb 2013 04:44:51 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3114621F853E; Thu, 7 Feb 2013 04:44:51 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so1364178eek.27 for ; Thu, 07 Feb 2013 04:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Tb0Lx49RK8Wx6RF6KTBTSGm1+MNYJkuRpzrTGkwqDV8=; b=cMfmPnf35tM5qrgHhjRHNzMyj9JVF2Swf4Npd7mb1cxJfLD2UYM0a4C7VnSJsSbnKx IxTWllOZztDhVi6ESwGKQ1xVaMlTcfnrGlLHzmgd/FixUQ3O6TwF23sMhxGxSotyGq+w 5RBE2jbn2s6eZFWeO9XJ6pGTTLEHfZ9wzeUEXPp/HjxDKgDQopqNX/5Zu6bU1dPFKvrC 3AE55VoEg4CZO57bL6C6ZnkWk1MhZAdJIH26FySzEmFr4c6uDJwz5JyvO5txeFLKsf4g IQpKfm5LgPfh3RhD4VifG1JUO6AC0wEbZDJK0Esx02pqRudQP5+st+dsHUT0ycYchHD1 BUKQ== X-Received: by 10.14.174.197 with SMTP id x45mr3946686eel.5.1360241090041; Thu, 07 Feb 2013 04:44:50 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id t4sm41902252eel.0.2013.02.07.04.44.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Feb 2013 04:44:48 -0800 (PST) From: "Roni Even" To: "'Timothy B. Terriberry'" , , References: <5112DC51.30604@mozilla.com> In-Reply-To: <5112DC51.30604@mozilla.com> Date: Thu, 7 Feb 2013 14:41:43 +0200 Message-ID: <056601ce0530$84f99000$8eecb000$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQGNAesojb2nU8D/T/W2cOyhIBJiDZjwXAgg Content-Language: en-us Subject: Re: [MMUSIC] Minutes from 6 Feb joint interim session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:44:52 -0000 Hi, On Action - Plan B: Write the drafts to extend SDP to explicitly describe multiple cameras with multiple streams from each camera under a single m-line. We did it in CLUE look at http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 examples is section 6.1 and 6.2. (6.2 was taken out in the 05 version since we agreed in CLUE that simulcast is out of scope for CLUE) Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Timothy B. Terriberry Sent: 07 February, 2013 12:42 AM To: rtcweb@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Minutes from 6 Feb joint interim session BUNDLE, ONE-RTP, MMT: * Note - If we proceed with MMT, we should use m=application instead of m=anymedia * Decision - Are you generally okay with any of the approaches that reduce the number of long-lived flows to this level OR is there some other feature in one of the proposals you must have before this meets your needs? 6 for the former, 17 for the latter Cullen's plan to dig us out of this hole: * Proposed Superset of Requirement 2 - Should be able to interop with legacy without the JS doing anything special. * Proposed Relaxation of Requirement 2 - Should be able to interop with legacy, but not necessarily in one O/A exchange within a single dialog (without relying on failure cases). * Requirement 3 - Change video flows to media flows * Proposed Requirement - When we have a large conference with 1000's of people, we don't have to send new signaling to every participant of the conference. * Proposed Requirement - Must be able to configure a set of similar flows such that once established, the endpoints can add or remove flows without having to do an O/A cycle (i.e., without having to exchange SDP). * Proposed Requirement - Have this process terminate in some finite period of time. * Point of Discussion - Plan A: same port on each m-line or different candidate sets? * Action - Plan B: Write the drafts to extend SDP to explicitly describe multiple cameras with multiple streams from each camera under a single m-line. * Decision - Should we come up with a set of requirements and proceed with Plan A and Plan B with the timelines outlined here? 24 for, 5 against * Note - Mary Barnes refuses to go back to work until she gets her mini candy bars. DataChannel SDP * Action - Justin to draft API for SDP-only channel open * Decision (rtcweb hats) - 2a) In-band only - 6 2b) SDP & in-band - 10 2c) SDP-only - 15 Work on both will continue until a decision is reached. * Action - Martin believes he can send a proposal to the list which will change some minds. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mary.ietf.barnes@gmail.com Thu Feb 7 06:01:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7340B21F86AF; Thu, 7 Feb 2013 06:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103 X-Spam-Level: X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNvNZc10qLvX; Thu, 7 Feb 2013 06:01:50 -0800 (PST) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E521F866D; Thu, 7 Feb 2013 06:01:50 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id 1so1195459qeb.13 for ; Thu, 07 Feb 2013 06:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jluss0Hq53aD8TzghcCwvlYqxWMrGoCUdHmkGFPliLo=; b=RMEZvx4Ay7desktp17uY1axmiI2qLhK2vhPCdpX4nzwDyrxKbRnxE3pOp44sNnJW7q 7aJ2vh1SeECFK1M10fsSfdNz4hRmkZGb6p6ZDZ2vY55Dv+wQ6XKeyn9ZA0O4ipcYR6pn ZkT3ITlBXcq9aSJfXWR1aEphwaYoyVWYVonWqr6tf5FZUMcmTnwYwYUuHOHUFIbY/cT/ XdY0W6/BEZv4RpdHflXICkBa09+Ida33JHUZf/LAJk9u6fdwlojzk2jYMtiWwHHIbY7I t4k/UyqEDdXqzyUB+gprS5ntd9q8NrJer4gH0j9VbgaLhrNl35FttvP40mmPfv/5RFJ1 V4ww== MIME-Version: 1.0 X-Received: by 10.49.72.136 with SMTP id d8mr588017qev.62.1360245709612; Thu, 07 Feb 2013 06:01:49 -0800 (PST) Received: by 10.49.131.199 with HTTP; Thu, 7 Feb 2013 06:01:49 -0800 (PST) In-Reply-To: <1.94dc0188bed96e22f168@cisco.com> References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com> <1.94dc0188bed96e22f168@cisco.com> Date: Thu, 7 Feb 2013 08:01:49 -0600 Message-ID: From: Mary Barnes To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , "rtcweb-chairs@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:01:51 -0000 The intent was to record the Webex sessions, thus a link to the recordings should be posted in the meeting minutes. However, the recording for the Feb. 6th session yesterday wasn't started until partway into the session so there will be a gap. Hopefully, someone will remember to start the recording at the beginning of the session tomorrow. Mary. On Thu, Feb 7, 2013 at 12:22 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > Are we recording these sessions? Will someone be sharing the URLs for the > recording? > > Muthu > > |-----Original Message----- > |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of > Ari Ker=E4nen > |Sent: Wednesday, February 06, 2013 10:29 PM > |To: Roni Even > |Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; > rtcweb-chairs@tools.ietf.org; mmusic@ietf.org > |Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda > | > |Hi, > | > |The agenda is (roughly) still as shown below. The afternoon sessions > |(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material > |(including chair slides with updated agenda) is available here: > |http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.ht= ml > | > | > |Cheers, > |Ari > | > |On 2/4/13 11:53 AM, Roni Even wrote: > |> Hi, > |> Is there a final agenda with time schedule. There is no relation betwe= en > the > |> agenda here and i=3Dthe one for mmusic and rtcweb in the reference. > |> I would like to attend from remote and since there is time difference = it > |> will be helpful to plan ahead. > |> Thanks > |> Roni Even who will try to attend from remote being 7 hours ahead of > Boston > |> > |> -----Original Message----- > |> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beha= lf > Of > |> Stefan H?kansson LK > |> Sent: 30 January, 2013 11:51 AM > |> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org; > |> public-media-capture@w3.org > |> Subject: [rtcweb] Boston meeting agenda > |> > |> All, > |> > |> below is a merged agenda covering both W3C and IETF parts of the meeti= ng. > |> Details are likely to change - the main message is that W3C meetings w= ill > be > |> before lunch, and IETF after. Before lunch could mean > |> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC. = A > hard > |> stop is planned for 17:00 on Feb 7th as many have planes to catch. > |> > |> (The sources used to assemble the agenda below are the W3C meeting > wiki's, > |> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). > |> > |> --Stefan (for all involved chairs) > |> > |> Feb 5th > |> =3D=3D=3D=3D=3D=3D=3D > |> Morning session: W3C Media Capture TF > |> ------------------------------------- > |> * device enumeration > |> * error handling > |> * "immediate stream" gUM > |> * Resource reservation > |> > |> Afternoon session: IETF mmusic and rtcweb WGs > |> --------------------------------------------- > |> * Multiple Flow SDP representation > |> * SDP for Data channels > |> > |> Feb 6th > |> =3D=3D=3D=3D=3D=3D=3D > |> Morning session: W3C Media Capture TF + WebRTC WG > |> ------------------------------------------------- > |> * Identity aspects of MediaStreams (MediaCap) > |> * Settings/constraints (MediaCap) > |> * Recording (MediaCap) > |> * Call flow (WebRTC) > |> > |> Afternoon session: IETF mmusic and rtcweb WGs > |> --------------------------------------------- > |> * SDP Grouping (Bundle/MMT/one-rtp) > |> * Mapping stream/track label concepts to SDP identifiers > |> > |> Feb 7th > |> =3D=3D=3D=3D=3D=3D=3D > |> Morning session: W3C WebRTC WG > |> ------------------------------ > |> * MediaStream and MediaStreamTrack - SDP interface > |> * Error handling > |> * Data channel > |> * Stats > |> > |> Afternoon session: IETF mmusic and rtcweb WGs > |> --------------------------------------------- > |> * Trickle ICE > |> * JSEP > |> > |> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 > |> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_2013 > |> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html > |> > |> > |> > |> > |> _______________________________________________ > |> rtcweb mailing list > |> rtcweb@ietf.org > |> https://www.ietf.org/mailman/listinfo/rtcweb > |> > | > |_______________________________________________ > |mmusic mailing list > |mmusic@ietf.org > |https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Thu Feb 7 06:06:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FCF21F8645; Thu, 7 Feb 2013 06:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnhaOw0I1vSh; Thu, 7 Feb 2013 06:06:03 -0800 (PST) Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0130A21F85F0; Thu, 7 Feb 2013 06:06:02 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id 9so3499489iec.32 for ; Thu, 07 Feb 2013 06:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=opjvC8wEZFadF52yVzIvlET48bmJH12o84TK7He6V04=; b=o9DDDaWVipTBvk7sx8s8tlgIT0pUPMfEDL992J38tJ6gvky6rvqLKMbIb/QxGFLNRj QjDqNwq2KfqLmzASAYHAqZH5WIBYmk7gjEDgOq0JaLPkIOosD1PkeFS7BYTcL41217MQ Hkusq2HuXJk5eDeSw5UG2BQ+AenI5lEPmAkYga7a9l0b7VOnBhT4vEapUDl8cb7KVuNW WJyA5cONS/ChRbPmbDXewVfdngjCqSDawKwm0W8dpjtMa0KOb5shn/4b2kZoHUcj3vI+ F2jDv6ZxdHMyq4CZoVlqK9At+wD9e2MA+cRDtplTsvGy7voXU/49Cqp05oH3cVelg5K5 uZMQ== MIME-Version: 1.0 X-Received: by 10.50.194.134 with SMTP id hw6mr3128073igc.20.1360245962420; Thu, 07 Feb 2013 06:06:02 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 06:06:02 -0800 (PST) In-Reply-To: References: <5108ED00.9090605@ericsson.com> <03a301ce02f8$2f71dfa0$8e559ee0$@gmail.com> <51128BB8.3080808@ericsson.com> <1.94dc0188bed96e22f168@cisco.com> Date: Thu, 7 Feb 2013 09:06:02 -0500 Message-ID: From: Ted Hardie To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , "rtcweb-chairs@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:06:03 -0000 On Thu, Feb 7, 2013 at 9:01 AM, Mary Barnes wr= ote: > The intent was to record the Webex sessions, thus a link to the > recordings should be posted in the meeting minutes. However, the > recording for the Feb. 6th session yesterday wasn't started until > partway into the session so there will be a gap. Hopefully, someone > will remember to start the recording at the beginning of the session > tomorrow. Apologies for missing the recording yesterday; we will try to do better today. Nagging from those in the room would be welcome. Ted > > Mary. > > On Thu, Feb 7, 2013 at 12:22 AM, Muthu Arul Mozhi Perumal (mperumal) > wrote: >> Are we recording these sessions? Will someone be sharing the URLs for th= e >> recording? >> >> Muthu >> >> |-----Original Message----- >> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f Of >> Ari Ker=E4nen >> |Sent: Wednesday, February 06, 2013 10:29 PM >> |To: Roni Even >> |Cc: mmusic-chairs@tools.ietf.org; rtcweb@ietf.org; >> rtcweb-chairs@tools.ietf.org; mmusic@ietf.org >> |Subject: Re: [MMUSIC] [rtcweb] Boston meeting agenda >> | >> |Hi, >> | >> |The agenda is (roughly) still as shown below. The afternoon sessions >> |(RTCWEB/MMUSIC parts) start at 1:30 PM EST. The meeting material >> |(including chair slides with updated agenda) is available here: >> |http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/proceedings.h= tml >> | >> | >> |Cheers, >> |Ari >> | >> |On 2/4/13 11:53 AM, Roni Even wrote: >> |> Hi, >> |> Is there a final agenda with time schedule. There is no relation betw= een >> the >> |> agenda here and i=3Dthe one for mmusic and rtcweb in the reference. >> |> I would like to attend from remote and since there is time difference= it >> |> will be helpful to plan ahead. >> |> Thanks >> |> Roni Even who will try to attend from remote being 7 hours ahead of >> Boston >> |> >> |> -----Original Message----- >> |> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beh= alf >> Of >> |> Stefan H?kansson LK >> |> Sent: 30 January, 2013 11:51 AM >> |> To: mmusic@ietf.org; rtcweb@ietf.org; public-webrtc@w3.org; >> |> public-media-capture@w3.org >> |> Subject: [rtcweb] Boston meeting agenda >> |> >> |> All, >> |> >> |> below is a merged agenda covering both W3C and IETF parts of the meet= ing. >> |> Details are likely to change - the main message is that W3C meetings = will >> be >> |> before lunch, and IETF after. Before lunch could mean >> |> 8:30 - 12:30, after lunch 13:30 - 17:30; but the exact times are TBC.= A >> hard >> |> stop is planned for 17:00 on Feb 7th as many have planes to catch. >> |> >> |> (The sources used to assemble the agenda below are the W3C meeting >> wiki's, >> |> [1][2], and the mail sent to mmusic and rtcweb Jan 14th [3]). >> |> >> |> --Stefan (for all involved chairs) >> |> >> |> Feb 5th >> |> =3D=3D=3D=3D=3D=3D=3D >> |> Morning session: W3C Media Capture TF >> |> ------------------------------------- >> |> * device enumeration >> |> * error handling >> |> * "immediate stream" gUM >> |> * Resource reservation >> |> >> |> Afternoon session: IETF mmusic and rtcweb WGs >> |> --------------------------------------------- >> |> * Multiple Flow SDP representation >> |> * SDP for Data channels >> |> >> |> Feb 6th >> |> =3D=3D=3D=3D=3D=3D=3D >> |> Morning session: W3C Media Capture TF + WebRTC WG >> |> ------------------------------------------------- >> |> * Identity aspects of MediaStreams (MediaCap) >> |> * Settings/constraints (MediaCap) >> |> * Recording (MediaCap) >> |> * Call flow (WebRTC) >> |> >> |> Afternoon session: IETF mmusic and rtcweb WGs >> |> --------------------------------------------- >> |> * SDP Grouping (Bundle/MMT/one-rtp) >> |> * Mapping stream/track label concepts to SDP identifiers >> |> >> |> Feb 7th >> |> =3D=3D=3D=3D=3D=3D=3D >> |> Morning session: W3C WebRTC WG >> |> ------------------------------ >> |> * MediaStream and MediaStreamTrack - SDP interface >> |> * Error handling >> |> * Data channel >> |> * Stats >> |> >> |> Afternoon session: IETF mmusic and rtcweb WGs >> |> --------------------------------------------- >> |> * Trickle ICE >> |> * JSEP >> |> >> |> [1] http://www.w3.org/wiki/Media_Capture/Feb_5-6_2013 >> |> [2] http://www.w3.org/2011/04/webrtc/wiki/February_6_-_February_7_201= 3 >> |> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06069.html >> |> >> |> >> |> >> |> >> |> _______________________________________________ >> |> rtcweb mailing list >> |> rtcweb@ietf.org >> |> https://www.ietf.org/mailman/listinfo/rtcweb >> |> >> | >> |_______________________________________________ >> |mmusic mailing list >> |mmusic@ietf.org >> |https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> From fandreas@cisco.com Thu Feb 7 07:00:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30321F84F2 for ; Thu, 7 Feb 2013 07:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY6JFjTrW2p6 for ; Thu, 7 Feb 2013 07:00:09 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC80421F84D5 for ; Thu, 7 Feb 2013 07:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12523; q=dns/txt; s=iport; t=1360249209; x=1361458809; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7XgA8784w7ubjNp3m3/qkHpfzdTB+xpoXYsGiKKHyBg=; b=kCrS2Z2qyzGjYZ4WWPw6EgZ/sJYrWcaQ59EDNVUxAulfCGIPJxJmrBTH KypUrEVjKeoNYusxdSa3wYpW7RX/2AcWvxd/3SipWWQmRSs5GpQv+lXPs hr9fMuCcGrjo+85Vjtgjk9SqjVJLQxho6sN/g9a9EvXimSi0EgmBXt+7m c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPi/E1GrRDoJ/2dsb2JhbABFjCS0QhZzgh8BAQEEAQEBawoBDAQZAwMBAgEJFg8JAwIBAgEVKAgGDQEFAgEBBYgHDb58kVwDiGaJSINzgR2PNYMe X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208,217";a="71269415" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 07 Feb 2013 15:00:09 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.247.193]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r17F07kI011841; Thu, 7 Feb 2013 15:00:07 GMT Message-ID: <5113C177.3000507@cisco.com> Date: Thu, 07 Feb 2013 10:00:07 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> In-Reply-To: <51094C89.7020302@jitsi.org> Content-Type: multipart/alternative; boundary="------------060104060608000709020806" Cc: MMUSIC IETF WG Subject: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:00:11 -0000 This is a multi-part message in MIME format. --------------060104060608000709020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I took a look the trickle-ice draft and have a couple of questions/comments: 1) Section 1 says This specification does not define usage of trickle ICE with any specific signalling protocol, contrary to [RFC5245] which contains a usage for ICE wht SIP. Such usages would have to be specified in separate documents. however you do define it specifically using SDP and Offer/Answer (I believe). It would be worthwhile calling that out. 2) Section 5.1 says As mentioned earlier in this section, Offers and Answers can contain any set of candidates, which means that a trickle ICE session description MAY contain no candidates at all. In such cases the agent would still need to place an address in the "c=" line(s). If the use of a host address there is undesirable (e.g. for privacy reasons), the agent MAY set the connection address to 0.0.0.0. In this case it MUST also set the port number to 1. There is no need to include a fictitious 0.0.0.0 candidate when doing so. I had to read this several times before I (think) I understood that when you say "the agent MAY set the connection address to 0.0.0.0", you are referring to the connection address in the "a=candidate" attribute, not the "c=" line. Can you clarify and rephrase accordingly. 3) Section 9.1 I'm confused about this whole section and it's premise that "a=candidate" attributes and media descriptions are not clearly linked. The "a=candidate" attribute is defined as a media-level attribute only and describes as such in RFC 5245, so I must be missing something here. 4) Section 9.2. Rather than talking about sending "end of candidates" via "the signalling channel" (which is not defined), could we change this to say and "end of candidates" need to be sent to the peer, and the only mechanism defined to do so in this document is through an O/A exchange (new exchange or answer to an offer) ? 5) Section 14 (Example) The exchange of the "additional candidates" does not use an O/A exchange. As for comment 4), this assumes some other un-defined mechanism somewhere - would it be useful to show it as an O/A exchange as well, but note that other mechanisms may be defined ? 6) Section A.1 (MID/Stream Indicates in SDP) I'm still unclear on this (per comment 3). Thanks -- Flemming (as Individual) On 1/30/13 11:38 AM, Emil Ivov wrote: > Hey all, > > Justin, Eric and I have just submitted an update to the trickle ICE > draft, accommodating comments from Atlanta: > > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 > > More details about the changes here: > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B > > Diff2: > http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 > > During the MMUSIC presentation and the mailing list discussions it was > also pointed out that it is important for this work to happen in > parallel with a SIP usage for trickle ICE. Enrico, Christer and I have > therefore submitted the following document: > > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 > > As always, comments are welcome! > > Cheers, > Emil > > -------- Original Message -------- > Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt > Date: Mon, 28 Jan 2013 11:39:21 -0800 > From: internet-drafts@ietf.org > To: emcho@jitsi.org > CC: justin@uberti.name, ekr@rtfm.com > > > A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt > has been successfully submitted by Emil Ivov and posted to the > IETF repository. > > Filename: draft-ivov-mmusic-trickle-ice > Revision: 00 > Title: Trickle ICE: Incremental Provisioning of Candidates for the > Interactive Connectivity Establishment (ICE) Protocol > Creation date: 2013-01-28 > WG ID: Individual Submission > Number of pages: 20 > URL: > http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt > Status: > http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice > Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 > > > Abstract: > This document describes an extension to the Interactive Connectivity > Establishment (ICE) protocol that allows ICE agents to send and > receive candidates incrementally rather than exchanging complete > lists. With such incremental provisioning, ICE agents can begin > connectivity checks while they are still gathering candidates and > considerably shorten the time necessary for ICE processing to > complete. > > The above mechanism is also referred to as "trickle ICE". > > > > > > The IETF Secretariat > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > --------------060104060608000709020806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I took a look the trickle-ice draft and have a couple of questions/comments:

1) Section 1 says
<quote>
   This specification does not define usage of trickle ICE with any
   specific signalling protocol, contrary to [RFC5245] which contains a
   usage for ICE wht SIP.  Such usages would have to be specified in
   separate documents.
</quote>
however you do define it specifically using SDP and Offer/Answer (I believe). It would be worthwhile calling that out.

2) Section 5.1 says
<quote>
   As mentioned earlier in this section, Offers and Answers can contain
   any set of candidates, which means that a trickle ICE session
   description MAY contain no candidates at all.  In such cases the
   agent would still need to place an address in the "c=" line(s).  If
   the use of a host address there is undesirable (e.g. for privacy
   reasons), the agent MAY set the connection address to 0.0.0.0.  In
   this case it MUST also set the port number to 1.  There is no need to
   include a fictitious 0.0.0.0 candidate when doing so.
<quote>
I had to read this several times before I (think) I understood that when you say "the agent MAY set the connection address to 0.0.0.0", you are referring to the connection address in the "a=candidate" attribute, not the "c=" line. Can you clarify and rephrase accordingly.

3) Section 9.1
I'm confused about this whole section and it's premise that "a=candidate" attributes and media descriptions are not clearly linked. The "a=candidate" attribute is defined as a media-level attribute only and describes as such in RFC 5245, so I must be missing something here.


4) Section 9.2. Rather than talking about sending "end of candidates" via "the signalling channel" (which is not defined), could we change this to say and "end of candidates" need to be sent to the peer, and the only mechanism defined to do so in this document is through an O/A exchange (new exchange or answer to an offer) ?

5) Section 14 (Example)
The exchange of the "additional candidates" does not use an O/A exchange. As for comment 4), this assumes some other un-defined mechanism somewhere - would it be useful to show it as an O/A exchange as well, but note that other mechanisms may be defined ?

6) Section A.1 (MID/Stream Indicates in SDP)
I'm still unclear on this (per comment 3).


Thanks

-- Flemming (as Individual)



On 1/30/13 11:38 AM, Emil Ivov wrote:
Hey all,

Justin, Eric and I have just submitted an update to the trickle ICE
draft, accommodating comments from Atlanta:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00

More details about the changes here:
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B

Diff2:
http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00

During the MMUSIC presentation and the mailing list discussions it was
also pointed out that it is important for this work to happen in
parallel with a SIP usage for trickle ICE. Enrico, Christer and I have
therefore submitted the following document:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00

As always, comments are welcome!

Cheers,
Emil

-------- Original Message --------
Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt
Date: Mon, 28 Jan 2013 11:39:21 -0800
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-ivov-mmusic-trickle-ice
Revision:	 00
Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:	 2013-01-28
WG ID:		 Individual Submission
Number of pages: 20
URL:
http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt
Status:
http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice
Htmlized:        http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00


Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat




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

--------------060104060608000709020806-- From fandreas@cisco.com Thu Feb 7 07:11:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64021F853E for ; Thu, 7 Feb 2013 07:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.243 X-Spam-Level: X-Spam-Status: No, score=-9.243 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEXwdoIH+3ui for ; Thu, 7 Feb 2013 07:11:13 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D021F84CA for ; Thu, 7 Feb 2013 07:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15099; q=dns/txt; s=iport; t=1360249873; x=1361459473; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=m6maWL4LwQLEjiMHI+Q3uyLoiignKruGqvQ0c7H2Hn4=; b=YZtpHFUOOVnRBXB9h3jAPrAPj1ZepNQpZULrrPYTWyKT0u7t00bjgq3x hLcUNE7jBHRFGDxprvoFs882MRLZ3aKOIXbv0uWuRYEo7S5s41ol8c2lt dPmdxzVIx/wuvitb4TGbIUI5Ch3HdnbqYD+axON1fvsp7Zz/eTLAAYgkb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAKPDE1GrRDoG/2dsb2JhbABFjCS0QhZzgh8BAQEDAQEBAWsKAQwECw4DAwECAQkWDwkDAgECARUoCAYNAQUCAQEFiAIFDb8BkVwDiGaJSINzgR2PNYMe X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208,217";a="68769042" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Feb 2013 15:10:53 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.247.193]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r17FAq9H028737; Thu, 7 Feb 2013 15:10:52 GMT Message-ID: <5113C3FB.3000600@cisco.com> Date: Thu, 07 Feb 2013 10:10:51 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> In-Reply-To: <5113C177.3000507@cisco.com> Content-Type: multipart/alternative; boundary="------------020605070909030308040007" Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:11:14 -0000 This is a multi-part message in MIME format. --------------020605070909030308040007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/7/13 10:00 AM, Flemming Andreasen wrote: > Hi > > I took a look the trickle-ice draft and have a couple of > questions/comments: > > 1) Section 1 says > > This specification does not define usage of trickle ICE with any > specific signalling protocol, contrary to [RFC5245] which contains a > usage for ICE wht SIP. Such usages would have to be specified in > separate documents. > > however you do define it specifically using SDP and Offer/Answer (I > believe). It would be worthwhile calling that out. > > 2) Section 5.1 says > > As mentioned earlier in this section, Offers and Answers can contain > any set of candidates, which means that a trickle ICE session > description MAY contain no candidates at all. In such cases the > agent would still need to place an address in the "c=" line(s). If > the use of a host address there is undesirable (e.g. for privacy > reasons), the agent MAY set the connection address to 0.0.0.0. In > this case it MUST also set the port number to 1. There is no need to > include a fictitious 0.0.0.0 candidate when doing so. > > I had to read this several times before I (think) I understood that > when you say "the agent MAY set the connection address to 0.0.0.0", > you are referring to the connection address in the "a=candidate" > attribute, not the "c=" line. Can you clarify and rephrase accordingly. > > 3) Section 9.1 > I'm confused about this whole section and it's premise that > "a=candidate" attributes and media descriptions are not clearly > linked. The "a=candidate" attribute is defined as a media-level > attribute only and describes as such in RFC 5245, so I must be missing > something here. > > > 4) Section 9.2. Rather than talking about sending "end of candidates" > via "the signalling channel" (which is not defined), could we change > this to say and "end of candidates" need to be sent to the peer, and > the only mechanism defined to do so in this document is through an O/A > exchange (new exchange or answer to an offer) ? > > 5) Section 14 (Example) > The exchange of the "additional candidates" does not use an O/A > exchange. As for comment 4), this assumes some other un-defined > mechanism somewhere - would it be useful to show it as an O/A exchange > as well, but note that other mechanisms may be defined ? > > 6) Section A.1 (MID/Stream Indicates in SDP) > I'm still unclear on this (per comment 3). > 7) It seems the inclusion of the "trickle" ice-options is what will trigger the use of tricke-ICE. I think this is a slight overloading of the ice-options semantics inasmuch as it is intended to indicate support for a given extension, which does not necessarily imply you actually want to use that extension. I think it would be useful to have a separate way of indicating you also want to use trickle-ICE. Thanks -- Flemming > > Thanks > > -- Flemming (as Individual) > > > > On 1/30/13 11:38 AM, Emil Ivov wrote: >> Hey all, >> >> Justin, Eric and I have just submitted an update to the trickle ICE >> draft, accommodating comments from Atlanta: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >> >> More details about the changes here: >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B >> >> Diff2: >> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 >> >> During the MMUSIC presentation and the mailing list discussions it was >> also pointed out that it is important for this work to happen in >> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have >> therefore submitted the following document: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >> >> As always, comments are welcome! >> >> Cheers, >> Emil >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt >> Date: Mon, 28 Jan 2013 11:39:21 -0800 >> From:internet-drafts@ietf.org >> To:emcho@jitsi.org >> CC:justin@uberti.name,ekr@rtfm.com >> >> >> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >> has been successfully submitted by Emil Ivov and posted to the >> IETF repository. >> >> Filename: draft-ivov-mmusic-trickle-ice >> Revision: 00 >> Title: Trickle ICE: Incremental Provisioning of Candidates for the >> Interactive Connectivity Establishment (ICE) Protocol >> Creation date: 2013-01-28 >> WG ID: Individual Submission >> Number of pages: 20 >> URL: >> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >> Htmlized:http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >> >> >> Abstract: >> This document describes an extension to the Interactive Connectivity >> Establishment (ICE) protocol that allows ICE agents to send and >> receive candidates incrementally rather than exchanging complete >> lists. With such incremental provisioning, ICE agents can begin >> connectivity checks while they are still gathering candidates and >> considerably shorten the time necessary for ICE processing to >> complete. >> >> The above mechanism is also referred to as "trickle ICE". >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020605070909030308040007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/7/13 10:00 AM, Flemming Andreasen wrote:
Hi

I took a look the trickle-ice draft and have a couple of questions/comments:

1) Section 1 says
<quote>
   This specification does not define usage of trickle ICE with any
   specific signalling protocol, contrary to [RFC5245] which contains a
   usage for ICE wht SIP.  Such usages would have to be specified in
   separate documents.
</quote>
however you do define it specifically using SDP and Offer/Answer (I believe). It would be worthwhile calling that out.

2) Section 5.1 says
<quote>
   As mentioned earlier in this section, Offers and Answers can contain
   any set of candidates, which means that a trickle ICE session
   description MAY contain no candidates at all.  In such cases the
   agent would still need to place an address in the "c=" line(s).  If
   the use of a host address there is undesirable (e.g. for privacy
   reasons), the agent MAY set the connection address to 0.0.0.0.  In
   this case it MUST also set the port number to 1.  There is no need to
   include a fictitious 0.0.0.0 candidate when doing so.
<quote>
I had to read this several times before I (think) I understood that when you say "the agent MAY set the connection address to 0.0.0.0", you are referring to the connection address in the "a=candidate" attribute, not the "c=" line. Can you clarify and rephrase accordingly.

3) Section 9.1
I'm confused about this whole section and it's premise that "a=candidate" attributes and media descriptions are not clearly linked. The "a=candidate" attribute is defined as a media-level attribute only and describes as such in RFC 5245, so I must be missing something here.


4) Section 9.2. Rather than talking about sending "end of candidates" via "the signalling channel" (which is not defined), could we change this to say and "end of candidates" need to be sent to the peer, and the only mechanism defined to do so in this document is through an O/A exchange (new exchange or answer to an offer) ?

5) Section 14 (Example)
The exchange of the "additional candidates" does not use an O/A exchange. As for comment 4), this assumes some other un-defined mechanism somewhere - would it be useful to show it as an O/A exchange as well, but note that other mechanisms may be defined ?

6) Section A.1 (MID/Stream Indicates in SDP)
I'm still unclear on this (per comment 3).

7) It seems the inclusion of the "trickle" ice-options is what will trigger the use of tricke-ICE. I think this is a slight overloading of the ice-options semantics inasmuch as it is intended to indicate support for a given extension, which does not necessarily imply you actually want to use that extension. I think it would be useful to have a separate way of indicating you also want to use trickle-ICE.

Thanks

-- Flemming



Thanks

-- Flemming (as Individual)



On 1/30/13 11:38 AM, Emil Ivov wrote:
Hey all,

Justin, Eric and I have just submitted an update to the trickle ICE
draft, accommodating comments from Atlanta:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00

More details about the changes here:
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B

Diff2:
http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00

During the MMUSIC presentation and the mailing list discussions it was
also pointed out that it is important for this work to happen in
parallel with a SIP usage for trickle ICE. Enrico, Christer and I have
therefore submitted the following document:

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00

As always, comments are welcome!

Cheers,
Emil

-------- Original Message --------
Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt
Date: Mon, 28 Jan 2013 11:39:21 -0800
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-ivov-mmusic-trickle-ice
Revision:	 00
Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:	 2013-01-28
WG ID:		 Individual Submission
Number of pages: 20
URL:
http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt
Status:
http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice
Htmlized:        http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00


Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat




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





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

--------------020605070909030308040007-- From ted.ietf@gmail.com Thu Feb 7 07:19:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8106C21F8635 for ; Thu, 7 Feb 2013 07:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g22DVUj5Mn2L for ; Thu, 7 Feb 2013 07:19:32 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1636821F84E6 for ; Thu, 7 Feb 2013 07:19:32 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so3593148iea.35 for ; Thu, 07 Feb 2013 07:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LAYKmX8cDyjAeo6mBy5VXkZOPwRwoEJEOk60W6GywwY=; b=x/DDPswl+QQ8oKNq5v9gM4V7b2JzqyhEA5EYq9GCPxJrk3wjPttS+ecQvLbHZkskWX Suz2M43AvorTF+28hJCI7ntFlA+1Yu/nZJUp6qNsPEDlcYQP5obyrwqDiVY7mh0q/xSq hLW7lsKllvAtMFqeO96pnGNLeXBWcTdnJ2dGsOqlRejZF/FP4ZYodDT7ulTQpNyqmKGt jiAZsaYW8ljwSbHZd4trXx3djfavhCnWjjdX5jFKhRDJ88ufRai1YJjyIMsR2U9a9yFo sGiXgJ6EQFbFvBHkRrlmfCWw/5mxNlyHtKxwK2e/oHxo8c2H3MLMyHBl5Rgvo01soxMD tNzw== MIME-Version: 1.0 X-Received: by 10.50.88.136 with SMTP id bg8mr3495082igb.96.1360250371556; Thu, 07 Feb 2013 07:19:31 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 07:19:31 -0800 (PST) In-Reply-To: <5113C3FB.3000600@cisco.com> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> Date: Thu, 7 Feb 2013 10:19:31 -0500 Message-ID: From: Ted Hardie To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:19:32 -0000 On Thu, Feb 7, 2013 at 10:10 AM, Flemming Andreasen wrote: > > 7) It seems the inclusion of the "trickle" ice-options is what will trigger > the use of tricke-ICE. I think this is a slight overloading of the > ice-options semantics inasmuch as it is intended to indicate support for a > given extension, which does not necessarily imply you actually want to use > that extension. I think it would be useful to have a separate way of > indicating you also want to use trickle-ICE. > Why wouldn't just starting trickle-ICE be sufficient indication, given that it has been indicated as supported? I think the half-trickle option covers the case where you don't know that it is supported, but it may be I am misunderstanding the issue. regards, Ted From fandreas@cisco.com Thu Feb 7 07:27:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF0F21F84D9 for ; Thu, 7 Feb 2013 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.515 X-Spam-Level: X-Spam-Status: No, score=-9.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhImJNIzkkrX for ; Thu, 7 Feb 2013 07:27:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02821F84D3 for ; Thu, 7 Feb 2013 07:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1070; q=dns/txt; s=iport; t=1360250825; x=1361460425; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kZVccCw4S7TpjtTjsdBGBUdv1JODGOC93kuocI7Oqbc=; b=f9xnTDQmJvwxgFy62wOkohNVjVUh6ISRhzbMm/6G0LvLaBoD/fLx39oT JSWSMFD39meApQD4KHgkJMYx+k06nYQSliNAnrXQ1O9uMV4pi7IhTc52J Kop+zvyVV9eFU+QeyJR0ixRcoTG33GdhAYfGUpdiaDelpIOgWAdh3dQlT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB7GE1GrRDoH/2dsb2JhbABFwGYWc4IfAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIDA2/AASRXAOIZo07kFKDHg X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="68771295" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Feb 2013 15:27:05 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.247.193]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r17FR4ir018119; Thu, 7 Feb 2013 15:27:04 GMT Message-ID: <5113C7C7.7000502@cisco.com> Date: Thu, 07 Feb 2013 10:27:03 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Hardie References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:27:05 -0000 On 2/7/13 10:19 AM, Ted Hardie wrote: > On Thu, Feb 7, 2013 at 10:10 AM, Flemming Andreasen wrote: >> 7) It seems the inclusion of the "trickle" ice-options is what will trigger >> the use of tricke-ICE. I think this is a slight overloading of the >> ice-options semantics inasmuch as it is intended to indicate support for a >> given extension, which does not necessarily imply you actually want to use >> that extension. I think it would be useful to have a separate way of >> indicating you also want to use trickle-ICE. >> > Why wouldn't just starting trickle-ICE be sufficient indication, How would you know you started trickle-ICE or vanilla ICE ? -- Flemming > given > that it has been indicated as supported? I think the half-trickle > option covers the case where you don't know that it is supported, but > it may be I am misunderstanding the issue. > > regards, > > Ted > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ted.ietf@gmail.com Thu Feb 7 08:02:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E8D21F8891 for ; Thu, 7 Feb 2013 08:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7+GODLNGZls for ; Thu, 7 Feb 2013 08:02:18 -0800 (PST) Received: from mail-ie0-x236.google.com (ie-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E31A021F8599 for ; Thu, 7 Feb 2013 08:02:17 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so3684288iea.41 for ; Thu, 07 Feb 2013 08:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=domSh7EiTsXH/QTSHKF7rWcvwaKWTgiGlz2sD7xfi2o=; b=kRtju+AQVzX5RpeD3O+XSYSyggDEafQAFLZ8RwNGvC5lqQBYgZRvtyHaemShmFADUz KnjGnWryNp5z52E33LSn6eKlMOq1s6JzNJgnLQ9qmXjrtE0DkHKm4mCUbPDram6Q8O46 s5K2Wti76tPGVyIoNBJZHVJkPl6DiX2qb9R2D1/0MepCaJgwtcwiyBID5/nUF6WAqnyV tDU48+kbwP81DnEOQtbPKTd7lAgTRjuuF7E3gnCtK+TG9So+jGCMNvZXbBNTSMJbv5Mk OTACwA7YModSC39TrwzLyaOHmWrPovxeOixvzv/GmGeQWU15NPlRAR4wjYQLLU6SiLTT rJng== MIME-Version: 1.0 X-Received: by 10.50.194.134 with SMTP id hw6mr4040873igc.20.1360252937141; Thu, 07 Feb 2013 08:02:17 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 08:02:16 -0800 (PST) In-Reply-To: <5113C7C7.7000502@cisco.com> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> Date: Thu, 7 Feb 2013 11:02:16 -0500 Message-ID: From: Ted Hardie To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:02:19 -0000 On Thu, Feb 7, 2013 at 10:27 AM, Flemming Andreasen wrote: > > On 2/7/13 10:19 AM, Ted Hardie wrote: >> >> On Thu, Feb 7, 2013 at 10:10 AM, Flemming Andreasen >> wrote: >>> >>> 7) It seems the inclusion of the "trickle" ice-options is what will >>> trigger >>> the use of tricke-ICE. I think this is a slight overloading of the >>> ice-options semantics inasmuch as it is intended to indicate support for >>> a >>> given extension, which does not necessarily imply you actually want to >>> use >>> that extension. I think it would be useful to have a separate way of >>> indicating you also want to use trickle-ICE. >>> >> Why wouldn't just starting trickle-ICE be sufficient indication, > > How would you know you started trickle-ICE or vanilla ICE ? > Well, you'd have a very strong indication if the candidate list were empty, and a reasonable indication if it contained only host candidates. If that weren't the case, you'd have to keep open the possibility that more candidates might come in. But I think I've been thinking of this the other way around--if both sides are known to support trickle-ICE, the client sends a=end-of-candidates whenever it's done *even if that is on the first candidate set sent*. Perhaps that is "vanilla ICE with sprinkles", but it seems to solve the problem without another indicator/round of negotiation. As you note, that may overload the the ice-option semantics, but it seems likely to work reasonable well. regards, Ted > -- Flemming >> >> given >> that it has been indicated as supported? I think the half-trickle >> option covers the case where you don't know that it is supported, but >> it may be I am misunderstanding the issue. >> >> regards, >> >> Ted >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From fandreas@cisco.com Thu Feb 7 08:09:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647C221F86EF for ; Thu, 7 Feb 2013 08:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.05 X-Spam-Level: X-Spam-Status: No, score=-9.05 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LuwrMmFC04k for ; Thu, 7 Feb 2013 08:09:54 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6C21F86DC for ; Thu, 7 Feb 2013 08:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2476; q=dns/txt; s=iport; t=1360253394; x=1361462994; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uxHl14W7SK5AcjuQ3/enWFvDzvdg+Ejp1dA43/qB+FQ=; b=l1iJT5F6K781U07WMw9oTucls+VRFfHnhcG/dHPPhYRmBBnLkR8wrL3h BohLeC4M6yERNXfFe/lTeC8aeW31OF0kiZnIUGxVO5HRq2DfoISqxaTBa Y698mIt4N8fIIfCuJ4vwdunTDMNvzqw6Kc1k66+WpvNtfI1WWVc2ROdLh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKnQE1GrRDoG/2dsb2JhbABFwGcWc4IfAQEBAwEBAQE1NgoBBQsLGAkWDwkDAgECARUwBg0BBQIBAYgHBQ2/EwSRXAOIZo07kFKDHg X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="68249986" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Feb 2013 16:09:53 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.245.38]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r17G9qjo030000; Thu, 7 Feb 2013 16:09:52 GMT Message-ID: <5113D1D0.3060806@cisco.com> Date: Thu, 07 Feb 2013 11:09:52 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Hardie References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:09:55 -0000 On 2/7/13 11:02 AM, Ted Hardie wrote: > On Thu, Feb 7, 2013 at 10:27 AM, Flemming Andreasen wrote: >> On 2/7/13 10:19 AM, Ted Hardie wrote: >>> On Thu, Feb 7, 2013 at 10:10 AM, Flemming Andreasen >>> wrote: >>>> 7) It seems the inclusion of the "trickle" ice-options is what will >>>> trigger >>>> the use of tricke-ICE. I think this is a slight overloading of the >>>> ice-options semantics inasmuch as it is intended to indicate support for >>>> a >>>> given extension, which does not necessarily imply you actually want to >>>> use >>>> that extension. I think it would be useful to have a separate way of >>>> indicating you also want to use trickle-ICE. >>>> >>> Why wouldn't just starting trickle-ICE be sufficient indication, >> How would you know you started trickle-ICE or vanilla ICE ? >> > Well, you'd have a very strong indication if the candidate list were > empty, and a reasonable indication if it contained only host > candidates. If that weren't the case, you'd have to keep open the > possibility that more candidates might come in. The above would seem to favor an explicit indication. > But I think I've been thinking of this the other way around--if both > sides are known to support trickle-ICE, the client sends > a=end-of-candidates whenever it's done *even if that is on the first > candidate set sent*. Not sure I follow - this would terminate trickle-ICE prematurely, no ? > Perhaps that is "vanilla ICE with sprinkles", > but it seems to solve the problem without another indicator/round of > negotiation. As you note, that may overload the the ice-option > semantics, but it seems likely to work reasonable well. I don't think it does since it would seem to terminate trickle-ICE prematurely, but maybe we should wait for the authors to clarify. Thanks -- Flemming > regards, > > Ted > > >> -- Flemming >>> given >>> that it has been indicated as supported? I think the half-trickle >>> option covers the case where you don't know that it is supported, but >>> it may be I am misunderstanding the issue. >>> >>> regards, >>> >>> Ted >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From ted.ietf@gmail.com Thu Feb 7 08:18:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6421F86DC for ; Thu, 7 Feb 2013 08:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9ZWK8geBV9B for ; Thu, 7 Feb 2013 08:18:41 -0800 (PST) Received: from mail-ia0-x231.google.com (ia-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6BF21F86CD for ; Thu, 7 Feb 2013 08:18:41 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id h8so3106665iaa.22 for ; Thu, 07 Feb 2013 08:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=huRHnPjG10K4AovyOeJzztQaXareyLxAmulnivghSnk=; b=ELX9HXsm97mu/jnuQTCG1g/wJv6mkwA8piAtoBxZKTr5hj975sg60jdHa4gPMc6ql8 fmM6tJmjsBG4b7850oRYCX+ig8bEOVdu874kosRGfwdg8YABBwgu9ir6z9G/GQQRXszI SMTOww7J8ICeJpZRtleswgdMU1rZKJlLWJxkrJatgkAvn02xYJvijrLcUSeePvzVmkyX c68tW7U1BmqP+Jrrc3gAj79JfYHJcDYSdhcRaYUawbXh0Xyf4JJTBFPJE19hk2EaSdsX CWBSM+SaKvxbx9EArZWIDv3dAVE7IfbeYdyv+rGl7ij0KeVEPtc0s0YSw2w7jWthttpy 9N7Q== MIME-Version: 1.0 X-Received: by 10.42.33.196 with SMTP id j4mr3465373icd.4.1360253911911; Thu, 07 Feb 2013 08:18:31 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 08:18:31 -0800 (PST) In-Reply-To: <5113D1D0.3060806@cisco.com> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> <5113D1D0.3060806@cisco.com> Date: Thu, 7 Feb 2013 11:18:31 -0500 Message-ID: From: Ted Hardie To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:18:41 -0000 On Thu, Feb 7, 2013 at 11:09 AM, Flemming Andreasen wrote: > If that weren't the case, you'd have to keep open the >> possibility that more candidates might come in. > > The above would seem to favor an explicit indication. > > >> But I think I've been thinking of this the other way around--if both >> sides are known to support trickle-ICE, the client sends >> a=end-of-candidates whenever it's done *even if that is on the first >> candidate set sent*. > > Not sure I follow - this would terminate trickle-ICE prematurely, no ? > It would terminate it, but not prematurely. The client sends a=end-of-candidates whenever it's done sending candidates; it just allows you to send that indicator if you already had the full list on the first use. So if it did the blocking version of candidate gathering, it sends that as the indicator that it is done. > >> Perhaps that is "vanilla ICE with sprinkles", >> but it seems to solve the problem without another indicator/round of >> negotiation. As you note, that may overload the the ice-option >> semantics, but it seems likely to work reasonable well. > > I don't think it does since it would seem to terminate trickle-ICE > prematurely, but maybe we should wait for the authors to clarify. > Well, I'd certainly be happy to have the authors or others chime in. But I am personally okay with the presumption that you always use Trickle-ICE if Trickle-ICE is available at both ends, because it is easy to get Vanilla ICE semantics using Trickle-ICE syntax. I agree, though, that this overloads the ice-option. regards, Ted Hardie From matthew@matthew.at Thu Feb 7 08:54:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC50421F8715 for ; Thu, 7 Feb 2013 08:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHH0wVBpZeDE for ; Thu, 7 Feb 2013 08:54:00 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8405A21F8C4B for ; Thu, 7 Feb 2013 08:53:57 -0800 (PST) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 1B96E230005 for ; Thu, 7 Feb 2013 08:53:57 -0800 (PST) Message-ID: <5113DC24.70402@matthew.at> Date: Thu, 07 Feb 2013 08:53:56 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> <5113D1D0.3060806@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:54:02 -0000 On 2/7/2013 8:18 AM, Ted Hardie wrote: > > It would terminate it, but not prematurely. The client sends > a=end-of-candidates whenever it's done sending candidates; it just > allows you to send that indicator if you already had the full list on > the first use. So if it did the blocking version of candidate > gathering, it sends that as the indicator that it is done. Isn't part of the point of trickle-ICE that you potentially are never done sending candidates? (Interface and connectivity changes and the like, avoiding a complete session restart by testing and switching to new candidates on the fly) Matthew Kaufman From ted.ietf@gmail.com Thu Feb 7 08:58:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECB021F873D for ; Thu, 7 Feb 2013 08:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+ZBXtiS2K-H for ; Thu, 7 Feb 2013 08:58:35 -0800 (PST) Received: from mail-ia0-x233.google.com (ia-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id B82C621F87C3 for ; Thu, 7 Feb 2013 08:58:35 -0800 (PST) Received: by mail-ia0-f179.google.com with SMTP id x24so3106662iak.38 for ; Thu, 07 Feb 2013 08:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=75RIWbGzAJlyX/ydxhUH9Iym3oo7L6ikbJHpbf1vKoY=; b=yVIgNmWURWovrFao+7qDW8ykhYyZr2OH8VvuPcakSgHFMfUyybtnnE5+icZl6OL+Yf YCHeFcDKTQaxTAmzprYkvm95QLSK6hgTZFdBvPdGgvKQNh7AB7aKtTNLOQe6+fFyhUGX v4GKZcE+1hxof3z3zG0JTQ51a9r0sB96VDI8mIjaHsbFZO1dw4uoGNA1HqywufPxBPbQ rxzDWVbOO6mXKc7Pb0MxN8Z4IG9o2fs5K9QTdxF6NZM5L0uHlDSSGKb6VxB7AYrUY0WR +S6OSrvE9Tcsn6Nl8ncIFFyGfXtvGoMqmtal4UZ2VaSI9NPQJTEKYpNNdUGH3/0efClG sZKA== MIME-Version: 1.0 X-Received: by 10.42.48.147 with SMTP id s19mr3654109icf.18.1360256315278; Thu, 07 Feb 2013 08:58:35 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 08:58:35 -0800 (PST) In-Reply-To: <5113DC24.70402@matthew.at> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> <5113D1D0.3060806@cisco.com> <5113DC24.70402@matthew.at> Date: Thu, 7 Feb 2013 11:58:35 -0500 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:58:36 -0000 On Thu, Feb 7, 2013 at 11:53 AM, Matthew Kaufman wrote: > On 2/7/2013 8:18 AM, Ted Hardie wrote: >> >> >> It would terminate it, but not prematurely. The client sends >> a=end-of-candidates whenever it's done sending candidates; it just >> allows you to send that indicator if you already had the full list on >> the first use. So if it did the blocking version of candidate >> gathering, it sends that as the indicator that it is done. > > > Isn't part of the point of trickle-ICE that you potentially are never done > sending candidates? (Interface and connectivity changes and the like, > avoiding a complete session restart by testing and switching to new > candidates on the fly) You could use it that way, but it supports modes that allow you to claim you are done. The "send host candidates first, then trickle server reflexive and call it done" is one called out in the draft. Since you can claim you are done, getting the semantics of vanilla ICE seems easy enough. Just my two cents, Ted > > Matthew Kaufman > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ted.ietf@gmail.com Thu Feb 7 09:09:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC67921F8561; Thu, 7 Feb 2013 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCLMXtYgcYFt; Thu, 7 Feb 2013 09:09:29 -0800 (PST) Received: from mail-ie0-x233.google.com (ie-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3378F21F841F; Thu, 7 Feb 2013 09:09:28 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so3781973iea.24 for ; Thu, 07 Feb 2013 09:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=tC8+2jo/S2AzpUlYdb5F7P43PDxO6SlTrugcPvdex4U=; b=kB8HeEqvJdwRtojDnu9ysodrRJoS5/QrlCCCk5DHdWO6Xlemt2Snj+rEK4zI331JmO Vm9CLw0cP6V3xYQTVhPCTUr/+HSWXQtZELRrqYfyK/ADpEzDmbjmt4F7uDPUAXAk2AA9 c/UYZx+k+QIwUzdR/SOBpLVKJDvWGd2eFVQD+SKXKz4smyhb1gIspm3UJmcXHv6MglfW 9elA4ESy6OWCKYY7tzSnSc06P3P3cRu0iR+DqnmuCZu8TPr9T4HfUi77Sp9sQCzYy95i Im9GnJQTf8ti9iYGhMp0zx5rH5Gj4NVzulfK+WFuyc8TsPmtujiciT096Kpo1rywojrD YHeg== MIME-Version: 1.0 X-Received: by 10.42.48.147 with SMTP id s19mr3722504icf.18.1360256967963; Thu, 07 Feb 2013 09:09:27 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 7 Feb 2013 09:09:27 -0800 (PST) Date: Thu, 7 Feb 2013 12:09:27 -0500 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] IETF Interim starting fifteen minutes early at 1:15 p.m. Boston time X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:09:29 -0000 In order to give folks a little extra time to get to the airport, we're going to start at 1:15 and aim to finish on time at 5:00. Ted From emil@sip-communicator.org Thu Feb 7 09:28:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8049521F8635 for ; Thu, 7 Feb 2013 09:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-vCOSFYgynx for ; Thu, 7 Feb 2013 09:28:02 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7D48B21F8B3F for ; Thu, 7 Feb 2013 09:28:02 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so1301074dak.2 for ; Thu, 07 Feb 2013 09:28:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=olS9/luJF7nlAKPzQg4Af/vTOa/DPY/RRU2MtYdFImw=; b=TAwIQWcz+BNOKlKcE2C4bceuSIqPV5INnwJQI+YeVbcEyUI7avRNSR7yW4JnUFiPHG JMD6TP20XUUHHvl/EaxpejfQUGtrD7C57kP41GthppMYhi4dgegVE3GJ3MDaT7Y76ofq E0eWs4VOAwe107Bio2et4Eig+C5IMxxYmbZr1qKDcpFXHtGirz5UNQO0bBNpauHY1wC5 bYHGNruMIR6g9y6BS5w2APRMyEKqrJmT9CwTKkAio+m1feWkhqEfj4V8+uGVrPSgdzN2 lfj4rUGM6QTyoYX+vnIWzaTkhvMT+zzoKXmOGlnS8FdgW24vsJbjxVTuUR6Q9xlj20HM I+wQ== X-Received: by 10.66.76.37 with SMTP id h5mr7778955paw.33.1360258081862; Thu, 07 Feb 2013 09:28:01 -0800 (PST) Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id l5sm47477259pax.10.2013.02.07.09.27.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 09:28:00 -0800 (PST) Message-ID: <5113E41B.3090403@jitsi.org> Date: Thu, 07 Feb 2013 12:27:55 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Hardie References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113C7C7.7000502@cisco.com> <5113D1D0.3060806@cisco.com> <5113DC24.70402@matthew.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnZ+wTrm5npndys4roUcE8VllHwT9bVSx1TX/BZudaKArEs7OrVCWFNNdNeHGl4GWuQ7N8r Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:28:03 -0000 Hey all, On 07.02.13, 11:58, Ted Hardie wrote: > On Thu, Feb 7, 2013 at 11:53 AM, Matthew Kaufman wrote: >> On 2/7/2013 8:18 AM, Ted Hardie wrote: >>> >>> >>> It would terminate it, but not prematurely. The client sends >>> a=end-of-candidates whenever it's done sending candidates; it just >>> allows you to send that indicator if you already had the full list on >>> the first use. So if it did the blocking version of candidate >>> gathering, it sends that as the indicator that it is done. >> >> >> Isn't part of the point of trickle-ICE that you potentially are never done >> sending candidates? (Interface and connectivity changes and the like, >> avoiding a complete session restart by testing and switching to new >> candidates on the fly) > > You could use it that way, but it supports modes that allow you to > claim you are done. The "send host candidates first, then trickle > server reflexive and call it done" is one called out in the draft. > Since you can claim you are done, getting the semantics of vanilla ICE > seems easy enough. Yup that's the idea. The whole point of having end-of-candidates indications is to basically say: I am not done till I say I am done (and I really am when I say I am). Emil > > Just my two cents, > > Ted -- https://jitsi.org From emil@sip-communicator.org Thu Feb 7 10:00:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31BF21F8856 for ; Thu, 7 Feb 2013 10:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cEcU9QR4p7o for ; Thu, 7 Feb 2013 10:00:50 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 41B5021F8800 for ; Thu, 7 Feb 2013 10:00:50 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kq12so1567617pab.1 for ; Thu, 07 Feb 2013 10:00:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=TTN3zD9MIaB+ZE0WFS8stRZQ0KWJUl1crQgGmJf505M=; b=QGk4mnDbMHjy3FJAdjayNr0L2m0augyLNYEpj6fzD6T65GbymheVeW2cL2AY25FfHj ii2CWisF5YApUi2g+vLBhCz/neXoi6U1rAIXx8k6QQn4U6VfQ7z4RY4Ug82dDsvftVMQ N9kHAn4GFXl5mAbhgVuV4BFXPOMfkhvtKq82zMgrZ9ixjH0fZ8QH4jYHNZ1phHABi4Z1 AAmNoXG6fl03b0t9kANia4Ak0h+e8EQxrsytJTwghnd/X2x/ojnavEnRfzI8BsA1eNYc idxdrh6groebbzEslOI8Bq9/u3z4fK0gQkaTU1qzfjg6g7q2viK5B7Ip+wS/cheqGu6p +FtQ== X-Received: by 10.66.89.199 with SMTP id bq7mr8135753pab.26.1360260049607; Thu, 07 Feb 2013 10:00:49 -0800 (PST) Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id f9sm47656716paz.12.2013.02.07.10.00.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 10:00:48 -0800 (PST) Message-ID: <5113EBCD.7050901@jitsi.org> Date: Thu, 07 Feb 2013 13:00:45 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> In-Reply-To: <5113C3FB.3000600@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmzbRgmo957x8HfsAH0hAi+ftbGhR2h9o0YF6eoMJiia12oP5MJWf0zMY0FIdZBSHuf+CVS Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 18:00:51 -0000 Hey Flemming, Ted, all, On 07.02.13, 10:10, Flemming Andreasen wrote: > 7) It seems the inclusion of the "trickle" ice-options is what will > trigger the use of tricke-ICE. I think this is a slight overloading of > the ice-options semantics inasmuch as it is intended to indicate support > for a given extension, which does not necessarily imply you actually > want to use that extension. I think it would be useful to have a > separate way of indicating you also want to use trickle-ICE. The intention of the current trickle ICE text is to say the following: 1. When your (the offerer's) intention is to do half trickle you include the "trickle" ice-options token and you are prepared to have the answerer trickling. You are also prepared to have them do vanilla ICE. In either case you can either include end-of-candidates in your offer or you can choose to not include it depending on how you intend to behave if the answerer turns out to support trickle. 1.1. If the answer does indicate support trickle ICE by the answerer, then you are both abiding by the trickle-ice spec. You can both still choose to behave like vanilla ICE agents and send complete sets of candidates from the start but you know that you have to handle trickle semantics and you know that you have to send end-of-candidates when you are done. 1.2 If the answerer does not support trickle, then there's no "trickle" ice-options token in the answer and the offerer knows that trickling is no longer possible (regardless of whether or not there was end-of-candidates in the offer). 2. If the offerer's intention is to generate a vanilla ICE offer then it does not include the "trickle" ice-options token and everyone just uses vanilla ICE semantics. I believe that this is the part in 5245 that you had a problem with and I think that this is the text you are referring to: First, ICE provides the a=ice-options SDP attribute. Each extension or change to ICE is associated with a token. When an agent supporting such an extension or change generates an offer or an answer, it MUST include the token for that extension in this attribute. *This allows each side to know what the other side is doing*. This attribute MUST NOT be present if the agent doesn't support any ICE extensions or changes. I am not sure exactly what the intention of this text was (maybe we could clarify this in 5245bis) but that highlighted part makes me think the point was to make sure everyone knows what behaviour to expect rather than what features they have in their ICE stack even if they are not planning on using them. In that sense, if I send what I intend to be a vanilla offer then you can count on me not to use any trickle semantics and you would make me really unhappy if you did it yourself (because I might be gateway-ing your stuff to a vanilla agent). In that sense I'd really like you to behave as if I were a vanilla ICE agent. In other words, I believe it would be legitimate for me not to include the "trickle" token in ice-options. Does this make sense? Emil > > Thanks > > -- Flemming > > >> >> Thanks >> >> -- Flemming (as Individual) >> >> >> >> On 1/30/13 11:38 AM, Emil Ivov wrote: >>> Hey all, >>> >>> Justin, Eric and I have just submitted an update to the trickle ICE >>> draft, accommodating comments from Atlanta: >>> >>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>> >>> More details about the changes here: >>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B >>> >>> Diff2: >>> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 >>> >>> During the MMUSIC presentation and the mailing list discussions it was >>> also pointed out that it is important for this work to happen in >>> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have >>> therefore submitted the following document: >>> >>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >>> >>> As always, comments are welcome! >>> >>> Cheers, >>> Emil >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt >>> Date: Mon, 28 Jan 2013 11:39:21 -0800 >>> From: internet-drafts@ietf.org >>> To: emcho@jitsi.org >>> CC: justin@uberti.name, ekr@rtfm.com >>> >>> >>> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >>> has been successfully submitted by Emil Ivov and posted to the >>> IETF repository. >>> >>> Filename: draft-ivov-mmusic-trickle-ice >>> Revision: 00 >>> Title: Trickle ICE: Incremental Provisioning of Candidates for the >>> Interactive Connectivity Establishment (ICE) Protocol >>> Creation date: 2013-01-28 >>> WG ID: Individual Submission >>> Number of pages: 20 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >>> Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>> >>> >>> Abstract: >>> This document describes an extension to the Interactive Connectivity >>> Establishment (ICE) protocol that allows ICE agents to send and >>> receive candidates incrementally rather than exchanging complete >>> lists. With such incremental provisioning, ICE agents can begin >>> connectivity checks while they are still gathering candidates and >>> considerably shorten the time necessary for ICE processing to >>> complete. >>> >>> The above mechanism is also referred to as "trickle ICE". >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From harald@alvestrand.no Fri Feb 8 12:56:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413B21F8BE7 for ; Fri, 8 Feb 2013 12:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.326 X-Spam-Level: X-Spam-Status: No, score=-110.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeZRzSkfoBWG for ; Fri, 8 Feb 2013 12:56:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE121F8B69 for ; Fri, 8 Feb 2013 12:56:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF41239E197 for ; Fri, 8 Feb 2013 21:56:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJdKGWfV4ejg for ; Fri, 8 Feb 2013 21:56:45 +0100 (CET) Received: from [IPv6:2620:0:1004:b:f175:1fb4:5361:b9a8] (unknown [IPv6:2620:0:1004:b:f175:1fb4:5361:b9a8]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5C70A39E125 for ; Fri, 8 Feb 2013 21:56:45 +0100 (CET) Message-ID: <5115668C.8020702@alvestrand.no> Date: Fri, 08 Feb 2013 21:56:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <5111247B.8060904@nostrum.com> In-Reply-To: <5111247B.8060904@nostrum.com> Content-Type: multipart/alternative; boundary="------------050508080600050302040005" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 20:56:49 -0000 This is a multi-part message in MIME format. --------------050508080600050302040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/05/2013 04:25 PM, Adam Roach wrote: > On 2/4/13 02:45, Justin Uberti wrote: >> Sorry for the short lead time, but here's a quick read for the plane. > > I addressed several of the assertions made in this draft in my > previous response (e.g. the need for glare resolution regardless of > which solution we select). Some additional thoughts: > >> o Adding or removing a source requires sending a full list of all >> sources, which doesn't scale well to 10s or 100s of sources, >> especially when they are added or removed frequently. > > Realistically, this isn't how multiparty conferences are handled. It's > unrealistic to think that my DSL connection is going to be sucking > down hundreds of video streams just because I'm in a video conference > with hundreds of people. (challenging assumptions) why is it realistic to assume that you're on a DSL line? In Kansas City, a hundred video streams each doing 100 Kbits/s or so may be a completely realistic way of doing conference-participation thumbnails; it's only 10 Mbits, which isn't that much on a gigabit link. (with today's codecs, CPU may be a more limiting factor. It's the DSL part I reacted to.) --------------050508080600050302040005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/05/2013 04:25 PM, Adam Roach wrote:
On 2/4/13 02:45, Justin Uberti wrote:
Sorry for the short lead time, but here's a quick read for the plane.

I addressed several of the assertions made in this draft in my previous response (e.g. the need for glare resolution regardless of which solution we select). Some additional thoughts:

   o  Adding or removing a source requires sending a full list of all
      sources, which doesn't scale well to 10s or 100s of sources,
      especially when they are added or removed frequently.

Realistically, this isn't how multiparty conferences are handled. It's unrealistic to think that my DSL connection is going to be sucking down hundreds of video streams just because I'm in a video conference with hundreds of people.

(challenging assumptions)
why is it realistic to assume that you're on a DSL line?
In Kansas City, a hundred video streams each doing 100 Kbits/s or so may be a completely realistic way of doing conference-participation thumbnails; it's only 10 Mbits, which isn't that much on a gigabit link.

(with today's codecs, CPU may be a more limiting factor. It's the DSL part I reacted to.)


--------------050508080600050302040005-- From andrew.hutton@siemens-enterprise.com Fri Feb 8 19:01:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE91121F8C8D for ; Fri, 8 Feb 2013 19:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLvKg1v0OKuu for ; Fri, 8 Feb 2013 19:01:33 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 465E421F8C7A for ; Fri, 8 Feb 2013 19:01:33 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C7D5B1EB8481 for ; Sat, 9 Feb 2013 04:01:31 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.249]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Sat, 9 Feb 2013 04:01:31 +0100 From: "Hutton, Andrew" To: "mmusic@ietf.org (E-mail)" Thread-Topic: Requirements for Bundle, Fumble etc. Thread-Index: Ac4GccK7bqnLXEJETZGGjdGBYA3GeA== Date: Sat, 9 Feb 2013 03:01:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 03:01:34 -0000 Hi, I suggest that the requirements discussed at the interim (http://www.ietf.o= rg/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-= 1-10.pdf) regarding bundling on to a single 5-tuple need the following addi= tional requirements. 1. Must work for a dual stack client when ICE candidates are used for addre= ss family negotiation. I think this is interesting because in this scenario= there will of course be different candidates for each address family and w= e will probably need some rules to make sure this works. 2. Must work when a TURN server is used. This is interesting because althou= gh a single TURN allocation will be needed for the bundled candidates it wi= ll I assume be necessary to do additional TURN allocations just in case the= peer does not support bundle. Regards Andy=20 From emil@sip-communicator.org Sat Feb 9 10:18:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297A021F861B for ; Sat, 9 Feb 2013 10:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj0z6KX1dyPc for ; Sat, 9 Feb 2013 10:18:29 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5221F85EE for ; Sat, 9 Feb 2013 10:18:29 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id d16so3042812vcd.12 for ; Sat, 09 Feb 2013 10:18:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=iGtBbbnKZNRrK1a5RjoziukG3rLnuY56SIdfIDzKDOc=; b=pyf13sXTaty9PNOXY/DG4Ge6slXO/wtxSe7LGLdPA34UzCGZGYw18UrPtDmiVKRSq/ oRIr2ktQike4gFQmtPCtMrdLbLXUHDFvoHhGzp/BJ8NhToAWr5eAAibMZn7+X39lt6bT 7hUC514EduzhwDKcpMIJle/aztMRHXMz05DPhYjImF3p4W2CaDYiw9h+04ZTG1lsU6C2 jGwNPggsFPF1i3hHr3eLE/j7q2VyIWWHKKGWgnMsvlrWxZLv7TKhta+5IUeniuZWXiFR I4O95QcCpbsi836LRLL6oTyOWfwUpY8bA1CEwTYV34VGl4674PnbHndYavNz9KI7KPF5 XcQw== X-Received: by 10.52.34.176 with SMTP id a16mr10838264vdj.44.1360433908512; Sat, 09 Feb 2013 10:18:28 -0800 (PST) Received: from camionet.local (static-173-210-90-146.ngn.onecommunications.net. [173.210.90.146]) by mx.google.com with ESMTPS id x17sm50359052vdi.1.2013.02.09.10.18.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 10:18:27 -0800 (PST) Message-ID: <511692F1.6060307@jitsi.org> Date: Sat, 09 Feb 2013 13:18:25 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Hutton, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnX/h+9AaaAx0LmJTgb5UbvuHWbrcxDLnMki3Pq+BgpytAozveg4BHo+r6T32bdk22rGufr Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 18:18:30 -0000 Hey all, On 08.02.13, 22:01, Hutton, Andrew wrote: > 2. Must work when a TURN server is used. This is interesting because > although a single TURN allocation will be needed for the bundled > candidates it will I assume be necessary to do additional TURN > allocations just in case the peer does not support bundle. This can actually be stated in a more generic way. I already mentioned it to Cullen but it's probably worth putting it on the list too: Some of the solutions that we discussed in Boston had the property of requiring multiple port allocations which would translate into multiple sets of ICE candidates. Note that, given how the whole point here is to talk to non-webrtc offer/answer devices, offerers may often be choosing not to use full trickle ICE and only resort to half trickle (or even vanilla ICE). Also note that, contrary to dedicated devices, WebRTC applications would often have no indication that a call is about to occur, until a "Call Us" button on a web page is clicked. In other words, using solutions like one-rtp or MMT would mean that clients would have to go through all the (paced) steps of harvesting candidates in a blocking manner, while the user is waiting and without even the option of using the vanilla ICE optimization of pre-harvesting them in anticipation for a call. I am not sure if this qualifies as a requirement but it would probably be good to keep it in mind. Cheers, Emil -- https://jitsi.org From worley@shell01.TheWorld.com Sat Feb 9 19:47:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E5721F8425 for ; Sat, 9 Feb 2013 19:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPUdQJBZG09I for ; Sat, 9 Feb 2013 19:47:39 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7921F841F for ; Sat, 9 Feb 2013 19:47:39 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1A3lPKG031005 for ; Sat, 9 Feb 2013 22:47:27 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1A3lOKt1557889 for ; Sat, 9 Feb 2013 22:47:25 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1A3lOVA1557650; Sat, 9 Feb 2013 22:47:24 -0500 (EST) Date: Sat, 9 Feb 2013 22:47:24 -0500 (EST) Message-Id: <201302100347.r1A3lOVA1557650@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com) References: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> Subject: Re: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 03:47:40 -0000 > From: "Hutton, Andrew" > > 1. Must work for a dual stack client when ICE candidates are used > for address family negotiation. I think this is interesting because > in this scenario there will of course be different candidates for > each address family and we will probably need some rules to make > sure this works. Doesn't ICE already have rules for negotiating both IPv4 and IPv6 addresses simultaneously? (I'm not very familiar with ICE, but skimming RFC 5245 suggests that SDP can provide candidates with both IPv4 and IPv6 addresses, and that the ICE negotiation handles them both.) Dale From andrew.hutton@siemens-enterprise.com Sun Feb 10 08:30:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F421F85FD for ; Sun, 10 Feb 2013 08:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sMzyLq0OEJp for ; Sun, 10 Feb 2013 08:30:56 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3021F843A for ; Sun, 10 Feb 2013 08:30:55 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 73D8823F0401; Sun, 10 Feb 2013 17:30:54 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.249]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Sun, 10 Feb 2013 17:30:54 +0100 From: "Hutton, Andrew" To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Requirements for Bundle, Fumble etc. Thread-Index: Ac4GccK7bqnLXEJETZGGjdGBYA3GeAAz6kaNABp7OgA= Date: Sun, 10 Feb 2013 16:30:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013E0086@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> <201302100347.r1A3lOVA1557650@shell01.TheWorld.com> In-Reply-To: <201302100347.r1A3lOVA1557650@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 16:30:56 -0000 On 09 February 2013 22:47 Dale R. Worley wrote: >=20 > Doesn't ICE already have rules for negotiating both IPv4 and IPv6 > addresses simultaneously? (I'm not very familiar with ICE, but > skimming RFC 5245 suggests that SDP can provide candidates with both > IPv4 and IPv6 addresses, and that the ICE negotiation handles them > both.) >=20 Absolutely ICE does have these rules we do however need to make sure that t= hey work when bundle is being negotiated at the same time. Andy From internet-drafts@ietf.org Sun Feb 10 22:26:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FB921F880B; Sun, 10 Feb 2013 22:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0JyqdrpxMzO; Sun, 10 Feb 2013 22:26:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC6421F87D5; Sun, 10 Feb 2013 22:25:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211062542.30658.22256.idtracker@ietfa.amsl.com> Date: Sun, 10 Feb 2013 22:25:42 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 06:26:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Cross Session Stream Identification in the Session Descr= iption Protocol Author(s) : Harald Alvestrand Filename : draft-ietf-mmusic-msid-00.txt Pages : 13 Date : 2013-02-10 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams within different RTP sessions as well as within a single RTP session, and independently of whether these media streams are described within one SDP m-line or in multiple m-lines. This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fandreas@cisco.com Mon Feb 11 17:33:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8321F85E7 for ; Mon, 11 Feb 2013 17:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.793 X-Spam-Level: X-Spam-Status: No, score=-8.793 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta+JZlE5INLV for ; Mon, 11 Feb 2013 17:33:11 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3A56621F85CC for ; Mon, 11 Feb 2013 17:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6981; q=dns/txt; s=iport; t=1360632791; x=1361842391; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=l3IK6sjYp8CqXsYjGP3amuKnjmWvrSDQfK38360kooo=; b=Ip5V6FsVFJaDm/kMGfIQNmFKEsTg7RqgBteOXfE4uL7Fxf0U3ygl3mcZ WVl9g8v13Z9W9DbySbJavs+aL6/Q/3zg+EdfAGyDIJXqpGUIN4QQLUJDa QdTqyfpEVt9dGOmhkBn/YDZIPnJIWY6Quz1CnPqiOQeciGK1hLkSDLBmm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALqaGVGrRDoH/2dsb2JhbABEwSkWc4IfAQEBBAEBATU2CgEMBAsOAwMBAgEJFg8JAwIBAgEVKAgGDQEFAgEBBYgIDcApkg0DiGaJSoN0gR2PNoMk X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; d="scan'208";a="68857631" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 12 Feb 2013 01:33:10 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.16.51]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1C1XAPQ017738; Tue, 12 Feb 2013 01:33:10 GMT Message-ID: <51199BD6.8070606@cisco.com> Date: Mon, 11 Feb 2013 20:33:10 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113EBCD.7050901@jitsi.org> In-Reply-To: <5113EBCD.7050901@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ari Keranen , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 01:33:15 -0000 Hi Emil As noted at the Interim meeting, I think it's cleaner to have ice-options used to strictly indicate features supported, and then have a separate way of indicating their use. However, in taking another look at RFC 5245, it's somewhat unclear what semantics were intended. Section 15.5 for example suggests "supported" semantics, however Section 21.1.7 suggests "used" semantics. There are a few more examples of each throughout the doc so I agree with you that 5245bis should clarify this (and depending on that clarification, we should use it the same way here). Thanks -- Flemming On 2/7/13 1:00 PM, Emil Ivov wrote: > Hey Flemming, Ted, all, > > On 07.02.13, 10:10, Flemming Andreasen wrote: >> 7) It seems the inclusion of the "trickle" ice-options is what will >> trigger the use of tricke-ICE. I think this is a slight overloading of >> the ice-options semantics inasmuch as it is intended to indicate support >> for a given extension, which does not necessarily imply you actually >> want to use that extension. I think it would be useful to have a >> separate way of indicating you also want to use trickle-ICE. > The intention of the current trickle ICE text is to say the following: > > 1. When your (the offerer's) intention is to do half trickle you include > the "trickle" ice-options token and you are prepared to have the > answerer trickling. You are also prepared to have them do vanilla ICE. > In either case you can either include end-of-candidates in your offer or > you can choose to not include it depending on how you intend to behave > if the answerer turns out to support trickle. > > 1.1. If the answer does indicate support trickle ICE by the answerer, > then you are both abiding by the trickle-ice spec. You can both still > choose to behave like vanilla ICE agents and send complete sets of > candidates from the start but you know that you have to handle trickle > semantics and you know that you have to send end-of-candidates when you > are done. > > 1.2 If the answerer does not support trickle, then there's no "trickle" > ice-options token in the answer and the offerer knows that trickling is > no longer possible (regardless of whether or not there was > end-of-candidates in the offer). > > 2. If the offerer's intention is to generate a vanilla ICE offer then it > does not include the "trickle" ice-options token and everyone just uses > vanilla ICE semantics. > > I believe that this is the part in 5245 that you had a problem with and > I think that this is the text you are referring to: > > First, ICE provides the a=ice-options SDP attribute. Each extension > or change to ICE is associated with a token. When an agent > supporting such an extension or change generates an offer or an > answer, it MUST include the token for that extension in this > attribute. *This allows each side to know what the other side is > doing*. This attribute MUST NOT be present if the agent doesn't > support any ICE extensions or changes. > > I am not sure exactly what the intention of this text was (maybe we > could clarify this in 5245bis) but that highlighted part makes me think > the point was to make sure everyone knows what behaviour to expect > rather than what features they have in their ICE stack even if they are > not planning on using them. > > In that sense, if I send what I intend to be a vanilla offer then you > can count on me not to use any trickle semantics and you would make me > really unhappy if you did it yourself (because I might be gateway-ing > your stuff to a vanilla agent). In that sense I'd really like you to > behave as if I were a vanilla ICE agent. > > In other words, I believe it would be legitimate for me not to include > the "trickle" token in ice-options. > > Does this make sense? > > Emil > >> Thanks >> >> -- Flemming >> >> >>> Thanks >>> >>> -- Flemming (as Individual) >>> >>> >>> >>> On 1/30/13 11:38 AM, Emil Ivov wrote: >>>> Hey all, >>>> >>>> Justin, Eric and I have just submitted an update to the trickle ICE >>>> draft, accommodating comments from Atlanta: >>>> >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>>> >>>> More details about the changes here: >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B >>>> >>>> Diff2: >>>> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 >>>> >>>> During the MMUSIC presentation and the mailing list discussions it was >>>> also pointed out that it is important for this work to happen in >>>> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have >>>> therefore submitted the following document: >>>> >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >>>> >>>> As always, comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt >>>> Date: Mon, 28 Jan 2013 11:39:21 -0800 >>>> From: internet-drafts@ietf.org >>>> To: emcho@jitsi.org >>>> CC: justin@uberti.name, ekr@rtfm.com >>>> >>>> >>>> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >>>> has been successfully submitted by Emil Ivov and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-ivov-mmusic-trickle-ice >>>> Revision: 00 >>>> Title: Trickle ICE: Incremental Provisioning of Candidates for the >>>> Interactive Connectivity Establishment (ICE) Protocol >>>> Creation date: 2013-01-28 >>>> WG ID: Individual Submission >>>> Number of pages: 20 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >>>> Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>>> >>>> >>>> Abstract: >>>> This document describes an extension to the Interactive Connectivity >>>> Establishment (ICE) protocol that allows ICE agents to send and >>>> receive candidates incrementally rather than exchanging complete >>>> lists. With such incremental provisioning, ICE agents can begin >>>> connectivity checks while they are still gathering candidates and >>>> considerably shorten the time necessary for ICE processing to >>>> complete. >>>> >>>> The above mechanism is also referred to as "trickle ICE". >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Mon Feb 11 18:07:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB8E21F8790 for ; Mon, 11 Feb 2013 18:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.973 X-Spam-Level: X-Spam-Status: No, score=-8.973 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56os6I5oiViU for ; Mon, 11 Feb 2013 18:07:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0021F87C5 for ; Mon, 11 Feb 2013 18:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=638; q=dns/txt; s=iport; t=1360634843; x=1361844443; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=aptUrqaZw3qDMA3JiRQ3ee+vb/BprJ7EgMUZM2NIGAo=; b=AskNCtAbIxbG9R2rUpvgp+Tbuwf5UJpodS8DMsKv30pCVX0jWr1EV/2I KCOdCdbicjU2NjPxg5bB4hFBDAt+rX443s3PtOfH3rmjikZKqFYsM0Jn0 AoC53xJ4SQltMVulwo7svx6Dl1lEX2HD8qDWHohoWCXvXWeYSEUS9w4nu 4=; X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; d="scan'208";a="71962815" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 12 Feb 2013 02:07:23 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.16.51]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1C27N4p002773; Tue, 12 Feb 2013 02:07:23 GMT Message-ID: <5119A3DB.6000703@cisco.com> Date: Mon, 11 Feb 2013 21:07:23 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Ari Keranen Subject: [MMUSIC] MMUSIC agenda requests for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 02:07:24 -0000 MMUSIC is currently scheduled to meet for a total of 4 hours at IETF 86 in Orlando, Florida. If you want to request a time slot to discuss a draft, please send an e-mail to the chairs. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given drafts that gather attention and discussion in the mailing list prior to the meeting. Thanks -- Ari and Flemming From internet-drafts@ietf.org Tue Feb 12 02:11:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C1521F8BBB; Tue, 12 Feb 2013 02:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu51kYCELWGV; Tue, 12 Feb 2013 02:11:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840A921F8B6B; Tue, 12 Feb 2013 02:11:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212101121.28255.7825.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 02:11:21 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:11:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Filename : draft-ietf-mmusic-sdp-bundle-negotiation-02.txt Pages : 11 Date : 2013-02-12 Abstract: This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation= -02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Tue Feb 12 02:13:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E42521F8943 for ; Tue, 12 Feb 2013 02:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Faa2Ne0XmLHr for ; Tue, 12 Feb 2013 02:13:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4021F8934 for ; Tue, 12 Feb 2013 02:13:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-9d-511a15acc93c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 65.99.10459.CA51A115; Tue, 12 Feb 2013 11:13:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 11:13:00 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: bundle-02 Thread-Index: Ac4JCVtv5wO47PQQQHmj6HqY06uscA== Date: Tue, 12 Feb 2013 10:13:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D7367@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B0D7367ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje5aUalAg5ZuZoupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY+Izq4JtohUtv9awNTB2CXcxcnJICJhIXG+6xwhhi0lcuLee rYuRi0NI4BCjxNyD06CcJYwSV9Y/Yu9i5OBgE7CQ6P6nDdIgIqAu8XVvDzOILSygKtF35SAr RFxL4vi0XmYIW0/i0vK/YHEWoJoJN5ewgdi8At4S+9vWgNmMQIu/n1rDBGIzC4hL3Hoynwni IAGJJXvOM0PYohIvH/9jhbAVJXaebWeGqM+X2NbwA2qmoMTJmU9YJjAKzUIyahaSsllIyiDi OhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAoD+45bfuDsZT50QOMUpz sCiJ84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNhrOHWb6WIbnlrpWXetJjQzvtLI MpiSxlUSa2wet2m2sf/HHslZYpWVt173Pu17vSDenvdQz+cP9ZZGFwyz7tU6KYg5zvbJKOkt 29vQ7+EpfNDw1G9lTTkuhu1Lpp1Uv7Tisr00p9F7f8+jSstWPNh/N/UK44Q5VsGzPJ7o9toZ MCn7bX6UosRSnJFoqMVcVJwIACKDqsBIAgAA Subject: [MMUSIC] Draft new version: bundle-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:13:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B0D7367ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Due to approaching expiration of the previous version, I've submitted a new= version (-02) of draft-bundle. There are no changes since the previous version. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B0D7367ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Due to approaching expiration of the previous versio= n, I’ve submitted a new version (-02) of draft-bundle.

 

There are no changes since the previous version.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B0D7367ESESSMB209ericsso_-- From gonzalo.camarillo@ericsson.com Tue Feb 12 03:45:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0821F8D12; Tue, 12 Feb 2013 03:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g22iBF8FRQmC; Tue, 12 Feb 2013 03:45:06 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD821F8D0B; Tue, 12 Feb 2013 03:45:05 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-09-511a2b40cc22 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.5A.19728.04B2A115; Tue, 12 Feb 2013 12:45:04 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Feb 2013 12:45:04 +0100 Message-ID: <511A2B40.2030408@ericsson.com> Date: Tue, 12 Feb 2013 13:45:04 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJMWRmVeSWpSXmKPExsUyM+Jvja6DtlSgwfX1lhZTlz9msVj7r53d gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZh69uZy2Ywlcx695z5gbGzdxdjJwcEgImEvPnLGKC sMUkLtxbz9bFyMUhJHCSUeJ6QyeUs5pRYsKRN6wgVbwC2hK3Lp1mA7FZBFQltj6fwg5iswlY SGy5dZ8FxBYViJJ4f7WJGaJeUOLkzCdgcREBXYkDmx6D2cICGhIvvk9ig9gsKbFoWidYnFlA T2LK1RZGCFteYvvbOWBzhID2Ln/WwjKBkX8WkrGzkLTMQtKygJF5FSN7bmJmTnq50SZGYGgd 3PJbdQfjnXMihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcVbDFk2vR /mV+aUs2XkubZRj5i8l77+GjJ2/rTzN+LXzPetGcXxFGZyN6Tj37t3GaoM3fZPUt377I7boc IJG+N9Pq+Ioy94T+lRbdbK17HkhL8qeff3bONpPdg3OT/ZPFLXGbVjdHsYmm93Ff/ybmO+/X au9s7h9sAYFNn+7JRv33k/nAdDxJiaU4I9FQi7moOBEAG85bB/sBAAA= Subject: [MMUSIC] Interim meeting and way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 11:45:07 -0000 Folks, first of all, I hope everybody has already managed to get back home after the storm. Also, I want to thank Hadriel and Acme for being great hosts. The information flow, the meeting facilities, the catering, the pullovers, and everything else was just perfect. With respect to the technical work that got done in Boston and, more importantly, that remains to be done, I want to share a few thoughts with the group. A fact that is obvious but some of us sometimes forget about is that RTCWeb, as any other technology, has a window of opportunity. The usefulness and relevance of any standards we develop in this area will be extremely high within that window, but will decrease dramatically if the window closes (e.g., if too many new applications out there are based on non-standard mechanisms). While we have everything in the group to meet the relevant market's deadlines, we should keep them in mind nevertheless. In particular, we are going to be facing cases where *any* decision is better than *no* decision, or where the *perfect* will be the enemy of the *good*. In practical terms, the group should think twice before opening already-made decisions and open them only for very good reasons. Also, the group is going to have to make decisions based on *rough* consensus, as opposed to *wide* consensus or unanimity. This may sound like motherhood and apple pie but I want to stress these points anyway since they are important and need to be kept in mind. For Orlando, I have allocated a *significant* amount of time to RTCWeb and MMUSIC. Those sessions will allow us to take advantage of the momentum we currently have after the interim and to make more progress in all the relevant specifications. Cheers, Gonzalo AD for the RTCWeb and MMUSIC WGs From christer.holmberg@ericsson.com Tue Feb 12 04:04:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCF921F8D2C for ; Tue, 12 Feb 2013 04:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUxCHKDozVhY for ; Tue, 12 Feb 2013 04:04:34 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFB21F8D2B for ; Tue, 12 Feb 2013 04:04:33 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-73-511a2fd0c6cd Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.9B.32353.0DF2A115; Tue, 12 Feb 2013 13:04:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 13:04:32 +0100 From: Christer Holmberg To: Flemming Andreasen , Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] Thread-Index: AQHOBUPYqb7YkJNSREmcN/UBfO3xbphub1aAgAAveICABse7AIAAvyvA Date: Tue, 12 Feb 2013 12:04:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D7481@ESESSMB209.ericsson.se> References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113EBCD.7050901@jitsi.org> <51199BD6.8070606@cisco.com> In-Reply-To: <51199BD6.8070606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje4FfalAg7OdihZrdk5gsXh/Qddi 6vLHLA7MHlN+b2T1WLLkJ5PH/zeBAcxRXDYpqTmZZalF+nYJXBkrj2xnLphsV9G6+xdLA+NB oy5GTg4JAROJ24v2M0PYYhIX7q1n62Lk4hASOMQocf7GekYIZwmjxJbDa4EcDg42AQuJ7n/a IA0iAh4St698ZgOxmQUSJRralrODlAgLJEh8OsAHYooAhQ/2ykJUu0k07lrDBGKzCKhKNLw7 yw5i8wp4S5xbtZQVxBYSuMEoceqeKojNKaApca79O1g9I9Bp309B9DILiEvcejKfCeJkAYkl e85DnS8q8fLxP1YIW1Fi59l2Zoh6PYkbU6dAXaktsWzha2aIvYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkb23MTMnPRy802MwHg5uOW3wQ7GTffFDjFKc7AoifOGu14IEBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cCoxfJwgUXXJ3aNng3rF2vfM9xvs+vzVcM0rdmzY70ei8e4LOA/ lLGtzGJzUELG6nl7ePqXm2dxxTR9TvCMLkgylpbsnpWzYo36vfLCk18/6zo5XBXnEmK+vJzd aOHUa0Wn3P7orgvcIXds/hLRhrUFSa7qhzRqP1asvaN90lv52nmF0/f39KgpsRRnJBpqMRcV JwIABVGZPmUCAAA= Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 12:04:35 -0000 Hi, When a SIP dialog is established, entities normally don't indicate support = for features that they don't want to use within that dialog. However, if the semantics of ice-options is unclear, another alternative is= to define a SIP option-tag, which provides more freedom to specify the sem= antics for individual option-tags. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen Sent: 12. helmikuuta 2013 3:33 To: Emil Ivov Cc: Ari Ker=E4nen; MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a ne= w SIP usage draft.] Hi Emil As noted at the Interim meeting, I think it's cleaner to have ice-options u= sed to strictly indicate features supported, and then have a separate way o= f indicating their use. However, in taking another look at RFC 5245, it's somewhat unclear what sem= antics were intended. Section 15.5 for example suggests "supported"=20 semantics, however Section 21.1.7 suggests "used" semantics. There are a fe= w more examples of each throughout the doc so I agree with you that 5245bis= should clarify this (and depending on that clarification, we should use it= the same way here). Thanks -- Flemming On 2/7/13 1:00 PM, Emil Ivov wrote: > Hey Flemming, Ted, all, > > On 07.02.13, 10:10, Flemming Andreasen wrote: >> 7) It seems the inclusion of the "trickle" ice-options is what will=20 >> trigger the use of tricke-ICE. I think this is a slight overloading=20 >> of the ice-options semantics inasmuch as it is intended to indicate=20 >> support for a given extension, which does not necessarily imply you=20 >> actually want to use that extension. I think it would be useful to=20 >> have a separate way of indicating you also want to use trickle-ICE. > The intention of the current trickle ICE text is to say the following: > > 1. When your (the offerer's) intention is to do half trickle you=20 > include the "trickle" ice-options token and you are prepared to have=20 > the answerer trickling. You are also prepared to have them do vanilla ICE= . > In either case you can either include end-of-candidates in your offer=20 > or you can choose to not include it depending on how you intend to=20 > behave if the answerer turns out to support trickle. > > 1.1. If the answer does indicate support trickle ICE by the answerer,=20 > then you are both abiding by the trickle-ice spec. You can both still=20 > choose to behave like vanilla ICE agents and send complete sets of=20 > candidates from the start but you know that you have to handle trickle=20 > semantics and you know that you have to send end-of-candidates when=20 > you are done. > > 1.2 If the answerer does not support trickle, then there's no "trickle" > ice-options token in the answer and the offerer knows that trickling=20 > is no longer possible (regardless of whether or not there was=20 > end-of-candidates in the offer). > > 2. If the offerer's intention is to generate a vanilla ICE offer then=20 > it does not include the "trickle" ice-options token and everyone just=20 > uses vanilla ICE semantics. > > I believe that this is the part in 5245 that you had a problem with=20 > and I think that this is the text you are referring to: > > First, ICE provides the a=3Dice-options SDP attribute. Each extensi= on > or change to ICE is associated with a token. When an agent > supporting such an extension or change generates an offer or an > answer, it MUST include the token for that extension in this > attribute. *This allows each side to know what the other side is > doing*. This attribute MUST NOT be present if the agent doesn't > support any ICE extensions or changes. > > I am not sure exactly what the intention of this text was (maybe we=20 > could clarify this in 5245bis) but that highlighted part makes me=20 > think the point was to make sure everyone knows what behaviour to=20 > expect rather than what features they have in their ICE stack even if=20 > they are not planning on using them. > > In that sense, if I send what I intend to be a vanilla offer then you=20 > can count on me not to use any trickle semantics and you would make me=20 > really unhappy if you did it yourself (because I might be gateway-ing=20 > your stuff to a vanilla agent). In that sense I'd really like you to=20 > behave as if I were a vanilla ICE agent. > > In other words, I believe it would be legitimate for me not to include=20 > the "trickle" token in ice-options. > > Does this make sense? > > Emil > >> Thanks >> >> -- Flemming >> >> >>> Thanks >>> >>> -- Flemming (as Individual) >>> >>> >>> >>> On 1/30/13 11:38 AM, Emil Ivov wrote: >>>> Hey all, >>>> >>>> Justin, Eric and I have just submitted an update to the trickle ICE=20 >>>> draft, accommodating comments from Atlanta: >>>> >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>>> >>>> More details about the changes here: >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendi >>>> x-B >>>> >>>> Diff2: >>>> http://www.ietf.org/rfcdiff?url1=3Ddraft-rescorla-mmusic-ice-trickle- >>>> 01&difftype=3D--html&submit=3DGo!&url2=3Ddraft-ivov-mmusic-trickle-ice= -00 >>>> >>>> During the MMUSIC presentation and the mailing list discussions it=20 >>>> was also pointed out that it is important for this work to happen=20 >>>> in parallel with a SIP usage for trickle ICE. Enrico, Christer and=20 >>>> I have therefore submitted the following document: >>>> >>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >>>> >>>> As always, comments are welcome! >>>> >>>> Cheers, >>>> Emil >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for=20 >>>> draft-ivov-mmusic-trickle-ice-00.txt >>>> Date: Mon, 28 Jan 2013 11:39:21 -0800 >>>> From: internet-drafts@ietf.org >>>> To: emcho@jitsi.org >>>> CC: justin@uberti.name, ekr@rtfm.com >>>> >>>> >>>> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >>>> has been successfully submitted by Emil Ivov and posted to the IETF=20 >>>> repository. >>>> >>>> Filename: draft-ivov-mmusic-trickle-ice >>>> Revision: 00 >>>> Title: Trickle ICE: Incremental Provisioning of Candidates for the >>>> Interactive Connectivity Establishment (ICE) Protocol >>>> Creation date: 2013-01-28 >>>> WG ID: Individual Submission >>>> Number of pages: 20 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-0 >>>> 0.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >>>> Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-= ice-00 >>>> >>>> >>>> Abstract: >>>> This document describes an extension to the Interactive Connectivi= ty >>>> Establishment (ICE) protocol that allows ICE agents to send and >>>> receive candidates incrementally rather than exchanging complete >>>> lists. With such incremental provisioning, ICE agents can begin >>>> connectivity checks while they are still gathering candidates and >>>> considerably shorten the time necessary for ICE processing to >>>> complete. >>>> >>>> The above mechanism is also referred to as "trickle ICE". >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> . >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Tue Feb 12 08:12:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8321F8E13 for ; Tue, 12 Feb 2013 08:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPOgSa41ulBR for ; Tue, 12 Feb 2013 08:12:48 -0800 (PST) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8221F8DE9 for ; Tue, 12 Feb 2013 08:12:48 -0800 (PST) Received: from userPC (unknown [122.179.50.53]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 86CA73E1B7C; Tue, 12 Feb 2013 16:12:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1360685568; bh=ekRbaTjuh2ImiNz5xqrPOxVKZr2eLEKnR/QiPnciS4s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=CNXV8GIqp9O4d6hXGAePOVstZ+jaP3RyyvAYqx4BmLBQqqkvD6tKT6mUZL3/e/vez ezEsYkFaT1RBDFqJkX0c0Uz8ThNFVEI8Oh/njR+egP5SvMckHyQG9R6q1KA7wAubT4 mIV6u+pXtRRjtfhWMVrrNMXkmsasAu+5aAoZ/oKc= From: "Parthasarathi R" To: Date: Tue, 12 Feb 2013 21:42:40 +0530 Message-ID: <003c01ce093b$cb4e2660$61ea7320$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4JO8ffBI4nCtQNRm+x0Ru8+hPm1A== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0206.511A69FF.01D5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Subject: [MMUSIC] Offer/Answer Considerations for G.723 Annex A and G.729 Annex B draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:12:49 -0000 Hi all, Offer/Answer Considerations for G.723 Annex A and G.729 Annex B draft is written as an update for RFC 4856 offer/answer considerations. The draft was adopted in MMUSIC after a good amount of discussion in Payload WG and MMUSIC WG. Now, All the review comments are incorporated and updated as https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729/. The authors hope that the draft work is complete and ready for WGLC soon. Please let us know in case you have any comments/feedback to the draft. Thanks Partha/Muthu From fluffy@cisco.com Wed Feb 13 06:06:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C9D21F86C4; Wed, 13 Feb 2013 06:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.26 X-Spam-Level: X-Spam-Status: No, score=-110.26 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q8iJsBqn8Si; Wed, 13 Feb 2013 06:06:49 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADA21F86BC; Wed, 13 Feb 2013 06:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7445; q=dns/txt; s=iport; t=1360764407; x=1361974007; h=from:to:subject:date:message-id:references:mime-version; bh=ocjybb0QY4slDZog5GG5rsd897aQHSiXGVVIiJ5Oehs=; b=G/Xcbujz/68XwpMn0afDhwruZmd7NwL2XjaiSbVmy4FgADVaoMd/Xj8o jwwRWLSJPKL1cPTQkI04c5QmgkweIzCMfPecIFTgbb+V2fx9M0fQpPjiY W4aKnyeaUaORnqV4eyctkJamlIcmTwiQ9All+RodXXFJ+cpuxfF/NSdSX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAAudG1GtJV2c/2dsb2JhbAAqGoYHumAWc4IgAQEEgQkCASokMiUCBAEaiAoMLb4xBJEiYQOmd4MGgic X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; d="scan'208,217";a="176412547" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 13 Feb 2013 14:06:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DE6lwo008123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 14:06:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 08:06:46 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" Thread-Topic: Recording of Feb 6 interim meeting Thread-Index: AQHOCfNb73WQHE8ZbUuj1M8OtF7bDg== Date: Wed, 13 Feb 2013 14:06:46 +0000 Message-ID: References: <249625838.2178581360190911147.JavaMail.nobody@rsj6rmd001.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [MMUSIC] Recording of Feb 6 interim meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:06:50 -0000 --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: Your recording is now available on the WebEx service site. Click the link b= elow to play it: https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D65855352&r= Key=3D10997854d4b84af5 WebRTC / RTCWeb / MMusic-20130206 1953-1 Wednesday, February 6, 2013 11:53 am San Francisco Time 2 Hours 52 Minutes --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <59D8E63AF0978B458DE1C1C1EAA63A36@cisco.com> Content-Transfer-Encoding: quoted-printable

Begin forwarded message:

Your recording is now available on the WebEx service site. Click the link below= to play it: 

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID= =3D65855352&rKey=3D10997854d4b84af5 

WebRTC / RTCWeb / MMusic-20130206 1953-1&nb= sp;
Wednesday, February 6, 2013 11:53 am San Francisco Time 
2 Hours 52 Minutes =

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB20Axmbalnx02ciscoc_-- From fluffy@cisco.com Wed Feb 13 06:11:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF321F8605; Wed, 13 Feb 2013 06:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.28 X-Spam-Level: X-Spam-Status: No, score=-110.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbcJU3oR658O; Wed, 13 Feb 2013 06:11:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 516F621F866D; Wed, 13 Feb 2013 06:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7723; q=dns/txt; s=iport; t=1360764670; x=1361974270; h=from:to:subject:date:message-id:references:mime-version; bh=vjHb6dLxNb3hWJ24JAm+CBBS7rDl47wjb1EBeaOmEa8=; b=KCH8aTBC/ayfPcbAL0g0syQZSlPkEENEnEhqKZxbkGxXgNbQl3uoHfJM nfSpBr0D0eRyC4kXNlitprBCv6ejsx5hdv211tvL1+S7Fu5vv4Xxxx52/ JqexSQzyZ9cS3YX+QjBv4zsgGQLtgp1I6HrvNGHZjezRbDHlRBykDuara w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAB2eG1GtJV2c/2dsb2JhbAAqGoYHumAWc4IgAQEEgQkCASokMiUCBAEaiAoMLb4zBJEiYQOmd4MGgic X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; d="scan'208,217";a="176605594" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2013 14:11:09 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DEB9pb013096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 14:11:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 08:11:09 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" , "rtcweb@ietf.org" Thread-Topic: Recording of Feb 7 interim meeting Thread-Index: AQHOCfP42GBEEiij4kmMU7C+TANYJQ== Date: Wed, 13 Feb 2013 14:11:09 +0000 Message-ID: References: <854910216.2305321360270351399.JavaMail.nobody@rsj6rmd001.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [MMUSIC] Recording of Feb 7 interim meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:11:14 -0000 --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your recording is now available on the WebEx service site. Click the link b= elow to play it: https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D65887687&r= Key=3D8c217cc13c9e0ea7 WebRTC / RTCWeb / MMusic-20130207 1348-1 Thursday, February 7, 2013 5:48 am San Francisco Time 7 Hours --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AD1EC2A7AD84E46A45318AD5F9548D0@cisco.com> Content-Transfer-Encoding: quoted-printable

Your recording is now available on the WebEx service site. Click the link below= to play it: 

https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID= =3D65887687&rKey=3D8c217cc13c9e0ea7 

WebRTC / RTCWeb / MMusic-20130207 1348-1&nb= sp;
Thursday, February 7, 2013 5:48 am San Francisco Time 
7 Hours 

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133DB254xmbalnx02ciscoc_-- From ari.keranen@ericsson.com Wed Feb 13 06:14:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B82E21F872C for ; Wed, 13 Feb 2013 06:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rjgq1+V4Z4R for ; Wed, 13 Feb 2013 06:14:24 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB85A21F871F for ; Wed, 13 Feb 2013 06:14:23 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-09-511b9fbee9cf Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 11.AA.32353.EBF9B115; Wed, 13 Feb 2013 15:14:22 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 15:14:22 +0100 Received: from tri62.nomadiclab.com (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2D4A2233F; Wed, 13 Feb 2013 16:14:22 +0200 (EET) Message-ID: <511B9FBD.9010507@ericsson.com> Date: Wed, 13 Feb 2013 16:14:21 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg , Flemming Andreasen , Emil Ivov References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113EBCD.7050901@jitsi.org> <51199BD6.8070606@cisco.com> <7594FB04B1934943A5C02806D1A2204B0D7481@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D7481@ESESSMB209.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje6++dKBBqd/mVms2TmBxeL9BV2L qcsfszgwe0z5vZHVY8mSn0we/98EBjBHcdmkpOZklqUW6dslcGW0rJvNWtDlVvG69Q9LA+Ns yy5GDg4JAROJQ29yuhg5gUwxiQv31rOB2EICJxklPs2J62LkArI3MEpMPnOCFcLZwiixbMck VpAqXgFtiavnjjCC2CwCqhLTz15mArHZBOwlbk64zg5iiwokS3y8cw2qXlDi5MwnLCCDRAQa GSX6f+5hBkkwC6hI7Lt3A2yQsECCxNLP69ghtk1ikmi9/gesiFPAR+Ll+jesEA22EhfmXGeB sOUlmrfOZoa4W1Xi6r9XjBMYhWYhWTgLScssJC0LGJlXMbLnJmbmpJebb2IEhu/BLb8NdjBu ui92iFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbQ0Lz4lzv3d4l13RbW SHLbaNOx/pfXyYBJk1VnhsWWJnOUT/NexL38nfLLzuiLcwOdTR7rlO9la6nr3xzFVdJ6Y16w bKDgIkfdwNtpmSrnkx41rTF7ID/P+/KUUwcd+6dydopMX2zumxnfc/y1cwj7HHuumdPdWye+ q86bsuj21lsMvkxd/UosxRmJhlrMRcWJAEWNWRItAgAA Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:14:25 -0000 Hi, This clearly needs to be clarified in ICE-bis. Regarding which way ("just support" or "support and will use") it should be clarified, we have one precedent. RTP+ECN RFC says (http://tools.ietf.org/html/rfc6679#section-6.4): > The answering party includes this same attribute at the session level > in the SDP answer if it also has the capability and removes the > attribute if it does not wish to use ECN or doesn't have the > capability to use ECN. This seems to imply that it should be "support and will use" to be consistent with current registration(s). And this would be consistent with the current Trickle ICE too. Then, should we have also "ice-supported" attribute, or SIP option-tag, or nothing? I wonder in what case would one use only the "supported"? Would the semantics be "I support but will not use unless you indicate that you want to use", or something else? Cheers, Ari (as individual) On 2/12/13 2:04 PM, Christer Holmberg wrote: > Hi, > > When a SIP dialog is established, entities normally don't indicate > support for features that they don't want to use within that dialog. > > However, if the semantics of ice-options is unclear, another > alternative is to define a SIP option-tag, which provides more > freedom to specify the semantics for individual option-tags. > > Regards, > > Christer > > -----Original Message----- From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 12. helmikuuta 2013 3:33 To: Emil Ivov Cc: Ari Keränen; MMUSIC > IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE > update and a new SIP usage draft.] > > Hi Emil > > As noted at the Interim meeting, I think it's cleaner to have > ice-options used to strictly indicate features supported, and then > have a separate way of indicating their use. > > However, in taking another look at RFC 5245, it's somewhat unclear > what semantics were intended. Section 15.5 for example suggests > "supported" semantics, however Section 21.1.7 suggests "used" > semantics. There are a few more examples of each throughout the doc > so I agree with you that 5245bis should clarify this (and depending > on that clarification, we should use it the same way here). > > Thanks > > -- Flemming > > > On 2/7/13 1:00 PM, Emil Ivov wrote: >> Hey Flemming, Ted, all, >> >> On 07.02.13, 10:10, Flemming Andreasen wrote: >>> 7) It seems the inclusion of the "trickle" ice-options is what >>> will trigger the use of tricke-ICE. I think this is a slight >>> overloading of the ice-options semantics inasmuch as it is >>> intended to indicate support for a given extension, which does >>> not necessarily imply you actually want to use that extension. I >>> think it would be useful to have a separate way of indicating you >>> also want to use trickle-ICE. >> The intention of the current trickle ICE text is to say the >> following: >> >> 1. When your (the offerer's) intention is to do half trickle you >> include the "trickle" ice-options token and you are prepared to >> have the answerer trickling. You are also prepared to have them do >> vanilla ICE. In either case you can either include >> end-of-candidates in your offer or you can choose to not include it >> depending on how you intend to behave if the answerer turns out to >> support trickle. >> >> 1.1. If the answer does indicate support trickle ICE by the >> answerer, then you are both abiding by the trickle-ice spec. You >> can both still choose to behave like vanilla ICE agents and send >> complete sets of candidates from the start but you know that you >> have to handle trickle semantics and you know that you have to send >> end-of-candidates when you are done. >> >> 1.2 If the answerer does not support trickle, then there's no >> "trickle" ice-options token in the answer and the offerer knows >> that trickling is no longer possible (regardless of whether or not >> there was end-of-candidates in the offer). >> >> 2. If the offerer's intention is to generate a vanilla ICE offer >> then it does not include the "trickle" ice-options token and >> everyone just uses vanilla ICE semantics. >> >> I believe that this is the part in 5245 that you had a problem >> with and I think that this is the text you are referring to: >> >> First, ICE provides the a=ice-options SDP attribute. Each >> extension or change to ICE is associated with a token. When an >> agent supporting such an extension or change generates an offer or >> an answer, it MUST include the token for that extension in this >> attribute. *This allows each side to know what the other side is >> doing*. This attribute MUST NOT be present if the agent doesn't >> support any ICE extensions or changes. >> >> I am not sure exactly what the intention of this text was (maybe >> we could clarify this in 5245bis) but that highlighted part makes >> me think the point was to make sure everyone knows what behaviour >> to expect rather than what features they have in their ICE stack >> even if they are not planning on using them. >> >> In that sense, if I send what I intend to be a vanilla offer then >> you can count on me not to use any trickle semantics and you would >> make me really unhappy if you did it yourself (because I might be >> gateway-ing your stuff to a vanilla agent). In that sense I'd >> really like you to behave as if I were a vanilla ICE agent. >> >> In other words, I believe it would be legitimate for me not to >> include the "trickle" token in ice-options. >> >> Does this make sense? >> >> Emil >> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> Thanks >>>> >>>> -- Flemming (as Individual) >>>> >>>> >>>> >>>> On 1/30/13 11:38 AM, Emil Ivov wrote: >>>>> Hey all, >>>>> >>>>> Justin, Eric and I have just submitted an update to the >>>>> trickle ICE draft, accommodating comments from Atlanta: >>>>> >>>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>>>> >>>>> More details about the changes here: >>>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendi >>>>> >>>>> x-B >>>>> >>>>> Diff2: >>>>> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle- >>>>> >>>>> 01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00 >>>>> >>>>> During the MMUSIC presentation and the mailing list >>>>> discussions it was also pointed out that it is important for >>>>> this work to happen in parallel with a SIP usage for trickle >>>>> ICE. Enrico, Christer and I have therefore submitted the >>>>> following document: >>>>> >>>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00 >>>>> >>>>> >>>>> As always, comments are welcome! >>>>> >>>>> Cheers, Emil >>>>> >>>>> -------- Original Message -------- Subject: New Version >>>>> Notification for draft-ivov-mmusic-trickle-ice-00.txt Date: >>>>> Mon, 28 Jan 2013 11:39:21 -0800 From: >>>>> internet-drafts@ietf.org To: emcho@jitsi.org CC: >>>>> justin@uberti.name, ekr@rtfm.com >>>>> >>>>> >>>>> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt >>>>> has been successfully submitted by Emil Ivov and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-ivov-mmusic-trickle-ice Revision: 00 Title: >>>>> Trickle ICE: Incremental Provisioning of Candidates for the >>>>> Interactive Connectivity Establishment (ICE) Protocol >>>>> Creation date: 2013-01-28 WG ID: Individual Submission >>>>> Number of pages: 20 URL: >>>>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-0 >>>>> >>>>> 0.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice >>>>> >>>>> Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00 >>>>> >>>>> >>>>> Abstract: This document describes an extension to the >>>>> Interactive Connectivity Establishment (ICE) protocol that >>>>> allows ICE agents to send and receive candidates >>>>> incrementally rather than exchanging complete lists. With >>>>> such incremental provisioning, ICE agents can begin >>>>> connectivity checks while they are still gathering candidates >>>>> and considerably shorten the time necessary for ICE >>>>> processing to complete. >>>>> >>>>> The above mechanism is also referred to as "trickle ICE". >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ mmusic >>>>> mailing list mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic . >>>>> >>>> >>>> >>>> _______________________________________________ mmusic mailing >>>> list mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > From ron.even.tlv@gmail.com Wed Feb 13 06:25:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8047F21F8712; Wed, 13 Feb 2013 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNsBtbClImsO; Wed, 13 Feb 2013 06:25:28 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 878CE21F86FC; Wed, 13 Feb 2013 06:25:27 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b57so613865eek.4 for ; Wed, 13 Feb 2013 06:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lHTdHM8ZRkYYDXENA/gLhhiAFFqJUkH0zV3iiYLguQY=; b=0S0OVRMPxcMqodquuoRC7HvdhsCsaEQTmpK2Jaa2tMDOcmohMfnauU7mlKchbalpaE +g+uuNvZlhVkuD27ufjCINWxlfS2MawMbU1xx8R4WDnAIMT1E9ZOytgIC7TXDfUVmHdM OWScNlzgsjHVGFEAw/BvrWEvxG2MLpz4miXGpfFejR2Nk8L1B/FwsD1JefyM7AFAd/xo 3VnPB35RR6usqL3LiFFkDhRerhx5VcaSPFtJyTT5p9QQCzdgh3c64Bck4B4uyAYR3Q01 YBbwDzhmyGL45IgGNsh4JTmdQwoVjafm4fOWo0GABlwNigP+mI2g1WlW+ftTTkQCLhkn LSHg== X-Received: by 10.14.183.67 with SMTP id p43mr75202632eem.10.1360765519485; Wed, 13 Feb 2013 06:25:19 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id u44sm13525229eel.7.2013.02.13.06.25.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 06:25:18 -0800 (PST) From: "Roni Even" To: "'Gonzalo Camarillo'" , , "'mmusic'" References: <511A2B40.2030408@ericsson.com> In-Reply-To: <511A2B40.2030408@ericsson.com> Date: Wed, 13 Feb 2013 16:22:09 +0200 Message-ID: <003801ce09f5$84478440$8cd68cc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDGMsj9CFovUr+bUSEmt3Vs6iJBAJqHhNpQ Content-Language: en-us Subject: Re: [MMUSIC] [rtcweb] Interim meeting and way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:25:28 -0000 Hi Gonzalo, Is there a meeting summary from the interim meeting that list the already-made decisions from the interim or are you talking about ones from IETF85? Thanks Roni Even -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: 12 February, 2013 1:45 PM To: rtcweb@ietf.org; mmusic Subject: [rtcweb] Interim meeting and way forward Folks, first of all, I hope everybody has already managed to get back home after the storm. Also, I want to thank Hadriel and Acme for being great hosts. The information flow, the meeting facilities, the catering, the pullovers, and everything else was just perfect. With respect to the technical work that got done in Boston and, more importantly, that remains to be done, I want to share a few thoughts with the group. A fact that is obvious but some of us sometimes forget about is that RTCWeb, as any other technology, has a window of opportunity. The usefulness and relevance of any standards we develop in this area will be extremely high within that window, but will decrease dramatically if the window closes (e.g., if too many new applications out there are based on non-standard mechanisms). While we have everything in the group to meet the relevant market's deadlines, we should keep them in mind nevertheless. In particular, we are going to be facing cases where *any* decision is better than *no* decision, or where the *perfect* will be the enemy of the *good*. In practical terms, the group should think twice before opening already-made decisions and open them only for very good reasons. Also, the group is going to have to make decisions based on *rough* consensus, as opposed to *wide* consensus or unanimity. This may sound like motherhood and apple pie but I want to stress these points anyway since they are important and need to be kept in mind. For Orlando, I have allocated a *significant* amount of time to RTCWeb and MMUSIC. Those sessions will allow us to take advantage of the momentum we currently have after the interim and to make more progress in all the relevant specifications. Cheers, Gonzalo AD for the RTCWeb and MMUSIC WGs _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From gonzalo.camarillo@ericsson.com Wed Feb 13 07:00:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE121F878F; Wed, 13 Feb 2013 07:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBAf1cLBntIx; Wed, 13 Feb 2013 07:00:19 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7811A21F874C; Wed, 13 Feb 2013 07:00:18 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-ac-511baa814733 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.43.19728.18AAB115; Wed, 13 Feb 2013 16:00:17 +0100 (CET) Received: from [131.160.126.60] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 16:00:17 +0100 Message-ID: <511BAA80.6090604@ericsson.com> Date: Wed, 13 Feb 2013 17:00:16 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <511A2B40.2030408@ericsson.com> <003801ce09f5$84478440$8cd68cc0$@gmail.com> In-Reply-To: <003801ce09f5$84478440$8cd68cc0$@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+JvjW7jKulAg56vahZTlz9msfjbzmyx 9l87uwOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CVsenTcqaCdvGK1xcmMDcw7hXqYuTk kBAwkXi8qY8FwhaTuHBvPVsXIxeHkMBJRon9b95BOWsYJU4dOg/kcHDwCmhLXPnkCdLAIqAq cWvOQlYQm03AQmLLrftgg0QFoiTeX21iBrF5BQQlTs58AhYXEVCTeL32MxuIzSygL3Ht6F92 EFtYwFTi88KnTCC2kEC4xKMth8FsTqCZ3/b1M0McJymxaFonC0SvnsSUqy2MELa8xPa3c5gh erUllj9rYZnAKDQLyepZSFpmIWlZwMi8ipE9NzEzJ73caBMjMGQPbvmtuoPxzjmRQ4zSHCxK 4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBy8BgnGwUwTr37IC4ubPWu8Nnbu39K SPPw856+KJukkbi+3CPls13ByhgP/2+/vZrc+pkDDIRCkqpWTFFlOyuZe2fmM9cNc2Ufz3xr Mv2EXuLNhHiPCr4ZG9UtG3x8LkU2+V5R/x5TO3md2rQnjmKqy8KMlqnH8U+W/W/aNmd/fu7G TRb72ZVYijMSDbWYi4oTAa8/sBcnAgAA Cc: rtcweb@ietf.org, 'mmusic' Subject: Re: [MMUSIC] [rtcweb] Interim meeting and way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:00:24 -0000 Hi Roni, at this point, I am talking in general and strategically, not about any decision in particular. Which particular topics would benefit from the suggestions below and which wouldn't should be kind-of obvious to anyone who is somewhat involved in the technical work. Also, as usual, the technical discussions on individual topics will be moderated and facilitated by the chairs. Thanks, Gonzalo On 13/02/2013 4:22 PM, Roni Even wrote: > Hi Gonzalo, > Is there a meeting summary from the interim meeting that list the > already-made decisions from the interim or are you talking about ones from > IETF85? > Thanks > Roni Even > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Gonzalo Camarillo > Sent: 12 February, 2013 1:45 PM > To: rtcweb@ietf.org; mmusic > Subject: [rtcweb] Interim meeting and way forward > > Folks, > > first of all, I hope everybody has already managed to get back home after > the storm. Also, I want to thank Hadriel and Acme for being great hosts. The > information flow, the meeting facilities, the catering, the pullovers, and > everything else was just perfect. > > With respect to the technical work that got done in Boston and, more > importantly, that remains to be done, I want to share a few thoughts with > the group. > > A fact that is obvious but some of us sometimes forget about is that RTCWeb, > as any other technology, has a window of opportunity. The usefulness and > relevance of any standards we develop in this area will be extremely high > within that window, but will decrease dramatically if the window closes > (e.g., if too many new applications out there are based on non-standard > mechanisms). > > While we have everything in the group to meet the relevant market's > deadlines, we should keep them in mind nevertheless. In particular, we are > going to be facing cases where *any* decision is better than *no* decision, > or where the *perfect* will be the enemy of the *good*. > > In practical terms, the group should think twice before opening already-made > decisions and open them only for very good reasons. Also, the group is going > to have to make decisions based on *rough* consensus, as opposed to *wide* > consensus or unanimity. This may sound like motherhood and apple pie but I > want to stress these points anyway since they are important and need to be > kept in mind. > > For Orlando, I have allocated a *significant* amount of time to RTCWeb and > MMUSIC. Those sessions will allow us to take advantage of the momentum we > currently have after the interim and to make more progress in all the > relevant specifications. > > Cheers, > > Gonzalo > AD for the RTCWeb and MMUSIC WGs > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From magnus.westerlund@ericsson.com Wed Feb 13 07:07:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DA921F8717; Wed, 13 Feb 2013 07:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.681 X-Spam-Level: X-Spam-Status: No, score=-105.681 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcbLbi-+xuKM; Wed, 13 Feb 2013 07:07:22 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7A21F870E; Wed, 13 Feb 2013 07:07:20 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-7d-511bac27e27c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 38.12.32353.72CAB115; Wed, 13 Feb 2013 16:07:19 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 16:07:19 +0100 Message-ID: <511BAC25.8020501@ericsson.com> Date: Wed, 13 Feb 2013 16:07:17 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <510A4B7C.3000009@ericsson.com> <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280477C368@xmb-aln-x08.cisco.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvja76GulAg/f3JSw2zfrCZjF1+WMW i7X/2tkdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErozDz7+xFhySrvjQO5m5gXGyWBcj J4eEgInEnceLWSFsMYkL99azdTFycQgJnGSUuHCuD8pZziix9MNBRpAqXgFtiZdz25lBbBYB VYlXyzaCxdkELCRu/mhkA7FFBYIlNhxcxQRRLyhxcuYTFhBbRMBQYtGkdWA2s4C/RNe1qWC2 sICvxJUpG8HqhQRyJK5+2wk2kxMo/m/3P6CZHEDXiUusecMB0aonMeVqCyOELS/RvHU2M0Sr tkRDUwfrBEahWUg2z0LSMgtJywJG5lWM7LmJmTnp5eabGIFBe3DLb4MdjJvuix1ilOZgURLn DXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMbJDskWDbb6T+szbVeIhM1cs1qs4eMJy 24NlVfyyzA6FE6dedP4WFSnmu+xV2c3DeyyELVKY9+qasU1IbA2YMtlySobk00maK8+FnI52 PJzspq79dM8ZQXbuBJXX3IK6b1bI7ImfWT6T+8WZiA2/jJ5fvjxnSdI/z53HzDdM/fj00jdl Dekdz5RYijMSDbWYi4oTAT6j33MoAgAA Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] Draft on Multimedia concepts and relations for Intermim X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:07:26 -0000 Hi Charles, Lets respond to your questions. On 2013-02-05 03:28, Charles Eckel (eckelcu) wrote: > Hi Magnus and Bo, > > Thanks for putting this together, and more importantly, for attaching > a copy in the e-mail so I was able to access it on the plane without > internet. I agree with most of the reasoning in the various sections; > however, there are a couple related concepts for which I'd like more > clarification. > > 1) MediaStream Is a MediaStream restricted to a single source? I did > not think it was, but the description on page 8 seems to imply this > restriction. For example, could I have a single MediaStream with the > following 4 MediaStreamTracks, where source 1 and source 2 are two > video cameras from the same endpoint, or a mic and an camera from the > same endpoint: > > > Source 1 - encoding 1 > Source 1 - encoding 2 > Source 2 - encoding 1 > Source 2 - encoding 2 No, MediaStream is definitely not restricted to a single Media source. In fact a common MediaStream will contain one MediaStreamTrack with an audio source, and another MediaStreamTrack with Video. Thus two different media sources. Your example above gets us into I think land where discussion is ongoing and agreement needs to be established. From my perspective there need to be a way of dealing with control of encoding and and a plan for different encodings of the same media source. If that is achieved by having multiple MediaStreamTracks of the same media source, having multiple MediaStreams with the same set of MediaStreamTracks but different encoding settings, or explicit encoding settings within a MediaStram and MediaStreamTrack or having them tied to the PeerConnection is a choice that needs to happen. They have different impact on differnt parts, but we really need to make a choice here. > > 2) PeerConnection Later, on page 18, a related restriction of a > single encoding per PC is suggested. In the case of a layered > encoding, this seems to imply each layer being in its own PC. Is that > the recommendation being suggested? For layered encoding this proposal is far from optimal. It works for simulcast where having different RTP streams each carrying a different encoding is fine. Thus we proposed it as a solution which appeared to require minimal impact with some simple restrictions regarding usage of CNAME, i.e. same CNAME for both SSRC, even if they are in different RTP sessions due to the different PeerConnections. I assume for layering that one like to be able to send the layers in a single RTP stream. When it comes to layering and simulcast I think the first step is actually to agree on requirements level. Are we supporting it from start, are we at least having it on the future road-map to avoid solutions which makes it difficult to add in the future? I have gotten the impression that a number of different people have interest in it. Maybe not to implement it immediately, but at least have a plan for how it should be included. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Wed Feb 13 11:48:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2566A21F852C; Wed, 13 Feb 2013 11:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5xTray9j16D; Wed, 13 Feb 2013 11:48:27 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8621F8530; Wed, 13 Feb 2013 11:48:25 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-81-511bee0810c6 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.FA.32353.80EEB115; Wed, 13 Feb 2013 20:48:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 20:48:24 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: BUNDLE: RTP only? Thread-Index: Ac4KIxU5eB8ChmgfTeKF683MxdSffg== Date: Wed, 13 Feb 2013 19:48:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjS7nO+lAg63nGC2mLn/MYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyTt9/xlgwl7WiuX0OSwNjH0sXIyeHhICJxMJrF5kh bDGJC/fWs3UxcnEICRxilGjddoUVJCEksIRR4vOz9C5GDg42AQuJ7n/aIGERAR+Jr1OWgfUK C0hJbLo+jxEiLi9xfd18JghbT2L14+9gNouAqkTLjIlsIDavgLfE0V8HwHoZgfZ+P7UGrIZZ QFzi1hOIXgkBAYkle85D3SYq8fLxP1aQEyQEFCWW98tBlOtILNj9iQ3C1pZYtvA1M8R4QYmT M5+wTGAUnoVk6iwkLbOQtMxC0rKAkWUVI3tuYmZOern5JkZgMB/c8ttgB+Om+2KHGKU5WJTE ecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNxY/jL3ziQDxbo3f2pM9/Nuqk1U9DSs XMR8ff2sL7olmkqpCbLbNGdaHs7ccCkrUDPZ/rXR/XSpHbwb0vMesL8oEuAr6eKR6mTr3lJg kW3zKS7s2jbvT88U/Z8t/P2vwPWAXlTSSulLGw0PPv7kvGNnub6GD3P3/kXx1x//tpeQl/e0 KtYIVWIpzkg01GIuKk4EANavOhQ0AgAA Subject: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:48:28 -0000 (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to bot= h the need of RTCWEB, and the solution produced by MMUSIC) Hi, At the interim, during my BUNDLE presentation, I indicated that we need to = make a decision whether the solution (whatever it will be...) shall support= bundling of non-RTP media. Not saying it can't be changed, but as currentl= y documented all alternatives only support bundling of RTP media. There might have been some comments from the mic, but as far as I know ther= e was no decision (if there was, please point me to it). So, my question is: do we keep the scope to RTP media? Regards, Christer= From pkyzivat@alum.mit.edu Wed Feb 13 12:06:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE10A21E805D for ; Wed, 13 Feb 2013 12:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4GN1FSmsN7P for ; Wed, 13 Feb 2013 12:06:03 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id EB01321E8054 for ; Wed, 13 Feb 2013 12:06:02 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id zpGS1k00E1vXlb853w62CM; Wed, 13 Feb 2013 20:06:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id zw621k00Y3ZTu2S3dw62Wa; Wed, 13 Feb 2013 20:06:02 +0000 Message-ID: <511BF229.1090702@alum.mit.edu> Date: Wed, 13 Feb 2013 15:06:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360785962; bh=9x2saBA7f8+4hGgaXmh/+ll1fITMvAE9pjPzSKgcsto=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=elflreUIgHjkBM+66D2N4DR3sbzqF6lY/LolhWDtenaa11fQ9On0R9IsjJLVEo8OO RvMSCRAgCSGtRHseowd+g9IWkMbakmeEhvf/SHdWCYGbYU74gPi2AseUpfq/qtzVrH bKSdOYhiaT+az0qhrxANQEPJu7KXH9HFk0KY0xSs97wxgO7LvKlOIqjXCLYIrsLXhV WyYLDPmp4bAB377oUFJGDMiJ5+AL96kbHtnOLWhzr2UvK3PAx5ggpCYcDisMxST1ol ue69TPYCqPCHp8ROKEXmPMFN0o7SfkzWXf072U7zFdt3wr5XJ1wKIJ7Ji8SGQcuSMY CYOofWYtOlEnw== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:06:03 -0000 On 2/13/13 2:48 PM, Christer Holmberg wrote: > > (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to both the need of RTCWEB, and the solution produced by MMUSIC) > > Hi, > > At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media. > > There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it). > > So, my question is: do we keep the scope to RTP media? *If* there is a goal to share a single 5-tuple between RTP and SCTP then we need a solution allows bundling them. The key to what you can bundle together is not whether it is RTP or not. It is whether you can specify the mechanism for demuxing the 5-tuple and associated the parts with the appropriate m-line in the bundle. Thanks, Paul From christer.holmberg@ericsson.com Wed Feb 13 12:08:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30521F862B for ; Wed, 13 Feb 2013 12:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+YjetV0mkqc for ; Wed, 13 Feb 2013 12:08:12 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6429321F84F5 for ; Wed, 13 Feb 2013 12:08:10 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-69-511bf2a64d86 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AE.EB.32353.6A2FB115; Wed, 13 Feb 2013 21:08:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 21:08:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: RTP only? Thread-Index: Ac4KIxU5eB8ChmgfTeKF683MxdSffv//9CiAgAAQ/a8= Date: Wed, 13 Feb 2013 20:08:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> In-Reply-To: <511BF229.1090702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje6yT9KBBt27hS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjaXtKwV7OirUfe5kbGDeydzFyckgImEis vbeQEcIWk7hwbz1bFyMXh5DAIUaJp5s3M0I4Sxgl7m9oZu5i5OBgE7CQ6P6nDdIgIuAr8ezx bTYQW1hAXWL25g3sEHENiVPP77FA2FYSDbffgC1gEVCV2LVrLVg9r4C3RP+UFrAaIYFsiSd3 d4PVcAroSNyZeQNsDiPQQd9PrWECsZkFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7GCnCYhoCix vF8OolxHYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj6CwkU2chaZmFpGUWkpYFjCyrGNlzEzNz 0svNNzEC4+Dglt8GOxg33Rc7xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6P8nSNvYw9Z27AouurO5uVg/XjDxkw0Ifjzrb3q8yPne98xiggMTH2xIeRAz2s2vSdHkxyk 77zx91wZZ9JZeuV128OLT7ynP3Dd9fKqwMnULe/uHcnVstJ00JlkxfFV56JSzylRq9mLp7Aw 5Ziv2NKWJnbG/mfaYbPTi92fnJt0rmjZFTZrkV1KLMUZiYZazEXFiQDruVJ5UQIAAA== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:08:13 -0000 Hi, >> (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to = both the need of RTCWEB, and the solution produced by MMUSIC) >> >> Hi, >> >> At the interim, during my BUNDLE presentation, I indicated that we need = to make a decision whether the solution (whatever it will be...) shall supp= ort bundling of non-RTP media. Not saying it can't be changed, but as curre= ntly documented all alternatives only support bundling of RTP media. >> >> There might have been some comments from the mic, but as far as I know t= here was no decision (if there was, please point me to it). >> >> So, my question is: do we keep the scope to RTP media? > > *If* there is a goal to share a single 5-tuple between RTP and SCTP then > we need a solution allows bundling them. That's another way of presenting my question, yes :) > The key to what you can bundle together is not whether it is RTP or not. > It is whether you can specify the mechanism for demuxing the 5-tuple and > associated the parts with the appropriate m-line in the bundle. Yes, and the question is whether we need to perform the exercise to look in= to that, or if we focus on RTP. Regards, Christer From fluffy@cisco.com Wed Feb 13 12:37:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910921E8064; Wed, 13 Feb 2013 12:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weXfTUFS6MpA; Wed, 13 Feb 2013 12:37:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DC21E8055; Wed, 13 Feb 2013 12:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1065; q=dns/txt; s=iport; t=1360787863; x=1361997463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yDQyfEh9wl2MUgutnT7/ceetg9OC+8Mku4WZez/JGd0=; b=MNsEIJTavk1FfbIR7STJ3uaDerRaEyq0cGjE5mwAK6FeLwy3UVshwpwU ypCXbiUEpFgSZDLQQ0T/4BkoDbcvzBW2xfCFkVWP3wyLhbL6ScVg8I2CL 6S3mxn9NgiDgp1YrSngi7Ygdbh+Myb/Dw629SVhCxlURW+a4r/qjr/WX8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG/4G1GtJXG8/2dsb2JhbABFwG4Wc4IgAQEEAQEBNzQLEAIBCCIUECcLJQIEDgUIE4d3DL9EBJEjYQOmd4MGgic X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176830057" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Feb 2013 20:37:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1DKbg6V010889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 20:37:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 14:37:42 -0600 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: RTP only? Thread-Index: AQHOCin4yriVbi3BTkiuqlV2yqiiBw== Date: Wed, 13 Feb 2013 20:37:42 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:37:44 -0000 I think EKR expressed that he felt it was important for data channel to be = included in the multiplexing.=20 On Feb 13, 2013, at 12:48 PM, Christer Holmberg wrote: >=20 > (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to b= oth the need of RTCWEB, and the solution produced by MMUSIC) >=20 > Hi, >=20 > At the interim, during my BUNDLE presentation, I indicated that we need t= o make a decision whether the solution (whatever it will be...) shall suppo= rt bundling of non-RTP media. Not saying it can't be changed, but as curren= tly documented all alternatives only support bundling of RTP media. >=20 > There might have been some comments from the mic, but as far as I know th= ere was no decision (if there was, please point me to it). >=20 > So, my question is: do we keep the scope to RTP media? >=20 > Regards, >=20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From randell-ietf@jesup.org Wed Feb 13 12:44:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1621F85F0; Wed, 13 Feb 2013 12:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEgGniJjaNYK; Wed, 13 Feb 2013 12:44:38 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30521F85C0; Wed, 13 Feb 2013 12:44:38 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4463 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U5jC2-0000XQ-0u; Wed, 13 Feb 2013 14:44:38 -0600 Message-ID: <511BFAB7.4060303@jesup.org> Date: Wed, 13 Feb 2013 15:42:31 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org, mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:44:39 -0000 On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote: > I think EKR expressed that he felt it was important for data channel to be included in the multiplexing. And I agree(d), strongly. We want 1 port to minimize NAT issues and startup times. > > At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media. > > There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it). > > So, my question is: do we keep the scope to RTP media? > -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Wed Feb 13 13:30:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6978521F8A98 for ; Wed, 13 Feb 2013 13:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht1dBDjyJCqe for ; Wed, 13 Feb 2013 13:30:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BB60421F8A8B for ; Wed, 13 Feb 2013 13:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1035; q=dns/txt; s=iport; t=1360791006; x=1362000606; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DH4ONi7IYHyctS22qpnxNPbwsBEniy8XFo+dPhfyirQ=; b=hLwP+uquAvVC64q+GJJHlPnPsv8Uwm8aJs85kmO9igEQW9Xy2sMxz7FQ Yp5kgEfWMB271xwCiiXQQCQSRntokkWcv+JJQGAEHGcHiPG6w4JI3ShNG CmTvadH6sUXVwZZw9oOfpE9r/bMVEoAKw+ThXXiC86ueviHi0Y9hCkKb3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGoFHFGtJXG9/2dsb2JhbABFwG8Wc4IfAQEBAwE6PwULAgEIIhQQMiUCBA4FCIgEBr9SkSNhA6Z3gwaCJw X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176781950" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2013 21:30:06 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1DLU66k025252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 21:30:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 15:30:06 -0600 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [MMUSIC] Requirements for Bundle, Fumble etc. Thread-Index: AQHOCjFJ648flA7PcEmfEoFt9/4PBw== Date: Wed, 13 Feb 2013 21:30:05 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:30:07 -0000 On Feb 8, 2013, at 8:01 PM, "Hutton, Andrew" wrote: > Hi, >=20 > I suggest that the requirements discussed at the interim (http://www.ietf= .org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcwe= b-1-10.pdf) regarding bundling on to a single 5-tuple need the following ad= ditional requirements. >=20 > 1. Must work for a dual stack client when ICE candidates are used for add= ress family negotiation. I think this is interesting because in this scenar= io there will of course be different candidates for each address family and= we will probably need some rules to make sure this works. >=20 > 2. Must work when a TURN server is used. This is interesting because alth= ough a single TURN allocation will be needed for the bundled candidates it = will I assume be necessary to do additional TURN allocations just in case t= he peer does not support bundle. >=20 > Regards > Andy=20 +1 makes sense to me. Now if only I had read this before up From ekr@rtfm.com Wed Feb 13 13:49:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979EA21E803D for ; Wed, 13 Feb 2013 13:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oH+1yW6RIj0 for ; Wed, 13 Feb 2013 13:49:11 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id D85FE21E808C for ; Wed, 13 Feb 2013 13:49:10 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id a22so639488qcs.12 for ; Wed, 13 Feb 2013 13:49:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=bZNR1yLLbNONO+3G9vNQGv8qHfCRt/OsmO+SO/F+ti4=; b=KQgeL5HmJ2kTnxGnoIujPsKVWxoP/QfSWsRYozHUEjL2+KK+rJqBoZaEc34A3Iyzh2 YzBrCodFTArYZRq/ng/rHVB2MpQMRLRIDPf2nb/tc94yxtVHYoX6V1HkTCTuUfFREYKf VVof/Bk5OnCIrJJ1Rg9H9AUPgF1RhmOivlNAqDi/+hUdFyfoHxUKbZPxtuFeEhjWmsiE 6PxQ9zp8rvWSkgxasZ/slgmFEFtHWcJPg0zO6KjMUx0oJZ+AeLIqHbC7OKiJExaUSIYs wPeELb9l1CciL75SJJ9LILnf+NJTogbcjQdjvVxr0oGTfWB/GsrMNPlBlimhUuVWlVBF wW+A== X-Received: by 10.224.59.134 with SMTP id l6mr9084630qah.93.1360792150314; Wed, 13 Feb 2013 13:49:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.130.198 with HTTP; Wed, 13 Feb 2013 13:48:30 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <511BFAB7.4060303@jesup.org> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BFAB7.4060303@jesup.org> From: Eric Rescorla Date: Wed, 13 Feb 2013 13:48:30 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=20cf3068447dbb90b404d5a21c41 X-Gm-Message-State: ALoCoQkRk7SwgxfZwD9bn7aO1NvT4A+faVszibhUxNMgoa2FT+VJvkLmfEONpiZwDW8Oo5746zWt Cc: rtcweb@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:49:11 -0000 --20cf3068447dbb90b404d5a21c41 Content-Type: text/plain; charset=ISO-8859-1 I would phrase this somewhat less strongly: less ports is better than more ports, so all things being equal, a multiplexing mechanism that keeps you down to one port is better than not. That said, if we decide that plan A is dead and we are going to plan B, I can live with having data on a separate port. -Ekr On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup wrote: > On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote: > >> I think EKR expressed that he felt it was important for data channel to >> be included in the multiplexing. >> > > And I agree(d), strongly. We want 1 port to minimize NAT issues and > startup times. > > > >> At the interim, during my BUNDLE presentation, I indicated that we need >> to make a decision whether the solution (whatever it will be...) shall >> support bundling of non-RTP media. Not saying it can't be changed, but as >> currently documented all alternatives only support bundling of RTP media. >> >> There might have been some comments from the mic, but as far as I know >> there was no decision (if there was, please point me to it). >> >> So, my question is: do we keep the scope to RTP media? >> >> > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf3068447dbb90b404d5a21c41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would phrase this somewhat less strongly: less ports is better than more = ports,
so all things being equal, a multiplexing mechanism that keeps y= ou down to
one port is better than not. That said, if we decide t= hat plan A is dead and
we are going to plan B, I can live with having data on a separate port= .

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup &= lt;randell-ietf= @jesup.org> wrote:
On 2/13/2013 3:37 PM, Cullen Jennings (= fluffy) wrote:
I think EKR expressed that he felt it was important for data channel to be = included in the multiplexing.

And I agree(d), strongly. =A0We want 1 port to minimize NAT issues and star= tup times.



At the interim, during my BUNDLE presentation, I indicated that we need to = make a decision whether the solution (whatever it will be...) shall support= bundling of non-RTP media. Not saying it can't be changed, but as curr= ently documented all alternatives only support bundling of RTP media.

There might have been some comments from the mic, but as far as I know ther= e was no decision (if there was, please point me to it).

So, my question is: do we keep the scope to RTP media?


--
Randell Jesup
randell-ietf@je= sup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3068447dbb90b404d5a21c41-- From bernard_aboba@hotmail.com Wed Feb 13 14:24:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5958711E80A3; Wed, 13 Feb 2013 14:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.921 X-Spam-Level: X-Spam-Status: No, score=-100.921 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLEjcGxFGWIU; Wed, 13 Feb 2013 14:24:02 -0800 (PST) Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9A46311E809C; Wed, 13 Feb 2013 14:24:02 -0800 (PST) Received: from BLU402-EAS53 ([65.55.111.137]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Feb 2013 14:24:02 -0800 X-EIP: [i2ME+56uDtkFcVuSHdrAPNS+6fBXn6qm] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_d31fe700-cd39-4a01-bdb8-08db532a2a1c_" References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BFAB7.4060303@jesup.org> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 13 Feb 2013 14:24:00 -0800 To: Eric Rescorla X-OriginalArrivalTime: 13 Feb 2013 22:24:02.0139 (UTC) FILETIME=[D36522B0:01CE0A38] Cc: Randell Jesup , "rtcweb@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:24:03 -0000 --_d31fe700-cd39-4a01-bdb8-08db532a2a1c_ Content-Type: multipart/alternative; boundary="Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8" Content-Transfer-Encoding: 7bit --Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A question:=20 Since we have a clear way of de-multiplexing RTP and DTLS, is it necessary t= o entangle that (solved) problem with the A/V mux issue? I realize that SDP h= as the tendency to "deeply intermingle" just about everything, but at the RT= P/DTLS level, we're in much better shape. Bernard "Do we need to boil the entire ocean, or just a lake or two?" Aboba On Feb 13, 2013, at 13:49, "Eric Rescorla" wrote: > I would phrase this somewhat less strongly: less ports is better than more= ports, > so all things being equal, a multiplexing mechanism that keeps you down to= > one port is better than not. That said, if we decide that plan A is dead a= nd > we are going to plan B, I can live with having data on a separate port. >=20 > -Ekr >=20 > On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup w= rote: >> On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote: >>> I think EKR expressed that he felt it was important for data channel to b= e included in the multiplexing. >>=20 >> And I agree(d), strongly. We want 1 port to minimize NAT issues and star= tup times. >>=20 >>=20 >>>=20 >>> At the interim, during my BUNDLE presentation, I indicated that we need t= o make a decision whether the solution (whatever it will be...) shall suppor= t bundling of non-RTP media. Not saying it can't be changed, but as currentl= y documented all alternatives only support bundling of RTP media. >>>=20 >>> There might have been some comments from the mic, but as far as I know t= here was no decision (if there was, please point me to it). >>>=20 >>> So, my question is: do we keep the scope to RTP media? >>=20 >> --=20 >> Randell Jesup >> randell-ietf@jesup.org >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
A question: 

Since we have a clear way of de-multiplexing RTP and DTLS, is it necessary to entangle that (solved) problem with the A/V mux issue? I realize that SDP has the tendency to "deeply intermingle" just about everything, but at the RTP/DTLS level, we're in much better shape.

Bernard "Do we need to boil the entire ocean, or just a lake or two?" Aboba

On Feb 13, 2013, at 13:49, "Eric Rescorla" <ekr@rtfm.com> wrote:

I would phrase this somewhat less strongly: less ports is better than more ports,
so all things being equal, a multiplexing mechanism that keeps you down to
one port is better than not. That said, if we decide that plan A is dead and
we are going to plan B, I can live with having data on a separate port.

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 2/13/2013 3:37 PM, Cullen Jennings (fluffy) wrote:
I think EKR expressed that he felt it was important for data channel to be included in the multiplexing.

And I agree(d), strongly.  We want 1 port to minimize NAT issues and startup times.



At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media.

There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it).

So, my question is: do we keep the scope to RTP media?


--
Randell Jesup
randell-ietf@jesup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-35268A49-A144-4EBD-AB0C-9E103FB1D3F8-- --_d31fe700-cd39-4a01-bdb8-08db532a2a1c_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_d31fe700-cd39-4a01-bdb8-08db532a2a1c_-- From pkyzivat@alum.mit.edu Wed Feb 13 19:15:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF821F8783 for ; Wed, 13 Feb 2013 19:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIu5jyfYfoNL for ; Wed, 13 Feb 2013 19:15:26 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1F21F879A for ; Wed, 13 Feb 2013 19:15:25 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id zyt71k0010EZKEL513FQda; Thu, 14 Feb 2013 03:15:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 03FP1l00R3ZTu2S3M3FPjt; Thu, 14 Feb 2013 03:15:24 +0000 Message-ID: <511C56CB.1080609@alum.mit.edu> Date: Wed, 13 Feb 2013 22:15:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360811724; bh=vb2P+IQTT8+TMjgS02X8IWuvH62g8fGSlSIz2wTXERk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iJ2Mt5uwoAyo5uqX9eedb/ce6iInXY+uCVxs50TEgpEKLozwUPupe/PP7SpxzWWZs NFXZvJwuFSy4y9AVZrlJFgKkB37Z13BVX9gP5bBKuCPXdf+p9g3alLnVoXPqadkZcc BxhmkBFcFAKN8Bp/FBruIta+RXo3LyTF7H/svIdRzTZpAJXKT/pgGmg2ygz1UEMjLD PfbW++QhFJIOFO1NssNaCMHxTJgHaDX7b0WHt4WiCNMM+gxo0C63xC0600eHe7msL9 wUfV35Y0XIRtQBJx3qWR7DCQqtbb/l5ptyNdgxU4zdQqWebPEx1WYWeLfzqfNQWGmj 4d9wa5nhqBFpA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 03:15:26 -0000 On 2/13/13 3:08 PM, Christer Holmberg wrote: > > Hi, > >>> (Sorry for sending this to both RTCWEB and MMUSIC, but it is related to both the need of RTCWEB, and the solution produced by MMUSIC) >>> >>> Hi, >>> >>> At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media. >>> >>> There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it). >>> >>> So, my question is: do we keep the scope to RTP media? >> >> *If* there is a goal to share a single 5-tuple between RTP and SCTP then >> we need a solution allows bundling them. > > That's another way of presenting my question, yes :) > >> The key to what you can bundle together is not whether it is RTP or not. >> It is whether you can specify the mechanism for demuxing the 5-tuple and >> associated the parts with the appropriate m-line in the bundle. > > Yes, and the question is whether we need to perform the exercise to look into that, or if we focus on RTP. We know how to do the demux between DTLS payloads, ICE, and RTP/SRTP payloads. And if we restrict to RTP/SRTP and SCTP over DTLS, then we know how to demux RTP and SCTP. There are various schemes that can be used to demux multiple RTP streams and associate them with individual m-lines in the bundle. What troubles me about it is that the rules for what you can bundle together are dependent on the demux strategy. Describing the rules for this as part of the specification of the bundling mechanism is going to be pretty ugly. I don't see any way to make it clean and elegant. Thanks, Paul From bernard_aboba@hotmail.com Wed Feb 13 20:27:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A2E21F85EA; Wed, 13 Feb 2013 20:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDB-S6iPWJjE; Wed, 13 Feb 2013 20:27:20 -0800 (PST) Received: from blu0-omc1-s2.blu0.hotmail.com (blu0-omc1-s2.blu0.hotmail.com [65.55.116.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6739D21F85E7; Wed, 13 Feb 2013 20:27:20 -0800 (PST) Received: from BLU002-W89 ([65.55.116.7]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Feb 2013 20:27:19 -0800 X-EIP: [gPesUQo542AzKrhazAfSa5MAS81xTxJB] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1a405a2f-3e15-4def-b782-a5651947f2be_" From: Bernard Aboba To: Gonzalo Camarillo , "rtcweb@ietf.org" , mmusic Date: Wed, 13 Feb 2013 20:27:19 -0800 Importance: Normal In-Reply-To: <511A2B40.2030408@ericsson.com> References: <511A2B40.2030408@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2013 04:27:19.0476 (UTC) FILETIME=[939ECF40:01CE0A6B] Subject: Re: [MMUSIC] [rtcweb] Interim meeting and way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 04:27:21 -0000 --_1a405a2f-3e15-4def-b782-a5651947f2be_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good thoughts=2C Gonzalo. I share your concern about the rate of progress.= However=2C I do not believe that the solution is to allocate more time. = If that were true then we would all be feeling a lot better after three day= s of work at the interim. IMHO=2C there is no amount of effort that can pr= oduce movement on this set of problems without getting better clarity on th= e context of the discussions and the process by which we get to consensus. = =20 One observation from the interim (and other previous meetings) is that ther= e is not a consistent understanding of the *context* for making decisions= =2C and what the definition of "consensus" is. IMHO=2C there is a world of= difference between asking for consensus on the solution to a set of proble= ms in the context of RTCWEB=2C versus setting the context to be within the = scope of MMUSIC {e.g. applicable to RTCWEB=2C CLUE and possible other WGs t= oo}. If the context is RTCWEB=2C we have a use case document to help us u= nderstand the requirements the WebRTC protocols and APIs=3B if it is MMUSI= C=2C then the set of requirements is not obvious (at least by me) and we sh= ould not be surprised if the group cannot come to consensus.=20 With respect to understanding of the nature of "consensus" in the IETF=2C P= ete Resnick has recently published an I-D which is well worth reading:=20 http://tools.ietf.org/html/draft-resnick-on-consensus > Date: Tue=2C 12 Feb 2013 13:45:04 +0200 > From: Gonzalo.Camarillo@ericsson.com > To: rtcweb@ietf.org=3B mmusic@ietf.org > Subject: [rtcweb] Interim meeting and way forward >=20 > Folks=2C >=20 > first of all=2C I hope everybody has already managed to get back home > after the storm. Also=2C I want to thank Hadriel and Acme for being great > hosts. The information flow=2C the meeting facilities=2C the catering=2C = the > pullovers=2C and everything else was just perfect. >=20 > With respect to the technical work that got done in Boston and=2C more > importantly=2C that remains to be done=2C I want to share a few thoughts > with the group. >=20 > A fact that is obvious but some of us sometimes forget about is that > RTCWeb=2C as any other technology=2C has a window of opportunity. The > usefulness and relevance of any standards we develop in this area will > be extremely high within that window=2C but will decrease dramatically if > the window closes (e.g.=2C if too many new applications out there are > based on non-standard mechanisms). >=20 > While we have everything in the group to meet the relevant market's > deadlines=2C we should keep them in mind nevertheless. In particular=2C w= e > are going to be facing cases where *any* decision is better than *no* > decision=2C or where the *perfect* will be the enemy of the *good*. >=20 > In practical terms=2C the group should think twice before opening > already-made decisions and open them only for very good reasons. Also=2C > the group is going to have to make decisions based on *rough* consensus= =2C > as opposed to *wide* consensus or unanimity. This may sound like > motherhood and apple pie but I want to stress these points anyway since > they are important and need to be kept in mind. >=20 > For Orlando=2C I have allocated a *significant* amount of time to RTCWeb > and MMUSIC. Those sessions will allow us to take advantage of the > momentum we currently have after the interim and to make more progress > in all the relevant specifications. >=20 > Cheers=2C >=20 > Gonzalo > AD for the RTCWeb and MMUSIC WGs >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_1a405a2f-3e15-4def-b782-a5651947f2be_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good thoughts=2C Gonzalo. = =3B I share your concern about the rate of progress. =3B However=2C I d= o not believe that the solution is to allocate more time. =3B If that w= ere true then we would all be feeling a lot better after three days of work= at the interim. =3B IMHO=2C there is no amount of effort that can prod= uce movement on this set of problems without getting better clarity on the = context of the discussions and the process by which we get to consensus.&nb= sp=3B

One observation from the interim (and other previous meetings= ) is that there is not a consistent understanding of the *context* for maki= ng decisions=2C and what the definition of "consensus" is. =3B IMHO=2C = there is a world of difference between asking for consensus on the solution= to a set of problems in the context of RTCWEB=2C versus setting the contex= t to be within the scope of MMUSIC {e.g. applicable to RTCWEB=2C CLUE and p= ossible other WGs too}. =3B =3B If the context is RTCWEB=2C we have= a use case document to help us understand the requirements the WebRTC prot= ocols and APIs=3B =3B if it is MMUSIC=2C then the set of requirements i= s not obvious (at least by me) and we should not be surprised if the group = cannot come to consensus.

With respect to understanding of the natu= re of "consensus" in the IETF=2C Pete Resnick has recently published an I-D= which is well worth reading:
http://tools.ietf.org/html/draft-resnick-= on-consensus

>=3B Date:= Tue=2C 12 Feb 2013 13:45:04 +0200
>=3B From: Gonzalo.Camarillo@ericss= on.com
>=3B To: rtcweb@ietf.org=3B mmusic@ietf.org
>=3B Subject: = [rtcweb] Interim meeting and way forward
>=3B
>=3B Folks=2C
&= gt=3B
>=3B first of all=2C I hope everybody has already managed to ge= t back home
>=3B after the storm. Also=2C I want to thank Hadriel and = Acme for being great
>=3B hosts. The information flow=2C the meeting f= acilities=2C the catering=2C the
>=3B pullovers=2C and everything else= was just perfect.
>=3B
>=3B With respect to the technical work = that got done in Boston and=2C more
>=3B importantly=2C that remains t= o be done=2C I want to share a few thoughts
>=3B with the group.
&g= t=3B
>=3B A fact that is obvious but some of us sometimes forget abou= t is that
>=3B RTCWeb=2C as any other technology=2C has a window of op= portunity. The
>=3B usefulness and relevance of any standards we devel= op in this area will
>=3B be extremely high within that window=2C but = will decrease dramatically if
>=3B the window closes (e.g.=2C if too m= any new applications out there are
>=3B based on non-standard mechanis= ms).
>=3B
>=3B While we have everything in the group to meet the= relevant market's
>=3B deadlines=2C we should keep them in mind never= theless. In particular=2C we
>=3B are going to be facing cases where *= any* decision is better than *no*
>=3B decision=2C or where the *perfe= ct* will be the enemy of the *good*.
>=3B
>=3B In practical term= s=2C the group should think twice before opening
>=3B already-made dec= isions and open them only for very good reasons. Also=2C
>=3B the grou= p is going to have to make decisions based on *rough* consensus=2C
>= =3B as opposed to *wide* consensus or unanimity. This may sound like
>= =3B motherhood and apple pie but I want to stress these points anyway since=
>=3B they are important and need to be kept in mind.
>=3B
&g= t=3B For Orlando=2C I have allocated a *significant* amount of time to RTCW= eb
>=3B and MMUSIC. Those sessions will allow us to take advantage of = the
>=3B momentum we currently have after the interim and to make more= progress
>=3B in all the relevant specifications.
>=3B
>= =3B Cheers=2C
>=3B
>=3B Gonzalo
>=3B AD for the RTCWeb and = MMUSIC WGs
>=3B
>=3B ___________________________________________= ____
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B http= s://www.ietf.org/mailman/listinfo/rtcweb
= --_1a405a2f-3e15-4def-b782-a5651947f2be_-- From harald@alvestrand.no Thu Feb 14 00:24:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A569321F877A for ; Thu, 14 Feb 2013 00:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.362 X-Spam-Level: X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpzu23dKfZA3 for ; Thu, 14 Feb 2013 00:24:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A332F21F8751 for ; Thu, 14 Feb 2013 00:24:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83D9239E0D2 for ; Thu, 14 Feb 2013 09:24:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8otT5lCFiJNR for ; Thu, 14 Feb 2013 09:24:37 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:8df0:3d6d:24d8:2e0b] (unknown [IPv6:2001:470:de0a:27:8df0:3d6d:24d8:2e0b]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F0A7339E0C8 for ; Thu, 14 Feb 2013 09:24:36 +0100 (CET) Message-ID: <511C9F44.3010806@alvestrand.no> Date: Thu, 14 Feb 2013 09:24:36 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> In-Reply-To: <511C56CB.1080609@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:24:43 -0000 RTCWEB has a requirement (or rather: it has assumed that there was a solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the same port pair as SRTP. If BUNDLE is not going to be that solution, we have to start designing another. On 02/14/2013 04:15 AM, Paul Kyzivat wrote: > On 2/13/13 3:08 PM, Christer Holmberg wrote: >> >> Hi, >> >>>> (Sorry for sending this to both RTCWEB and MMUSIC, but it is >>>> related to both the need of RTCWEB, and the solution produced by >>>> MMUSIC) >>>> >>>> Hi, >>>> >>>> At the interim, during my BUNDLE presentation, I indicated that we >>>> need to make a decision whether the solution (whatever it will >>>> be...) shall support bundling of non-RTP media. Not saying it can't >>>> be changed, but as currently documented all alternatives only >>>> support bundling of RTP media. >>>> >>>> There might have been some comments from the mic, but as far as I >>>> know there was no decision (if there was, please point me to it). >>>> >>>> So, my question is: do we keep the scope to RTP media? >>> >>> *If* there is a goal to share a single 5-tuple between RTP and SCTP >>> then >>> we need a solution allows bundling them. >> >> That's another way of presenting my question, yes :) >> >>> The key to what you can bundle together is not whether it is RTP or >>> not. >>> It is whether you can specify the mechanism for demuxing the 5-tuple >>> and >>> associated the parts with the appropriate m-line in the bundle. >> >> Yes, and the question is whether we need to perform the exercise to >> look into that, or if we focus on RTP. > > We know how to do the demux between DTLS payloads, ICE, and RTP/SRTP > payloads. And if we restrict to RTP/SRTP and SCTP over DTLS, then we > know how to demux RTP and SCTP. > > There are various schemes that can be used to demux multiple RTP > streams and associate them with individual m-lines in the bundle. > > What troubles me about it is that the rules for what you can bundle > together are dependent on the demux strategy. Describing the rules for > this as part of the specification of the bundling mechanism is going > to be pretty ugly. I don't see any way to make it clean and elegant. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Thu Feb 14 05:49:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65C321F8413 for ; Thu, 14 Feb 2013 05:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrmPIy6wWN-y for ; Thu, 14 Feb 2013 05:49:27 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5129221F81FF for ; Thu, 14 Feb 2013 05:49:27 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-e1-511ceb654be1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7F.9F.19728.56BEC115; Thu, 14 Feb 2013 14:49:25 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 14:49:25 +0100 Received: from tri62.nomadiclab.com (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 597FF233F for ; Thu, 14 Feb 2013 15:49:25 +0200 (EET) Message-ID: <511CEB64.6070306@ericsson.com> Date: Thu, 14 Feb 2013 15:49:24 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCJMWRmVeSWpSXmKPExsUyM+JvjW7qa5lAgyePLSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujANHNjIVfOSs2HF6BXMD42/2LkZODgkBE4lLZ3+xQthiEhfu rWfrYuTiEBI4ySix8s1TJghnA6NEx6b/7BDOKUaJd5M+MIG08ApoS8zdeZAZxGYRUJWYd+wS I4jNJmAvcXPCdbAVogLJEh/vXGOFqBeUODnzCQuILSIgI7F302awXmEBc4mHs+6B1TAL2Epc mHOdBcKWl9j+dg5YjRDQ/Kv/XjFOYOSfhWTULCQts5C0LGBkXsXInpuYmZNebrSJERhSB7f8 Vt3BeOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYU6+YvV174Yst j8W7B7clFJe0nDOacWPOW0+V6sT3b57cCxMoXizdmMX9Y90nkbtBGWdOihXLvPaoe3+gv/PD LJnJ+7Zy6U2IWTvn3V+3xy9Up1j911p2bMVGjZUsptIn/jdeeL38Xn62dWZDq8y+ttVdR+5Z xxS9SZbd3MO9sZk5RE8t47Z6vRJLcUaioRZzUXEiABr79fb3AQAA Subject: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 13:49:28 -0000 Hi all, Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for background, see [1] and [2]), as discussed at the Atlanta meeting, will be one of the important changes in the new version of ICE. Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms." This results in very slow pace of starting connectivity checks if ICE is used with non-RTP traffic. With RTP, the Ta is calculated based on the expected bandwidth used by the RTP stream and can be down to 20 ms. Therefore, many current implementations apparently ignore the "MUST NOT" above and set Ta to something lower. The quite conservative value of 500 ms was originally chosen because of the fear of congesting the links with the connectivity check messages. This is obviously still a valid concern, but would suggesting something lower still make sense? How low would it be reasonably safe to go? What is currently used in practice? Can we come up with a formula similar to RTP (perhaps based on expected bandwidth usage)? Cheers, Ari [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 [2] http://tools.ietf.org/html/rfc5245#section-16.2 From magnus.westerlund@ericsson.com Thu Feb 14 06:00:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF38E21F8820 for ; Thu, 14 Feb 2013 06:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.768 X-Spam-Level: X-Spam-Status: No, score=-105.768 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkI4tFLKI8ZR for ; Thu, 14 Feb 2013 06:00:34 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 55E6921F8BBD for ; Thu, 14 Feb 2013 06:00:33 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-41-511cee003f35 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FA.84.10459.00EEC115; Thu, 14 Feb 2013 15:00:33 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 15:00:32 +0100 Message-ID: <511CEDFF.7060001@ericsson.com> Date: Thu, 14 Feb 2013 15:00:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adam Roach References: <5111247B.8060904@nostrum.com> In-Reply-To: <5111247B.8060904@nostrum.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+JvjS7jO5lAg+Ub2Cz2/F3EbrF1qpDF 1OWPWRyYPRZsKvVYsuQnk8esnU9YApijuGxSUnMyy1KL9O0SuDLmnlrEVnBZumLKae4GxiVi XYwcHBICJhKzF0d2MXICmWISF+6tZ+ti5OIQEjjJKDHt1FIoZzmQ82MlI0gVr4C2RNeTEywg NouAqsThFc/YQWw2AQuJmz8a2UBsUYFgiQ0HVzFB1AtKnJz5BKxeREBRou3wTWYQm1nAT2Je 22ewemGg+oaDf8HqhQTyJdbcfwAW5wTatez2TFaIQ8Ul1rzhgGjVk5hytYURwpaXaN46mxmi VVuioamDdQKj0Cwkm2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAsD245bfuDsZT50QOMUpzsCiJ 84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGhab8Rqff+YaMLnpWEaSzjf1ObJfHMX umTxp/0kp9hm/7f7j7q1VTz8atRUfH6tuuKnuakH3tz6Jj3ndN/c2tlr7tcpPWuK+sq9rOHT tb2Zyu1Sx29yb2x3PmK6YI/lmQTLSVVL0gzmRj7su3RD8WA1/+EZbFGTn+dsTtxwpqvCPZ9n Opv+dwElluKMREMt5qLiRACQKjPqKQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:00:35 -0000 On 2013-02-05 16:25, Adam Roach wrote: > On 2/4/13 02:45, Justin Uberti wrote: >> Sorry for the short lead time, but here's a quick read for the plane. > > I addressed several of the assertions made in this draft in my previous > response (e.g. the need for glare resolution regardless of which > solution we select). Some additional thoughts: > >> o Adding or removing a source requires sending a full list of all >> sources, which doesn't scale well to 10s or 100s of sources, >> especially when they are added or removed frequently. > > Realistically, this isn't how multiparty conferences are handled. It's > unrealistic to think that my DSL connection is going to be sucking down > hundreds of video streams just because I'm in a video conference with > hundreds of people. > > In practice, the way existing conferencing systems handle this is to > send a small, manageable number of streams to each participant, changing > them out as necessary to have a reasonable user experience (either under > the control of the user, its own algorithms, or a combination of the two). > > Which is to say: even with hundreds of source streams being fed into a > conference system, you're really looking at a realistic upper bound on > m= sections of a dozen or two, simply because you can't reasonably > expect recipients to receive more than that many streams simultaneously. > Hi, I definitely want to comment on this from an RTP usage perspective that might be very relevant to remember. Even with a centralized conference solution there is two very distinct solutions in RTP how to transmit a session where you have total of 100 participants and you receive 5 video streams. A) Central point with conceptual sources In this case the central entity creates conceptual RTP streams that carries all the media intended for a specific usage, for example main video, thumbnail one, thumbnail two, thumbnail three, thumbnail four. B) Central point doing source projection In this case there exist 100 potential RTP streams and SSRC from the central point down to the receiver. However, at any point no more than five will actually have RTP packets. But as activity changes and which is most relevant for the receiver the SSRCs in use will switch. For a solution where each SSRC requires its own m= line A) is definitely preferable as it will not require renegotiating the properties for these five conceptual streams. However, B will require a large number of m= lines and dynamic updates as participants comes and go. IF one had a single m= line per RTP session and media type, the amount of updates/renegotiation depends on the amount of meta data about streams that you have put in the SDP. They solutions A) and B) can be identical from an SDP perspective. The above two cases I am quite certain we did discuss in the CLUE interim meeting in Stockholm when discussing topologies and also the relation ship between RTP streams (SSRC) and their origin, i.e. media source/capture. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Thu Feb 14 07:21:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A269F21F886F for ; Thu, 14 Feb 2013 07:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.906 X-Spam-Level: X-Spam-Status: No, score=-109.906 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+FnaPxMPMAb for ; Thu, 14 Feb 2013 07:20:59 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D421F8868 for ; Thu, 14 Feb 2013 07:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2571; q=dns/txt; s=iport; t=1360855259; x=1362064859; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=O9j5iAVTokAJqlpgoIFJ8AnFo6Pzy6bC5+BnBzETJ9Q=; b=gdLlu05SeCWZdCgjiTEtbIvOFHzClr9LBkkjVEs+Abbn+CM3fqWFRNpx IYlkAt92XqHzffYgT4TGkXI9i3Oli5+alIpH/IKyn1xzTcIyH/jSY0iCA YHUwwMrbepi6NgrP2nvOSVak4f+1dFXmEDWdkzU6rol7UDanAFDg2cB8W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIoAHVGrRDoJ/2dsb2JhbABEwGcWc4IfAQEBAwEBAQEFAmQQBwEDAgkRBAEBKAcZDh8DAQUIAgQBEgsFh3wFDb1mjUWEPwOIMDaFIYgdgR2PNoMogUk X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; d="scan'208";a="72235110" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Feb 2013 15:20:44 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1EFKhLS016360; Thu, 14 Feb 2013 15:20:43 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'Ari_Ker=E4nen'?=" , "'mmusic'" References: <511CEB64.6070306@ericsson.com> In-Reply-To: <511CEB64.6070306@ericsson.com> Date: Thu, 14 Feb 2013 07:20:13 -0800 Message-ID: <05a401ce0ac6$db547230$91fd5690$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEzjPbQxUzVAxWufG5eY2LeHo6PJiL6vPA Content-Language: en-us Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:21:00 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf > Of Ari Ker=E4nen > Sent: Thursday, February 14, 2013 5:49 AM > To: mmusic > Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >=20 > Hi all, >=20 > Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for > background, see [1] and [2]), as discussed at the Atlanta meeting, = will > be one of the important changes in the new version of ICE. >=20 > Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be > configurable, SHOULD have a default of 500 ms, and MUST NOT be > configurable to be less than 500 ms." >=20 > This results in very slow pace of starting connectivity checks if ICE = is > used with non-RTP traffic. With RTP, the Ta is calculated based on the > expected bandwidth used by the RTP stream and can be down to 20 ms. > Therefore, many current implementations apparently ignore the "MUST = NOT" > above and set Ta to something lower. That would explain failures claimed to justify the desire for running over one port. =20 The 20ms threshold for the initial connectivity checks is because some=20 NATs could not create new mappings quickly. This problems appears to persist today, considering that both Chrome and Windows 8 limit their=20 number of outstanding DNS queries in an apparent attempt to work around that very same NAT UDP mapping behavior. If trying to create NAT mappings with 0ms pacing, it will certainly=20 cause NAT mapping failures and force retries. > The quite conservative value of 500 ms was originally chosen because = of > the fear of congesting the links with the connectivity check messages. > This is obviously still a valid concern, but would suggesting = something > lower still make sense? How low would it be reasonably safe to go? = What > is currently used in practice? Can we come up with a formula similar = to > RTP (perhaps based on expected bandwidth usage)? A good question for the transport area, which is the origination of the suggestion to send ICE connectivity checks paced to not exceed the=20 bandwidth of the subsequent media. Perhaps the arguments that TCP=20 IW=3D10 is not harmful could be brought to the party. -d >=20 > Cheers, > Ari >=20 > [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 > [2] http://tools.ietf.org/html/rfc5245#section-16.2 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Thu Feb 14 07:32:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61621F8634 for ; Thu, 14 Feb 2013 07:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bb7ke-HLmLO for ; Thu, 14 Feb 2013 07:32:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8504F21F8632 for ; Thu, 14 Feb 2013 07:32:57 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-dc-511d03a8d74e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.EE.32353.8A30D115; Thu, 14 Feb 2013 16:32:56 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 16:32:56 +0100 Received: from tri62.nomadiclab.com (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1D22B233F; Thu, 14 Feb 2013 17:32:56 +0200 (EET) Message-ID: <511D03A7.1060008@ericsson.com> Date: Thu, 14 Feb 2013 17:32:55 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dan Wing , 'mmusic' References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> In-Reply-To: <05a401ce0ac6$db547230$91fd5690$@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3RncFs2ygwYEFmhYXrz1kspi6/DGL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx+o5MwVuximP3mtkaGI8JdTFycEgImEj0 LjboYuQEMsUkLtxbzwZiCwmcZJSY+8e7i5ELyN7AKNGy+BczhLOFUWLdzQlgVbwC2hLn9k9m BhnEIqAqse6IFEiYTcBe4uaE6+wgtqhAssTHO9dYIcoFJU7OfMICYosIWEl0zP/KDGILC7hI vG76BrU4XOLR2zawOKeAhcTaF2uYQGxmAVuJC3Ous0DY8hLNW2czQ9SrSlz994pxAqPgLCQr ZiFpmYWkZQEj8ypG9tzEzJz0cvNNjMBwPLjlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAWDhl1/sLa5c6savPjV96fEbslwf9Tyb9uRNyYcn0lRqdvkE/ bn7qL7y3P0tyxtFjBjz10e/F710QtH/luuqOdmsmq/rH9Tnn7oQ6hZ/9xM3se7EgSXj/h2zP W4c150TKyTyZYnte1Nf8Y/79FknFnLeX0sRZZidXfrLovHtOU/HmbMUZr5repCmxFGckGmox FxUnAgDORQe9FQIAAA== Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:32:58 -0000 On 2/14/13 5:20 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Ari Keränen >> Sent: Thursday, February 14, 2013 5:49 AM >> To: mmusic >> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >> >> Hi all, >> >> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >> background, see [1] and [2]), as discussed at the Atlanta meeting, will >> be one of the important changes in the new version of ICE. >> >> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >> configurable, SHOULD have a default of 500 ms, and MUST NOT be >> configurable to be less than 500 ms." >> >> This results in very slow pace of starting connectivity checks if ICE is >> used with non-RTP traffic. With RTP, the Ta is calculated based on the >> expected bandwidth used by the RTP stream and can be down to 20 ms. >> Therefore, many current implementations apparently ignore the "MUST NOT" >> above and set Ta to something lower. > > That would explain failures claimed to justify the desire for running > over one port. Interesting point. Does anyone know what kind of pacing was actually used when these failures were observed? > The 20ms threshold for the initial connectivity checks is because some > NATs could not create new mappings quickly. This problems appears to > persist today, considering that both Chrome and Windows 8 limit their > number of outstanding DNS queries in an apparent attempt to work around > that very same NAT UDP mapping behavior. > > If trying to create NAT mappings with 0ms pacing, it will certainly > cause NAT mapping failures and force retries. Yes, definitely. So we shouldn't go below 20ms with non-RTP either. Perhaps need to add some more justification/warning text about this too. >> The quite conservative value of 500 ms was originally chosen because of >> the fear of congesting the links with the connectivity check messages. >> This is obviously still a valid concern, but would suggesting something >> lower still make sense? How low would it be reasonably safe to go? What >> is currently used in practice? Can we come up with a formula similar to >> RTP (perhaps based on expected bandwidth usage)? > > A good question for the transport area, which is the origination of the > suggestion to send ICE connectivity checks paced to not exceed the > bandwidth of the subsequent media. Perhaps the arguments that TCP > IW=10 is not harmful could be brought to the party. FYI, I forwarded the original mail to the Transport ADs too. Cheers, Ari >> >> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 >> [2] http://tools.ietf.org/html/rfc5245#section-16.2 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From emil@sip-communicator.org Thu Feb 14 07:37:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151A521F8632 for ; Thu, 14 Feb 2013 07:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnOTjTd9LGVV for ; Thu, 14 Feb 2013 07:37:02 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4753121F8783 for ; Thu, 14 Feb 2013 07:37:02 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so2112900wey.16 for ; Thu, 14 Feb 2013 07:37:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=bUhlsE5CdP1k/iTVtalaf12z0S3z427rAHJsAyOEMX0=; b=IXeFFOMHGr2QCUU4QyW9TlXsAy/PC6zacFA4YxXJzPIe3C28Zr4il9dFxVHEdL/35W qZc6jK/EWP4BRqWhNeeXKhWwY+0TJyZ0ndcRupgv64QuH3Ot1P8B9+mzFfeYSMH0LHF+ 6Bhl/meKU28IS7tL1uWhCq37vTRSbKgOQYy3V2K7+wOpAPvDWASxtFd61Laz49OpX82P shD3GqRHRfhJG+vlK4NtMad/OIlOvpYnGM7qp0hI28rkcZakaSDUd5cZyemQ0l1FbjyB QkPK67Vs/Z4BR5D7h46bZc1N5EpuyqPqKlubuMxJ7ggZaC/xmbq+hODEieVephwpAUAs judw== X-Received: by 10.180.90.147 with SMTP id bw19mr7591wib.28.1360856220894; Thu, 14 Feb 2013 07:37:00 -0800 (PST) Received: from camionet.local (wifi-osiris-sec-182-115.u-strasbg.fr. [130.79.182.115]) by mx.google.com with ESMTPS id q13sm553673wie.0.2013.02.14.07.36.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 07:36:59 -0800 (PST) Message-ID: <511D0498.3030909@jitsi.org> Date: Thu, 14 Feb 2013 16:36:56 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> In-Reply-To: <511D03A7.1060008@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmOJ8QryaRHg8gsHPQUVlfsYdbAkDRpBy33ohjXPqW3ruiq+etqEz3cIJF76X5Jcjb3K8n3 Cc: 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:37:03 -0000 Any idea why there had to be different pacing for RTP and non-RTP flows in the first place? Emil On 14.02.13, 16:32, Ari Ker=E4nen wrote: > On 2/14/13 5:20 PM, Dan Wing wrote: >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Beh= alf >>> Of Ari Ker=E4nen >>> Sent: Thursday, February 14, 2013 5:49 AM >>> To: mmusic >>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >>> >>> Hi all, >>> >>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >>> background, see [1] and [2]), as discussed at the Atlanta meeting, wi= ll >>> be one of the important changes in the new version of ICE. >>> >>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >>> configurable, SHOULD have a default of 500 ms, and MUST NOT be >>> configurable to be less than 500 ms." >>> >>> This results in very slow pace of starting connectivity checks if ICE= is >>> used with non-RTP traffic. With RTP, the Ta is calculated based on th= e >>> expected bandwidth used by the RTP stream and can be down to 20 ms. >>> Therefore, many current implementations apparently ignore the "MUST N= OT" >>> above and set Ta to something lower. >> >> That would explain failures claimed to justify the desire for running >> over one port. >=20 > Interesting point. Does anyone know what kind of pacing was actually=20 > used when these failures were observed? >=20 >> The 20ms threshold for the initial connectivity checks is because some= >> NATs could not create new mappings quickly. This problems appears to >> persist today, considering that both Chrome and Windows 8 limit their >> number of outstanding DNS queries in an apparent attempt to work aroun= d >> that very same NAT UDP mapping behavior. >> >> If trying to create NAT mappings with 0ms pacing, it will certainly >> cause NAT mapping failures and force retries. >=20 > Yes, definitely. So we shouldn't go below 20ms with non-RTP either.=20 > Perhaps need to add some more justification/warning text about this too= =2E >=20 >>> The quite conservative value of 500 ms was originally chosen because = of >>> the fear of congesting the links with the connectivity check messages= =2E >>> This is obviously still a valid concern, but would suggesting somethi= ng >>> lower still make sense? How low would it be reasonably safe to go? Wh= at >>> is currently used in practice? Can we come up with a formula similar = to >>> RTP (perhaps based on expected bandwidth usage)? >> >> A good question for the transport area, which is the origination of th= e >> suggestion to send ICE connectivity checks paced to not exceed the >> bandwidth of the subsequent media. Perhaps the arguments that TCP >> IW=3D10 is not harmful could be brought to the party. >=20 > FYI, I forwarded the original mail to the Transport ADs too. >=20 >=20 > Cheers, > Ari >=20 >>> >>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 >>> [2] http://tools.ietf.org/html/rfc5245#section-16.2 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 --=20 https://jitsi.org From ari.keranen@ericsson.com Thu Feb 14 07:44:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D391221F8623 for ; Thu, 14 Feb 2013 07:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6bAp4qQn9MI for ; Thu, 14 Feb 2013 07:44:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1594D21F85B8 for ; Thu, 14 Feb 2013 07:44:34 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-8f-511d06617387 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A4.02.10459.1660D115; Thu, 14 Feb 2013 16:44:34 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 16:44:33 +0100 Received: from tri62.nomadiclab.com (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 924B5233F; Thu, 14 Feb 2013 17:44:33 +0200 (EET) Message-ID: <511D0660.5020607@ericsson.com> Date: Thu, 14 Feb 2013 17:44:32 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Emil Ivov References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> In-Reply-To: <511D0498.3030909@jitsi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvjW4Sm2ygwbSnvBYXrz1kslizcwKL xdTlj1kcmD2m/N7I6rFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgyTk84zVbQxVJxbMN/xgbG 6cxdjJwcEgImEntbnzBC2GISF+6tZ+ti5OIQEjjJKLHi9kJ2CGcDo8TitiYoZwujxJble5hA WngFtCU2/F4J1s4ioCrxa+93sDibgL3EzQnX2UFsUYFkiY93rrFC1AtKnJz5hAXEFhGQl+hu WwRWzyxgJfG2vRfsJGEBF4nXTd+gzpjCKLFpw3OgBAcHp4CmxOtFIhD1thIX5lxngbDlJba/ nQPWKwR0w9V/rxgnMArNQrJuFpKWWUhaFjAyr2Jkz03MzEkvN9zECAzgg1t+6+5gPHVO5BCj NAeLkjhvmOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MoQe+S87NXVl390KDRXh54m6p xlL/W2qfnYT3pKln+13tOFf68+i13/vPVz1dbvJXxeXO79/qU7dfF/rGd3rzhke6xqmKGu3C Ngdu9gbuY9qrqNrtKrtr6f+lBd/X3PFe+PRI3Lo550VfvP8jxNOjaPh6lmN5ueSCt4/0pI+7 cr8W77hY1dNgoMRSnJFoqMVcVJwIABz69eguAgAA Cc: 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:44:35 -0000 On 2/14/13 5:36 PM, Emil Ivov wrote: > Any idea why there had to be different pacing for RTP and non-RTP flows > in the first place? Because with RTP you know the to-be-used bandwidth and can match checks with that (http://tools.ietf.org/html/rfc5245#section-16.1): > These formulas are aimed at causing STUN transactions to be paced at > the same rate as media. This ensures that ICE will work properly > under the same network conditions needed to support the media as > well. Cheers, Ari From magnus.westerlund@ericsson.com Thu Feb 14 07:51:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3844B21F8726 for ; Thu, 14 Feb 2013 07:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.802 X-Spam-Level: X-Spam-Status: No, score=-105.802 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Va+5tGlpivb for ; Thu, 14 Feb 2013 07:51:18 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1045921F8444 for ; Thu, 14 Feb 2013 07:51:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-41-511d07f1c596 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9D.B2.10459.1F70D115; Thu, 14 Feb 2013 16:51:14 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 16:51:14 +0100 Message-ID: <511D07F1.3070808@ericsson.com> Date: Thu, 14 Feb 2013 16:51:13 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Emil Ivov References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> In-Reply-To: <511D0498.3030909@jitsi.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje4ndtlAg30/uSwuXnvIZLFm5wQW i6nLH7M4MHtM+b2R1WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlzNi4lL3gkUbFgq5ZzA2M sxS7GDk5JARMJGb0/2SHsMUkLtxbz9bFyMUhJHCSUeJK4zQWkISQwHJGidYj7iA2r4C2xOm/ t1hBbBYBVYn+E4sZQWw2AQuJmz8a2UBsUYFgiQ0HVzFB1AtKnJz5BGyOiIC8RHfbIrA4s0CV xI71z8EWCwu4SLxu+ga1eAqjxKYNz5m7GDk4OAU0JV4vEgExJQTEJda84YBo1ZOYcrWFEcKW l2jeOpsZ4kxtiYamDtYJjEKzkGyehaRlFpKWBYzMqxjZcxMzc9LLDTcxAkP34JbfujsYT50T OcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjthZrutXeeoVl3K6fNyVd XfdI38pvhc2tzdOtZApOlkyQFNAs+nMsfq+x1Ml71v1Lmz3UTzvcu3L97zvNuxuM+O5Ojdzo tv8sT8mesyxRmp+f6ppwnnNh7YyPr6rWytH0fqXUbP/m5XmP863WpglK3xJj4s6sVJy+yur7 l5SCfa+kLP5F/5yhxFKckWioxVxUnAgAsJP8jSsCAAA= Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:51:20 -0000 On 2013-02-14 16:36, Emil Ivov wrote: > Any idea why there had to be different pacing for RTP and non-RTP flows > in the first place? I think our arguments where that in the context of a non-congestion controlled voice application it would send with 20 ms interval anyway. For other transports and protocols it was not obvious for what intended environment it would be used. For example a low power network application that sends beyond 30 kbps could be problematic. Thus we took one of our conservative values from the transport books, i.e. 500 ms. I would point out that this is a difficult transport issue. Compared to TCP IW10, that burst occurs first after the initial handshake when one has actually established that there is a responder. With ICE there is a clear issue with an attacker bloating a offer/answer with candidates that recreates the voice hammer attack using ICE's STUN checks towards a target address or domain. Also the STUN checks will have different source address pairs which in it self could be an issue for attack prevention firewalls etc. Thus I would be careful with speeding up Ta for RTP to much, and I think someone needs to fine empiric data that it would work. For the the 500 ms that can likely be significantly lowered without any issues. But some considerations around the wider usage needs to be taken into account. Cheers Magnus One of the ADs responsible for the pacing in ICE. > > Emil > > On 14.02.13, 16:32, Ari Keränen wrote: >> On 2/14/13 5:20 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>>> Of Ari Keränen >>>> Sent: Thursday, February 14, 2013 5:49 AM >>>> To: mmusic >>>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >>>> >>>> Hi all, >>>> >>>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >>>> background, see [1] and [2]), as discussed at the Atlanta meeting, will >>>> be one of the important changes in the new version of ICE. >>>> >>>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >>>> configurable, SHOULD have a default of 500 ms, and MUST NOT be >>>> configurable to be less than 500 ms." >>>> >>>> This results in very slow pace of starting connectivity checks if ICE is >>>> used with non-RTP traffic. With RTP, the Ta is calculated based on the >>>> expected bandwidth used by the RTP stream and can be down to 20 ms. >>>> Therefore, many current implementations apparently ignore the "MUST NOT" >>>> above and set Ta to something lower. >>> >>> That would explain failures claimed to justify the desire for running >>> over one port. >> >> Interesting point. Does anyone know what kind of pacing was actually >> used when these failures were observed? >> >>> The 20ms threshold for the initial connectivity checks is because some >>> NATs could not create new mappings quickly. This problems appears to >>> persist today, considering that both Chrome and Windows 8 limit their >>> number of outstanding DNS queries in an apparent attempt to work around >>> that very same NAT UDP mapping behavior. >>> >>> If trying to create NAT mappings with 0ms pacing, it will certainly >>> cause NAT mapping failures and force retries. >> >> Yes, definitely. So we shouldn't go below 20ms with non-RTP either. >> Perhaps need to add some more justification/warning text about this too. >> >>>> The quite conservative value of 500 ms was originally chosen because of >>>> the fear of congesting the links with the connectivity check messages. >>>> This is obviously still a valid concern, but would suggesting something >>>> lower still make sense? How low would it be reasonably safe to go? What >>>> is currently used in practice? Can we come up with a formula similar to >>>> RTP (perhaps based on expected bandwidth usage)? >>> >>> A good question for the transport area, which is the origination of the >>> suggestion to send ICE connectivity checks paced to not exceed the >>> bandwidth of the subsequent media. Perhaps the arguments that TCP >>> IW=10 is not harmful could be brought to the party. >> >> FYI, I forwarded the original mail to the Transport ADs too. >> >> >> Cheers, >> Ari >> >>>> >>>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 >>>> [2] http://tools.ietf.org/html/rfc5245#section-16.2 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ari.keranen@ericsson.com Thu Feb 14 08:12:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C8E21F882E for ; Thu, 14 Feb 2013 08:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY7EJN9fen1k for ; Thu, 14 Feb 2013 08:12:39 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC0EF21F882A for ; Thu, 14 Feb 2013 08:12:38 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-49-511d0cf557a8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F9.C1.19728.5FC0D115; Thu, 14 Feb 2013 17:12:37 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Feb 2013 17:12:37 +0100 Received: from tri62.nomadiclab.com (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F192A233F; Thu, 14 Feb 2013 18:12:36 +0200 (EET) Message-ID: <511D0CF4.4010001@ericsson.com> Date: Thu, 14 Feb 2013 18:12:36 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> In-Reply-To: <511D07F1.3070808@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje5XHtlAg1XztCwuXnvIZLFm5wQW i6nLH7M4MHtM+b2R1WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlfP6+jbHgonbFt3/7mBoY 1yl3MXJySAiYSByZdJ8NwhaTuHBvPZDNxSEkcJJR4s/lp4wQzgZGidnrFrBDOFsYJZ4cfgfW wiugLbF4zlwmEJtFQFXi3qk7YHE2AXuJmxOus4PYogLJEh/vXGOFqBeUODnzCQuILSJgJvFw wn6wemaBKIlvL+8yg9jCAi4Sr5u+scEtu9N1E2gBBwengI7EozOFEPW2EhfmXGeBsOUlmrfO BusVArrh6r9XjBMYhWYhWTcLScssJC0LGJlXMbLnJmbmpJcbbWIEBvDBLb9VdzDeOSdyiFGa g0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaGeevvzX5wgp2pyfGbU1qrgGrW Y0bJT+fmCYt7ce7oacoUZrGy+TOj+FetzOSzJwxe+miL1779qrvmzaGYBVf/HDq/Str5pMI/ UWt/2X/PXHac2lN45PodPs89vpev8mnlmWg2xJc+ith7mmVZ3VS5oM8akhVq3xZwztjGvpiD 9+CxIKfvvEuUWIozEg21mIuKEwH+j4APLgIAAA== Cc: 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:12:40 -0000 Hi Magnus, Thanks for clarifying the background on this! Some comments and questions inline. On 2/14/13 5:51 PM, Magnus Westerlund wrote: > On 2013-02-14 16:36, Emil Ivov wrote: >> Any idea why there had to be different pacing for RTP and non-RTP flows >> in the first place? > > I think our arguments where that in the context of a non-congestion > controlled voice application it would send with 20 ms interval anyway. > For other transports and protocols it was not obvious for what intended > environment it would be used. For example a low power network > application that sends beyond 30 kbps could be problematic. Thus we took > one of our conservative values from the transport books, i.e. 500 ms. > > I would point out that this is a difficult transport issue. Compared to > TCP IW10, that burst occurs first after the initial handshake when one > has actually established that there is a responder. > > With ICE there is a clear issue with an attacker bloating a offer/answer > with candidates that recreates the voice hammer attack using ICE's STUN > checks towards a target address or domain. > > Also the STUN checks will have different source address pairs which in > it self could be an issue for attack prevention firewalls etc. > > Thus I would be careful with speeding up Ta for RTP to much, and I think > someone needs to fine empiric data that it would work. I'd guess the 20 ms interval is quite OK for the RTP since, as Dan noted, you can't go much faster without overwhelming the NATs. > For the the 500 ms that can likely be significantly lowered without any > issues. But some considerations around the wider usage needs to be taken > into account. Would you have any recommendation for a good, less conservative value? If the bandwidth of the non-RTP stream is known, I guess that could be used in a similar way as with RTP to calculate Ta (with lower bound of 20ms). For cases where the bw is not known, we could perhaps RFC2119-recommend some fairly-conservative value (say, around 100ms?) and "MUST NOT" for below 20ms? Cheers, Ari (as individual) > Cheers > > Magnus > One of the ADs responsible for the pacing in ICE. > >> >> Emil >> >> On 14.02.13, 16:32, Ari Keränen wrote: >>> On 2/14/13 5:20 PM, Dan Wing wrote: >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>>>> Of Ari Keränen >>>>> Sent: Thursday, February 14, 2013 5:49 AM >>>>> To: mmusic >>>>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >>>>> >>>>> Hi all, >>>>> >>>>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >>>>> background, see [1] and [2]), as discussed at the Atlanta meeting, will >>>>> be one of the important changes in the new version of ICE. >>>>> >>>>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >>>>> configurable, SHOULD have a default of 500 ms, and MUST NOT be >>>>> configurable to be less than 500 ms." >>>>> >>>>> This results in very slow pace of starting connectivity checks if ICE is >>>>> used with non-RTP traffic. With RTP, the Ta is calculated based on the >>>>> expected bandwidth used by the RTP stream and can be down to 20 ms. >>>>> Therefore, many current implementations apparently ignore the "MUST NOT" >>>>> above and set Ta to something lower. >>>> >>>> That would explain failures claimed to justify the desire for running >>>> over one port. >>> >>> Interesting point. Does anyone know what kind of pacing was actually >>> used when these failures were observed? >>> >>>> The 20ms threshold for the initial connectivity checks is because some >>>> NATs could not create new mappings quickly. This problems appears to >>>> persist today, considering that both Chrome and Windows 8 limit their >>>> number of outstanding DNS queries in an apparent attempt to work around >>>> that very same NAT UDP mapping behavior. >>>> >>>> If trying to create NAT mappings with 0ms pacing, it will certainly >>>> cause NAT mapping failures and force retries. >>> >>> Yes, definitely. So we shouldn't go below 20ms with non-RTP either. >>> Perhaps need to add some more justification/warning text about this too. >>> >>>>> The quite conservative value of 500 ms was originally chosen because of >>>>> the fear of congesting the links with the connectivity check messages. >>>>> This is obviously still a valid concern, but would suggesting something >>>>> lower still make sense? How low would it be reasonably safe to go? What >>>>> is currently used in practice? Can we come up with a formula similar to >>>>> RTP (perhaps based on expected bandwidth usage)? >>>> >>>> A good question for the transport area, which is the origination of the >>>> suggestion to send ICE connectivity checks paced to not exceed the >>>> bandwidth of the subsequent media. Perhaps the arguments that TCP >>>> IW=10 is not harmful could be brought to the party. >>> >>> FYI, I forwarded the original mail to the Transport ADs too. >>> >>> >>> Cheers, >>> Ari >>> >>>>> >>>>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 >>>>> [2] http://tools.ietf.org/html/rfc5245#section-16.2 >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> > > From emil@sip-communicator.org Thu Feb 14 08:13:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5F421F882E for ; Thu, 14 Feb 2013 08:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw-bDqTDFy9M for ; Thu, 14 Feb 2013 08:13:03 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2948E21F8849 for ; Thu, 14 Feb 2013 08:13:03 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so1995210wgl.6 for ; Thu, 14 Feb 2013 08:12:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=wXf7iRGNCZ9AhQQwKm1LecvgZkZGqcDQ8WDfxUv8P7Q=; b=ghQrdbRzbgr5TRgsGkJae1mbX+n9hyh/oR84tHDZRQ3i++CKmTKw38mpF+Vf4AorPu H86qLZYVneXbo3WObB8GzHCf7GTMJhV6WgUgcL85aaflZjfxDL75FpmSLYQGOKw8nCGP Ikp1Ta4dp3RgS73TrdDVscRHCKJgLdGvMhcU+iVbmpbBymSFaT8oEbGfu7EmobUzNkhj 8cgW7xRyifnoz2wNaN4dv5JEKxa1wPi5KjdA7TrcgCYyaWIT6Cf3lHOb/EnFpzze4vtk RC3z+rv1WBUbiUvINX1qMieQKQ2lr8i4IqSJHFXsJ9iU4ommYM7Xiv8v+q5yMYmsFO24 yEFw== X-Received: by 10.194.156.196 with SMTP id wg4mr46699826wjb.22.1360858373974; Thu, 14 Feb 2013 08:12:53 -0800 (PST) Received: from camionet.local (wifi-osiris-sec-182-115.u-strasbg.fr. [130.79.182.115]) by mx.google.com with ESMTPS id n10sm239436wia.0.2013.02.14.08.12.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 08:12:52 -0800 (PST) Message-ID: <511D0D00.5050100@jitsi.org> Date: Thu, 14 Feb 2013 17:12:48 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> In-Reply-To: <511D07F1.3070808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQls3n1iENLxBfTK2NkIS/M0P2fFVauvOETc1tBjrVvgT3aGNs2Qya/w9mPW17pgMA/81Vjv Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:13:04 -0000 Thanks for explaining Magnus, some more inline On 14.02.13, 16:51, Magnus Westerlund wrote: > On 2013-02-14 16:36, Emil Ivov wrote: >> Any idea why there had to be different pacing for RTP and non-RTP flow= s >> in the first place? >=20 > I think our arguments where that in the context of a non-congestion > controlled voice application it would send with 20 ms interval anyway. > For other transports and protocols it was not obvious for what intended= > environment it would be used. For example a low power network > application that sends beyond 30 kbps could be problematic. Thus we too= k > one of our conservative values from the transport books, i.e. 500 ms. >=20 > I would point out that this is a difficult transport issue. Compared to= > TCP IW10, that burst occurs first after the initial handshake when one > has actually established that there is a responder. >=20 > With ICE there is a clear issue with an attacker bloating a offer/answe= r > with candidates that recreates the voice hammer attack using ICE's STUN= > checks towards a target address or domain. OK, but we already have 5.7.3 and the 100 check limitation, right? I suppose the thing that is really problematic here is the strength of the recommendation. Other sections in the spec seem to often refer to often leave the choice to the application advising use of a rate that matches the traffic that's about to be exchanged. It seems that a similar recommendation would make sense here. WDYT? Emil >=20 > Also the STUN checks will have different source address pairs which in > it self could be an issue for attack prevention firewalls etc. >=20 > Thus I would be careful with speeding up Ta for RTP to much, and I thin= k > someone needs to fine empiric data that it would work. >=20 > For the the 500 ms that can likely be significantly lowered without any= > issues. But some considerations around the wider usage needs to be take= n > into account. >=20 > Cheers >=20 > Magnus > One of the ADs responsible for the pacing in ICE. >=20 >> >> Emil >> >> On 14.02.13, 16:32, Ari Ker=E4nen wrote: >>> On 2/14/13 5:20 PM, Dan Wing wrote: >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On B= ehalf >>>>> Of Ari Ker=E4nen >>>>> Sent: Thursday, February 14, 2013 5:49 AM >>>>> To: mmusic >>>>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks >>>>> >>>>> Hi all, >>>>> >>>>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for >>>>> background, see [1] and [2]), as discussed at the Atlanta meeting, = will >>>>> be one of the important changes in the new version of ICE. >>>>> >>>>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be >>>>> configurable, SHOULD have a default of 500 ms, and MUST NOT be >>>>> configurable to be less than 500 ms." >>>>> >>>>> This results in very slow pace of starting connectivity checks if I= CE is >>>>> used with non-RTP traffic. With RTP, the Ta is calculated based on = the >>>>> expected bandwidth used by the RTP stream and can be down to 20 ms.= >>>>> Therefore, many current implementations apparently ignore the "MUST= NOT" >>>>> above and set Ta to something lower. >>>> >>>> That would explain failures claimed to justify the desire for runnin= g >>>> over one port. >>> >>> Interesting point. Does anyone know what kind of pacing was actually = >>> used when these failures were observed? >>> >>>> The 20ms threshold for the initial connectivity checks is because so= me >>>> NATs could not create new mappings quickly. This problems appears t= o >>>> persist today, considering that both Chrome and Windows 8 limit thei= r >>>> number of outstanding DNS queries in an apparent attempt to work aro= und >>>> that very same NAT UDP mapping behavior. >>>> >>>> If trying to create NAT mappings with 0ms pacing, it will certainly >>>> cause NAT mapping failures and force retries. >>> >>> Yes, definitely. So we shouldn't go below 20ms with non-RTP either.=20 >>> Perhaps need to add some more justification/warning text about this t= oo. >>> >>>>> The quite conservative value of 500 ms was originally chosen becaus= e of >>>>> the fear of congesting the links with the connectivity check messag= es. >>>>> This is obviously still a valid concern, but would suggesting somet= hing >>>>> lower still make sense? How low would it be reasonably safe to go? = What >>>>> is currently used in practice? Can we come up with a formula simila= r to >>>>> RTP (perhaps based on expected bandwidth usage)? >>>> >>>> A good question for the transport area, which is the origination of = the >>>> suggestion to send ICE connectivity checks paced to not exceed the >>>> bandwidth of the subsequent media. Perhaps the arguments that TCP >>>> IW=3D10 is not harmful could be brought to the party. >>> >>> FYI, I forwarded the original mail to the Transport ADs too. >>> >>> >>> Cheers, >>> Ari >>> >>>>> >>>>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 >>>>> [2] http://tools.ietf.org/html/rfc5245#section-16.2 >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >=20 >=20 --=20 https://jitsi.org From pkyzivat@alum.mit.edu Thu Feb 14 10:14:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F163421F8423 for ; Thu, 14 Feb 2013 10:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.282 X-Spam-Level: X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb-R08e61UrA for ; Thu, 14 Feb 2013 10:14:33 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id E38FD21F841B for ; Thu, 14 Feb 2013 10:14:32 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta10.westchester.pa.mail.comcast.net with comcast id 0JCa1l0021wpRvQ5AJEUWF; Thu, 14 Feb 2013 18:14:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 0JEU1l00M3ZTu2S3eJEUKV; Thu, 14 Feb 2013 18:14:28 +0000 Message-ID: <511D2982.6040506@alum.mit.edu> Date: Thu, 14 Feb 2013 13:14:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> In-Reply-To: <511C9F44.3010806@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360865668; bh=uBWvU0uIjzzjGfSrUtrahjC/splfk3Njhk7BeyIFyCE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MHSszM+WC1adEnK/Lu+kLDKjmfVMucUQ1bVhhZYSVfZa8rK+jQFRZNIbpRdLFH6Zt LszlBtqIvSkD3XCo0TWF/u++xjyaLbeTAIPAh3TlaKzFD6p0qrVitJPedELudW9Nr6 OGxs7BTe5UPbyaVih6XZ4g/yCIKGf4AB5gJh3AZGXu8vlILKYgQSWuyz3arNUdGwfV 3Zn5q42DdHGcsFa/ZF5R7sGCV8Nc+ZTKETZdXW6uvE5JRy4UgJbZgAVkifjnXdKbUZ U/CtUPeKBdDuZynO1r44UH2kKqJlIMT1DbggX7a5YX+u4MRSr1J/NE8zYThL1KUCjM bOaA/uAIT8/qg== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:14:34 -0000 Harald, On 2/14/13 3:24 AM, Harald Alvestrand wrote: > RTCWEB has a requirement (or rather: it has assumed that there was a > solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the > same port pair as SRTP. > > If BUNDLE is not going to be that solution, we have to start designing > another. Yes, I know. But nobody has made a proposal that actually encompasses that desire. I think we have turned over a rock and found a large can of worms. There is a deep connection here between the mechanisms used to demux packets into separate logical "flows" and the SDP notations used to describe those flows. SDP was designed to describe flows that are demuxed by 3-tuple - incoming transport type, address, and port. SDP O/A extended that to describe symmetric pairs of such flows. Restriction to symmetry of send/recv address/port potentially extends that to demux by 5-tuple. But we are already on fuzzy ground of SDP expressiveness by that time. Now we want to extend that expressiveness to further levels and criteria for demuxing. The bundle *syntax* lets us describe the things we want to demux, but without any explicit indication of what demux algorithm to apply. The existing bundle proposal applies some restrictions on what can be bundled - presumably to limit it what can be demuxed - but doesn't explicitly say how to demux. (There are restrictions on use of payload types across m-lines that suggest an expectation that demux is to be done based on payload type.) The restrictions it imposes don't permit bundling RTP and SCTP. Unless we want to devolve into a Do What I Mean situation, we need to find a way to explicitly say what we mean. A good start would be to first be *specific* (and exhaustive) about what we would like to multiplex (without regard to how we will notate that), and how we propose to mux/demux it. There is info out there on how to mux/demux UDP/TLS/RTP/SAVP and DTLS/SCTP over the same DTLS connection. (Though it isn't immediately obvious where that is specified.) Presumably the goal for RTCWEB is to demux distinct MediaStreamTracks from a single UDP/TLS/RTP/SAVP session. I doubt we want to do that by payload type. Based on discussion last week, this may sometimes be done by SSRC, but I think we had cases when multiple SSRCs might map to the same track, and the mappings may not always be known in advance. CLUE has further needs, where an SSRC may move about from one "capture-encoding" to another. (A clue capture-encoding is, I think, more or less equivalent to an RTCWEB track.) So I think we need a serious discussion of mux/demux criteria/algorithms. This seems to be a prerequisite to a solution to the bundling problem in MMUSIC. But MMUSIC may not be the proper wg for this discussion. I don't know which one is. Thanks, Paul > On 02/14/2013 04:15 AM, Paul Kyzivat wrote: >> On 2/13/13 3:08 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> (Sorry for sending this to both RTCWEB and MMUSIC, but it is >>>>> related to both the need of RTCWEB, and the solution produced by >>>>> MMUSIC) >>>>> >>>>> Hi, >>>>> >>>>> At the interim, during my BUNDLE presentation, I indicated that we >>>>> need to make a decision whether the solution (whatever it will >>>>> be...) shall support bundling of non-RTP media. Not saying it can't >>>>> be changed, but as currently documented all alternatives only >>>>> support bundling of RTP media. >>>>> >>>>> There might have been some comments from the mic, but as far as I >>>>> know there was no decision (if there was, please point me to it). >>>>> >>>>> So, my question is: do we keep the scope to RTP media? >>>> >>>> *If* there is a goal to share a single 5-tuple between RTP and SCTP >>>> then >>>> we need a solution allows bundling them. >>> >>> That's another way of presenting my question, yes :) >>> >>>> The key to what you can bundle together is not whether it is RTP or >>>> not. >>>> It is whether you can specify the mechanism for demuxing the 5-tuple >>>> and >>>> associated the parts with the appropriate m-line in the bundle. >>> >>> Yes, and the question is whether we need to perform the exercise to >>> look into that, or if we focus on RTP. >> >> We know how to do the demux between DTLS payloads, ICE, and RTP/SRTP >> payloads. And if we restrict to RTP/SRTP and SCTP over DTLS, then we >> know how to demux RTP and SCTP. >> >> There are various schemes that can be used to demux multiple RTP >> streams and associate them with individual m-lines in the bundle. >> >> What troubles me about it is that the rules for what you can bundle >> together are dependent on the demux strategy. Describing the rules for >> this as part of the specification of the bundling mechanism is going >> to be pretty ugly. I don't see any way to make it clean and elegant. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Thu Feb 14 10:34:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F42D21F888E for ; Thu, 14 Feb 2013 10:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo3cO906GtM6 for ; Thu, 14 Feb 2013 10:34:09 -0800 (PST) Received: from mail-we0-x232.google.com (we-in-x0232.1e100.net [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 62BF521F888B for ; Thu, 14 Feb 2013 10:34:09 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so2164228wey.23 for ; Thu, 14 Feb 2013 10:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KwZA8wJheL1dybf/hpGj1oyY6+MZUPAvQ/Xu1xHVkBw=; b=DKYy0722/S7qQcjOfVJuBUUkFlBxdre+ZeR8s58lSV7jgdswNrzETYiwDPOTPHyvUd t+DFiOQhR+2va0p1SNce7R/TTsyZTP+uIa8GCAlvv6EDIZHZ6JXxkMM2GG5M1HT070n9 m56lnU7cRwib/TztUIsYcn7xcUrGuAiszYr9NXOoyKtMNriusSZv5+LGBm0XLQJ0Ole5 p6nLiDJwyNUNO5GPqSOAgwM4eUxv8hnH1H9S22glU3ILwnBr7SqOJ3ZbvWatIZFKxzIl OTepo7fzskXo1JptcRrT6702in/HpBhHbmmFWuFj6Imsu3fTzu0+6t8cX0jv2LoNgEhy EuDg== MIME-Version: 1.0 X-Received: by 10.180.75.177 with SMTP id d17mr1284446wiw.16.1360866848368; Thu, 14 Feb 2013 10:34:08 -0800 (PST) Received: by 10.194.5.135 with HTTP; Thu, 14 Feb 2013 10:34:08 -0800 (PST) In-Reply-To: <511C56CB.1080609@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> Date: Thu, 14 Feb 2013 10:34:08 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:34:10 -0000 On 13 February 2013 19:15, Paul Kyzivat wrote: > What troubles me about it is that the rules for what you can bundle together > are dependent on the demux strategy. Describing the rules for this as part > of the specification of the bundling mechanism is going to be pretty ugly. I > don't see any way to make it clean and elegant. I didn't see this as a deal-breaker. You could think of it as: "if you can demux these things, then it is valid to multiplex them". Don't bother saying anything more than that. As Bernard observes, it's the RTP demux that is hard. Solve that and let the rest sort themselves out. Sure, you might not be able to demux protocol MEAT and protocol CHEESE, but that's an easy solve - don't try to multiplex them. From pkyzivat@alum.mit.edu Thu Feb 14 10:55:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3732821F8833 for ; Thu, 14 Feb 2013 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu85aRw2nI6g for ; Thu, 14 Feb 2013 10:55:29 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 999B421F8739 for ; Thu, 14 Feb 2013 10:55:29 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0HBm1l02V0bG4ec53JvVUF; Thu, 14 Feb 2013 18:55:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 0JvU1l00P3ZTu2S3PJvUMe; Thu, 14 Feb 2013 18:55:29 +0000 Message-ID: <511D3320.2090001@alum.mit.edu> Date: Thu, 14 Feb 2013 13:55:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360868129; bh=QmyzOrJbw+DmQ+dQBt8X3lg9ZzHzLpMU4ymDrH5cvzk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Tsm01jqPQQ6/pRpt0ELzb6fJz1bprg4fJjw2J3zhrp+G3IXMlcQpSoe4jGLGRPlFS TeX76eUP4W+8G4+zcakRKlEEHdWAGQyOthcJoKVk4Ns0aYgdfkebnZ08AnIa2jntlc UlVOZUDNJwhdNFSIciJ9zx7n4ukysAq1tEHZTNpFM1d9mpRNElPPFaef4VUuwahXUk 6/RZCnT5EOlh82PkwmYiki5DFYInk5cqsH/8tYddc/dqQIvtl8hZ5A81BlpSGG0xAr 4FneE7/A3zG5znEEw3mMq31NziSmaXBmsIQaix+zmHH0oCiDIwunmjr2HRLJgCHuFN RIVLRwOXF5MBQ== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:55:30 -0000 On 2/14/13 1:34 PM, Martin Thomson wrote: > On 13 February 2013 19:15, Paul Kyzivat wrote: >> What troubles me about it is that the rules for what you can bundle together >> are dependent on the demux strategy. Describing the rules for this as part >> of the specification of the bundling mechanism is going to be pretty ugly. I >> don't see any way to make it clean and elegant. > > > I didn't see this as a deal-breaker. You could think of it as: "if > you can demux these things, then it is valid to multiplex them". > Don't bother saying anything more than that. > > As Bernard observes, it's the RTP demux that is hard. Solve that and > let the rest sort themselves out. Sure, you might not be able to > demux protocol MEAT and protocol CHEESE, but that's an easy solve - > don't try to multiplex them. I agree we don't need an algorithm to demux anything from anything. But we do need a specified way to look at the SDP and know what the mux/demux algorithm is. The rule for bundling should make that a prerequisite for any given bundle. Thanks, Paul From worley@shell01.TheWorld.com Thu Feb 14 11:54:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5717A21F8518 for ; Thu, 14 Feb 2013 11:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhwMdePHrkYp for ; Thu, 14 Feb 2013 11:54:12 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB821F88EF for ; Thu, 14 Feb 2013 11:54:11 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EJrPQO012093 for ; Thu, 14 Feb 2013 14:53:27 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EJrP0p1849710 for ; Thu, 14 Feb 2013 14:53:25 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EJrMT01840535; Thu, 14 Feb 2013 14:53:22 -0500 (EST) Date: Thu, 14 Feb 2013 14:53:22 -0500 (EST) Message-Id: <201302141953.r1EJrMT01840535@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <511BF229.1090702@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:54:13 -0000 > From: Paul Kyzivat > > *If* there is a goal to share a single 5-tuple between RTP and SCTP then > we need a solution allows bundling them. Do any of the current proposed bundling techniques include both RTP and SCTP? Dale From christer.holmberg@ericsson.com Thu Feb 14 12:13:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73EB21F85C6 for ; Thu, 14 Feb 2013 12:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGhiNeGQ9T3C for ; Thu, 14 Feb 2013 12:13:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8021F85B4 for ; Thu, 14 Feb 2013 12:13:43 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-54-511d45724465 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9F.35.19728.2754D115; Thu, 14 Feb 2013 21:13:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 21:13:37 +0100 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: RTP only? Thread-Index: AQHOCuzxeB8ChmgfTeKF683MxdSffph5xzB1 Date: Thu, 14 Feb 2013 20:13:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu>, <201302141953.r1EJrMT01840535@shell01.TheWorld.com> In-Reply-To: <201302141953.r1EJrMT01840535@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW6Rq2ygwZKFohZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyrjb2MRYsIazontKG1MD41n2LkYODgkBE4kN z5y6GDmBTDGJC/fWs3UxcnEICRxilFh9/SsrhLOEUeLZwumsIA1sAhYS3f+0QRpEBPwk1q/6 wA5iCwuoS8zevIEdIq4hcer5PRYI20ji1JO7bCA2i4CqxPnb35hAbF4Bb4k3W3uYIeYvZJRo bV/ECpLgFHCQaD5xhxnEZgS66PupNWANzALiEreezGeCuFRAYsme88wQtqjEy8f/WCGeUZRY 3i8HUa4jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSqbOQtMxC0jILScsCRpZVjOy5iZk5 6eVGmxiBcXBwy2/VHYx3zokcYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gZH1/MMbzwvX3ZrIV9Iyv23K2ZTljh1sRw/q3zzGWjX1JpPNA6V9066w3bmdf/9X7/LYIx01 1twLNRss03VczvZnT22ULn0suKjS5dGVuaryn2xupddViuTzcDcl7vigclRizvkskT8Mey+G LV6we2WNfXR1/m0OI2OVQNM1LFKrLFd/79WS+q/EUpyRaKjFXFScCACSaXsNUQIAAA== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 20:13:44 -0000 Hi Dale, I see no reason why BUNDLE couldn't be used also for non-RTP. We would need= to consider it when we study the study the SDP attribute impact, though, b= ut that exercise we have to do for RTP anyway. For MMT it is more tricky. As it only uses a single m=3D line for the whole= bundle, we would need to define a new "MMT" proto value for that m=3D line= (currently the draft uses RTP). Then we would need to, inside the m=3D lin= e, define a way to specify the proto value for each individual media. Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Dale R= . Worley [worley@ariadne.com] Sent: Thursday, 14 February 2013 9:53 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? > From: Paul Kyzivat > > *If* there is a goal to share a single 5-tuple between RTP and SCTP then > we need a solution allows bundling them. Do any of the current proposed bundling techniques include both RTP and SCTP? Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From matthew@matthew.at Thu Feb 14 13:10:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C335021F884B for ; Thu, 14 Feb 2013 13:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZdcpdtg8cZS for ; Thu, 14 Feb 2013 13:10:55 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D321F85CC for ; Thu, 14 Feb 2013 13:10:55 -0800 (PST) Received: from [10.244.209.117] (mobile-166-137-212-068.mycingular.net [166.137.212.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 846F014803B; Thu, 14 Feb 2013 13:10:54 -0800 (PST) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <511D2982.6040506@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> X-Mailer: iPhone Mail (10A523) From: Matthew Kaufman Date: Thu, 14 Feb 2013 13:10:50 -0800 To: Paul Kyzivat Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:10:56 -0000 On Feb 14, 2013, at 10:14 AM, Paul Kyzivat wrote: >>=20 >=20 > Yes, I know. But nobody has made a proposal that actually encompasses that= desire. I think we have turned over a rock and found a large can of worms. >=20 > There is a deep connection here between the mechanisms used to demux packe= ts into separate logical "flows" and the SDP notations used to describe thos= e flows. >=20 > SDP was designed to describe flows that are demuxed by 3-tuple - incoming t= ransport type, address, and port. SDP O/A extended that to describe symmetri= c pairs of such flows. Restriction to symmetry of send/recv address/port pot= entially extends that to demux by 5-tuple. But we are already on fuzzy groun= d of SDP expressiveness by that time. >=20 > Now we want to extend that expressiveness to further levels and criteria f= or demuxing. The bundle *syntax* lets us describe the things we want to demu= x, but without any explicit indication of what demux algorithm to apply. The= existing bundle proposal applies some restrictions on what can be bundled -= presumably to limit it what can be demuxed - but doesn't explicitly say how= to demux. (There are restrictions on use of payload types across m-lines th= at suggest an expectation that demux is to be done based on payload type.) T= he restrictions it imposes don't permit bundling RTP and SCTP. >=20 > Unless we want to devolve into a Do What I Mean situation, we need to find= a way to explicitly say what we mean. >=20 Yes, and *only* because RTCWEB turned over the rock *and* continues to insis= t that SDP be the way for the developers to "explicitly say what we mean" ar= e we here in MMUSIC with a big can of worms and some urgency around coming u= p with any solution, no matter how ugly. There are better ways to construct an API with which developers could tell t= he browser what they want it to do, and then MMUSIC could work on carefully s= tandardizing only what is needed for interworking cases. Matthew Kaufman (Sent from my iPhone)= From martin.thomson@gmail.com Thu Feb 14 13:40:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98A21F8629 for ; Thu, 14 Feb 2013 13:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUASMwC+oqut for ; Thu, 14 Feb 2013 13:40:32 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id ED25921F86EF for ; Thu, 14 Feb 2013 13:40:30 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so2301345wey.23 for ; Thu, 14 Feb 2013 13:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U+wcagEGJBthuXWUC9xDfPQVfyiTuvN0RIUpbud4pWg=; b=G8jT56yfWDorCFixWM8vWEjRRaEsmmXxmXoS7nX/p/HXhfyWbK8hQ4BtR2bTRDZu4O CTJlKim1lLsn0BT/gCyyt+NWBNDe5WlOx48zwYSvleEcxV4MeIaVKREsWqt2DzZXikRy dWVUb7WQrowzAJG2mcB3MXyiVGsnoZ3MdLZL/DBAIwg7ydLKRCm81W9qrSDCbTX60Fi1 pH7rOVMwieMWi/2rj0u2xvWp73f3iAzYUtsPyPGrb15iJRtPDxU9PjvvWrC3EIJMKyP6 UFchL/56IuN3cBcbmNYcVU7fJgNHcpKg7isKXdblTGDDU52FoQppmJZrp4bTsD9gHH5S dH8A== MIME-Version: 1.0 X-Received: by 10.194.88.202 with SMTP id bi10mr418795wjb.5.1360878030136; Thu, 14 Feb 2013 13:40:30 -0800 (PST) Received: by 10.194.5.135 with HTTP; Thu, 14 Feb 2013 13:40:30 -0800 (PST) In-Reply-To: <511D3320.2090001@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511D3320.2090001@alum.mit.edu> Date: Thu, 14 Feb 2013 13:40:30 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:40:33 -0000 On 14 February 2013 10:55, Paul Kyzivat wrote: > I agree we don't need an algorithm to demux anything from anything. > > But we do need a specified way to look at the SDP and know what the > mux/demux algorithm is. The rule for bundling should make that a > prerequisite for any given bundle. That's only necessary if there is a choice of algorithm. As long as you know that you are doing protocol DUCK and protocol GOOSE somehow - and it matters not how, for now - then the DUCK/GOOSE multiplexing rules apply. Where the multiplexed things appear on multiple m= lines, seeing the protocol labels should suffice. As Christer notes, the same applies if you go with the one m= line for all, you still need a way to say that you want to do SCTP over DTLS somewhere, presumably using the same sort of label you would use for multiple m= lines. From dwing@cisco.com Thu Feb 14 13:56:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C101021F86B8 for ; Thu, 14 Feb 2013 13:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.089 X-Spam-Level: X-Spam-Status: No, score=-110.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbjjZCeyxBv4 for ; Thu, 14 Feb 2013 13:56:16 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8878C21F867A for ; Thu, 14 Feb 2013 13:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6900; q=dns/txt; s=iport; t=1360878975; x=1362088575; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=iuTX6KwMSgjiOtDH3T7W09l58ClYWEi2WwZFdpy1Mbg=; b=JNikdV1vI97EX2A8JwaBpWda4+pGuumhvBBQo+W+ls8F9XnhUo03xoWw B62FDxXnW9uALV3KY6557CyK1BOZR61W2clIJ0ge+5+bzod3F6I3ykO/O zHcxNdbUyXx0SZisdnCCNxyV6JFq/QdLmIc0JJ/yvong3TtkvqwnvbG8H Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPZcHVGrRDoH/2dsb2JhbABEDsBdFnOCHwEBAQMBAQEBBQIdEzQQBwEDAgkOAwQBAQEnBxkOHwkIAgQBEgsFC4dxBQ29KI1FhD8DiGaFIYgdgR2PNoJIYIFJ X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="69160832" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 14 Feb 2013 21:56:12 +0000 Received: from DWINGWS01 ([10.154.36.85]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1ELuCHs021154; Thu, 14 Feb 2013 21:56:12 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> In-Reply-To: <511D2982.6040506@alum.mit.edu> Date: Thu, 14 Feb 2013 13:56:12 -0800 Message-ID: <07f401ce0afe$1aa84790$4ff8d6b0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2rchmH/3VuwGSoHuIDLSakeSA2wLHf9y2AxwpgzgBiQx97QHjRS7tAf/E95yXTiCxEA== Content-Language: en-us Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:56:25 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, February 14, 2013 10:14 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: RTP only? > > Harald, > > On 2/14/13 3:24 AM, Harald Alvestrand wrote: > > RTCWEB has a requirement (or rather: it has assumed that there was a > > solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the > > same port pair as SRTP. > > > > If BUNDLE is not going to be that solution, we have to start designing > > another. > > Yes, I know. But nobody has made a proposal that actually encompasses > that desire. I think we have turned over a rock and found a large can of > worms. > > There is a deep connection here between the mechanisms used to demux > packets into separate logical "flows" and the SDP notations used to > describe those flows. > > SDP was designed to describe flows that are demuxed by 3-tuple - > incoming transport type, address, and port. SDP O/A extended that to > describe symmetric pairs of such flows. Restriction to symmetry of > send/recv address/port potentially extends that to demux by 5-tuple. But > we are already on fuzzy ground of SDP expressiveness by that time. > > Now we want to extend that expressiveness to further levels and criteria > for demuxing. The bundle *syntax* lets us describe the things we want to > demux, but without any explicit indication of what demux algorithm to > apply. The existing bundle proposal applies some restrictions on what > can be bundled - presumably to limit it what can be demuxed - but > doesn't explicitly say how to demux. (There are restrictions on use of > payload types across m-lines that suggest an expectation that demux is > to be done based on payload type.) The restrictions it imposes don't > permit bundling RTP and SCTP. > > Unless we want to devolve into a Do What I Mean situation, we need to > find a way to explicitly say what we mean. > > A good start would be to first be *specific* (and exhaustive) about what > we would like to multiplex (without regard to how we will notate that), > and how we propose to mux/demux it. > > There is info out there on how to mux/demux UDP/TLS/RTP/SAVP and > DTLS/SCTP over the same DTLS connection. (Though it isn't immediately > obvious where that is specified.) http://tools.ietf.org/html/rfc5764 explains how to demux RTP (and SRTP), DTLS, and STUN: +----------------+ | 127 < B < 192 -+--> forward to RTP | | packet --> | 19 < B < 64 -+--> forward to DTLS | | | B < 2 -+--> forward to STUN +----------------+ To that, I believe we want to consider SCTP-over-UDP, which I believe was going to be protected with DTLS. So, that looks like this, where DTLS demuxes and processes DTLS handshakes itself and decrypts encrypted payloads and sends them to SCTP. +----------------+ | 127 < B < 192 -+--> forward to RTP | | /SCTP packet --> | 19 < B < 64 -+--> forward to DTLS -< | | \DTLS handshake | B < 2 -+--> forward to STUN +----------------+ -d > Presumably the goal for RTCWEB is to demux distinct MediaStreamTracks > from a single UDP/TLS/RTP/SAVP session. I doubt we want to do that by > payload type. Based on discussion last week, this may sometimes be done > by SSRC, but I think we had cases when multiple SSRCs might map to the > same track, and the mappings may not always be known in advance. CLUE > has further needs, where an SSRC may move about from one "capture- > encoding" to another. (A clue capture-encoding is, I think, more or less > equivalent to an RTCWEB track.) > > So I think we need a serious discussion of mux/demux > criteria/algorithms. This seems to be a prerequisite to a solution to > the bundling problem in MMUSIC. But MMUSIC may not be the proper wg for > this discussion. I don't know which one is. > > Thanks, > Paul > > > On 02/14/2013 04:15 AM, Paul Kyzivat wrote: > >> On 2/13/13 3:08 PM, Christer Holmberg wrote: > >>> > >>> Hi, > >>> > >>>>> (Sorry for sending this to both RTCWEB and MMUSIC, but it is > >>>>> related to both the need of RTCWEB, and the solution produced by > >>>>> MMUSIC) > >>>>> > >>>>> Hi, > >>>>> > >>>>> At the interim, during my BUNDLE presentation, I indicated that we > >>>>> need to make a decision whether the solution (whatever it will > >>>>> be...) shall support bundling of non-RTP media. Not saying it > >>>>> can't be changed, but as currently documented all alternatives > >>>>> only support bundling of RTP media. > >>>>> > >>>>> There might have been some comments from the mic, but as far as I > >>>>> know there was no decision (if there was, please point me to it). > >>>>> > >>>>> So, my question is: do we keep the scope to RTP media? > >>>> > >>>> *If* there is a goal to share a single 5-tuple between RTP and SCTP > >>>> then we need a solution allows bundling them. > >>> > >>> That's another way of presenting my question, yes :) > >>> > >>>> The key to what you can bundle together is not whether it is RTP or > >>>> not. > >>>> It is whether you can specify the mechanism for demuxing the > >>>> 5-tuple and associated the parts with the appropriate m-line in the > >>>> bundle. > >>> > >>> Yes, and the question is whether we need to perform the exercise to > >>> look into that, or if we focus on RTP. > >> > >> We know how to do the demux between DTLS payloads, ICE, and RTP/SRTP > >> payloads. And if we restrict to RTP/SRTP and SCTP over DTLS, then we > >> know how to demux RTP and SCTP. > >> > >> There are various schemes that can be used to demux multiple RTP > >> streams and associate them with individual m-lines in the bundle. > >> > >> What troubles me about it is that the rules for what you can bundle > >> together are dependent on the demux strategy. Describing the rules > >> for this as part of the specification of the bundling mechanism is > >> going to be pretty ugly. I don't see any way to make it clean and > elegant. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From john@jlc.net Thu Feb 14 14:25:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAB421F8A61 for ; Thu, 14 Feb 2013 14:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUYtHnKihRDR for ; Thu, 14 Feb 2013 14:25:09 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60F21F8925 for ; Thu, 14 Feb 2013 14:25:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D90C233D4A; Thu, 14 Feb 2013 17:25:05 -0500 (EST) Date: Thu, 14 Feb 2013 17:25:05 -0500 From: John Leslie To: Matthew Kaufman Message-ID: <20130214222505.GD23183@verdi> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> User-Agent: Mutt/1.4.1i Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:25:11 -0000 Matthew Kaufman wrote: > On Feb 14, 2013, at 10:14 AM, Paul Kyzivat wrote: >> On 2/14/13 3:24 AM, Harald Alvestrand wrote: >> >>> RTCWEB has a requirement (or rather: it has assumed that there was a >>> solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the >>> same port pair as SRTP. (This sentence confuses me, but that's not the point...) >>> If BUNDLE is not going to be that solution, we have to start designing >>> another. Harald posted to MMUSIC and not RTCWEB. I'm not sure I agree that MMUSIC has to start designing that... >> Yes, I know. But nobody has made a proposal that actually encompasses >> that desire. I think we have turned over a rock and found a large can >> of worms. In my career, I have encountered many cans of worms. I take them as a signal that my assumptions may have been faulty. >> There is a deep connection here between the mechanisms used to demux >> packets into separate logical "flows" and the SDP notations used to >> describe those flows. (Thus, trying to change either threatens to reveal worms...) >> SDP was designed to describe flows that are demuxed by 3-tuple - >> incoming transport type, address, and port. SDP O/A extended that to >> describe symmetric pairs of such flows. Restriction to symmetry of >> send/recv address/port potentially extends that to demux by 5-tuple. >> But we are already on fuzzy ground of SDP expressiveness by that time. Is it possibly time to stop digging? >> Now we want to extend that expressiveness to further levels and >> criteria for demuxing. The bundle *syntax* lets us describe the >> things we want to demux, but without any explicit indication of >> what demux algorithm to apply. Am I imagining it, or is the ground starting to shake? >> The existing bundle proposal applies some restrictions on what can >> be bundled - presumably to limit it what can be demuxed - but >> doesn't explicitly say how to demux. (There are restrictions on >> use of payload types across m-lines that suggest an expectation >> that demux is to be done based on payload type.) The restrictions >> it imposes don't permit bundling RTP and SCTP. ISTM that the existing "bundle" isn't a good way to relate RTP and SCTP... >> Unless we want to devolve into a Do What I Mean situation, PLEASE NO!!! >> we need to find a way to explicitly say what we mean. Again, Paul posted to MMUSIC and not RTCWEB. Again, I'm not sure I agree that MMUSIC needs to design that. > Yes, and *only* because RTCWEB turned over the rock *and* continues > to insist that SDP be the way for the developers to "explicitly say > what we mean" are we here in MMUSIC with a big can of worms and some > urgency around coming up with any solution, no matter how ugly. > > There are better ways to construct an API with which developers > could tell the browser what they want it to do, and then MMUSIC > could work on carefully standardizing only what is needed for > interworking cases. Perhaps MMUSIC needs to learn how to say "No" to RTCWEB... In an ideal world, MMUSIC would have already designed what RTCWEB wants. But revisiting basic principles tends to be dangerous and lead to delays. RTCWEB has good folks who could design a way to do what they want without needing MMUSIC to revisit its basic design. IMHO... YMMV... -- John Leslie From mthornbu@adobe.com Thu Feb 14 14:43:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB321F86F6 for ; Thu, 14 Feb 2013 14:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D40TLT8mFsYn for ; Thu, 14 Feb 2013 14:43:26 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2021F8634 for ; Thu, 14 Feb 2013 14:43:19 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUR1ohqNdj8T3CtPcqMeevxHKpHPO3cK7@postini.com; Thu, 14 Feb 2013 14:43:19 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1EMeE1v009861 for ; Thu, 14 Feb 2013 14:40:14 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1EMhIAV005036 for ; Thu, 14 Feb 2013 14:43:18 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 14 Feb 2013 14:43:18 -0800 From: Michael Thornburgh To: "mmusic@ietf.org" Date: Thu, 14 Feb 2013 14:43:16 -0800 Thread-Topic: draft-thornburgh-adobe-rtmfp notice and feedback request Thread-Index: Ac4LBK2YX1ndIHKtQmmM/vzhVwhQqg== Message-ID: <02485FF93524F8408ECA9608E47D9F20092C12DC3A@nambx05.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] draft-thornburgh-adobe-rtmfp notice and feedback request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:43:26 -0000 hi MMUSIC folks. i recently uploaded an Internet-Draft describing a vendor network transport= protocol, "Secure Real-Time Media Flow Protocol (RTMFP)" from Adobe System= s Incorporated. this protocol is the foundation for the real-time and peer= -to-peer communication capabilities in Flash Player and related Adobe produ= cts, which are widely deployed on the Internet today. we believe this tran= sport protocol has applicability beyond Flash and will be of interest to th= e Internet community. this is the protocol presented by Matthew Kaufman to= the TSV Area at IETF-77. we are looking toward this specification being published as an Informationa= l RFC. to that end i am soliciting feedback, comments, and reviews of the = I-D to gauge community interest and to help us improve its quality. i real= ize that this kind of protocol isn't in MMUSIC's charter; however, it was r= ecommended to me that members of this working group should be informed of t= he existence of this I-D. there is IPR associated with this specification, which i have disclosed alo= ng with a royalty-free license declaration. that disclosure/declaration is= linked from the HTML-ized I-D page. --- Filename: draft-thornburgh-adobe-rtmfp Revision: 04 Title: Adobe's Secure Real-Time Media Flow Protocol Creation date: 2013-02-14 Group: Individual Submission Number of pages: 98 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-adobe= -rtmfp-04.txt Status: http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtm= fp Htmlized: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thornburgh-adobe-= rtmfp-04 Abstract: This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. --- thank you. -michael thornburgh From ekr@rtfm.com Thu Feb 14 14:46:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23E821F861C for ; Thu, 14 Feb 2013 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lihTu9QMCKQ for ; Thu, 14 Feb 2013 14:46:31 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4309621F8606 for ; Thu, 14 Feb 2013 14:46:31 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id o13so192415qaj.12 for ; Thu, 14 Feb 2013 14:46:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=syrTHl8rt4ZS4iR551kIIm0b5RULaHtzr8oYWxZ6mYE=; b=ZDua12CmuGcVbfAMen2DnExbvC9ee6xGZ2n1bUp0rjiFxQqZ/B5uNJV1Yz5HNxWNab nnB/qyxAUcAYMDTneEe7q7nzrNkYBdalBQA1yxlLlNTAYTU/bkaQ5D1pp6m+ZU+jOmoX 3KY98hOB0K+9WMgCyMVvSWE2ikrMt0xpA1xXFesHIXmG/incEJ+Ww1j6HLzPp+JMWQep RYVviRTXKmif99NXjdP+0Wlj4SDmMak5+rOGXcT5D+zy+XsFgMVhYSEzwL5vsWA4Grs1 /gEA/t+bfrX29gvs4Vpuvm6CSa4Dgz+3wWM/wLZm9iFFUwe3OEg/3Bgz0HGgnclzTIsu PWZg== X-Received: by 10.229.252.208 with SMTP id mx16mr38292qcb.37.1360881990475; Thu, 14 Feb 2013 14:46:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.130.198 with HTTP; Thu, 14 Feb 2013 14:45:50 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201302141953.r1EJrMT01840535@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> From: Eric Rescorla Date: Thu, 14 Feb 2013 14:45:50 -0800 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001636c5b4a59fa1b804d5b707e0 X-Gm-Message-State: ALoCoQkgFRJkoCBBfnoIaaAPU3sIFYmCnQ3tzXgc0lI+YfMw9Bwfhv853QzmOnbfc+Xk3paBpLTi Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:46:31 -0000 --001636c5b4a59fa1b804d5b707e0 Content-Type: text/plain; charset=ISO-8859-1 I had always assumed that bundle/fumble, etc. (I.e., anything under Cullen's Plan A) would potentially mux all m-lines together. I assumed that Plan B (multiple flows per m-line) would not. -Ekr On Thu, Feb 14, 2013 at 11:53 AM, Dale R. Worley wrote: > > From: Paul Kyzivat > > > > *If* there is a goal to share a single 5-tuple between RTP and SCTP then > > we need a solution allows bundling them. > > Do any of the current proposed bundling techniques include both RTP > and SCTP? > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001636c5b4a59fa1b804d5b707e0 Content-Type: text/html; charset=ISO-8859-1 I had always assumed that bundle/fumble, etc. (I.e., anything under Cullen's
Plan A) would potentially mux all m-lines together. I assumed that Plan B
(multiple flows per m-line) would not.

-Ekr


On Thu, Feb 14, 2013 at 11:53 AM, Dale R. Worley <worley@ariadne.com> wrote:
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>
> *If* there is a goal to share a single 5-tuple between RTP and SCTP then
> we need a solution allows bundling them.

Do any of the current proposed bundling techniques include both RTP
and SCTP?

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

--001636c5b4a59fa1b804d5b707e0-- From pkyzivat@alum.mit.edu Thu Feb 14 14:51:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7360221F884B for ; Thu, 14 Feb 2013 14:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NedsklLEzRKf for ; Thu, 14 Feb 2013 14:51:37 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 0765721F865D for ; Thu, 14 Feb 2013 14:51:36 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id 0Bo41l0071ap0As55Nraqz; Thu, 14 Feb 2013 22:51:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 0NrZ1l00U3ZTu2S3iNrZUw; Thu, 14 Feb 2013 22:51:34 +0000 Message-ID: <511D6A75.2030507@alum.mit.edu> Date: Thu, 14 Feb 2013 17:51:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu>, <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360882294; bh=CZm0ulyGopSPA2KkgBs5vBMTYoztx1vb2wHN6/+Nv08=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gkuUjzq7S0UJNX8gesn4N4RRbeAgVO84gPWI0NXMYpr2pLSv0Pxer0ofXKoQ/zjf8 +gFGzgWI0+WXiGGl1w069H4EmQjfjBGZq/3hB9E+hN8watS5JztMuMSxTYw/LRFIBu ISrDpLtZ8WgpifN4+iNf+19+uUqWlcUv3ePYnm7tM8xL8w0BVo6+41vkrqhdouf9o+ RNpHpJnOEzFADrMTW/7WM+U2+75f5Ab+1NxHGKHIpqQ3arKJzMOfZfPKV7sQASDi49 h+Dt2/ElfxcDd99ih00s8TBX68VzpWCQQwvqsI7aybsUoevEaKH9QzMbm9DIaFcRmF dCR/+wnI1m8jQ== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:51:38 -0000 On 2/14/13 3:13 PM, Christer Holmberg wrote: > Hi Dale, > > I see no reason why BUNDLE couldn't be used also for non-RTP. We would need to consider it when we study the study the SDP attribute impact, though, but that exercise we have to do for RTP anyway. Again this is all to do with how you do the demux. E.g. if you bundled multiple m-lines with a UDP proto then it isn't clear how you could demux them. Thanks, Paul > For MMT it is more tricky. As it only uses a single m= line for the whole bundle, we would need to define a new "MMT" proto value for that m= line (currently the draft uses RTP). Then we would need to, inside the m= line, define a way to specify the proto value for each individual media. > > Regards, > > Christer > ________________________________________ > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Dale R. Worley [worley@ariadne.com] > Sent: Thursday, 14 February 2013 9:53 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: RTP only? > >> From: Paul Kyzivat >> >> *If* there is a goal to share a single 5-tuple between RTP and SCTP then >> we need a solution allows bundling them. > > Do any of the current proposed bundling techniques include both RTP > and SCTP? > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Thu Feb 14 14:52:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA30021F8868 for ; Thu, 14 Feb 2013 14:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOtLLde47ezk for ; Thu, 14 Feb 2013 14:52:29 -0800 (PST) Received: from blu0-omc2-s3.blu0.hotmail.com (blu0-omc2-s3.blu0.hotmail.com [65.55.111.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCFA21F8AD1 for ; Thu, 14 Feb 2013 14:52:28 -0800 (PST) Received: from BLU402-EAS104 ([65.55.111.72]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Feb 2013 14:52:22 -0800 X-EIP: [f3NMskJ/XJ1RzfoywrLIlVQO7wWFh2t/aY0g2iq5rCM=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Eric Rescorla'" References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> In-Reply-To: Date: Thu, 14 Feb 2013 14:52:20 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01CE0AC2.E44FEEE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgMEagmU2KkoKNCNUd66SKhkDAC0qPOmAOF3ggkAkua3u5wCvnOg Content-Language: en-us X-OriginalArrivalTime: 14 Feb 2013 22:52:22.0379 (UTC) FILETIME=[F33AEBB0:01CE0B05] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bernard_aboba@hotmail.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:52:41 -0000 ------=_NextPart_000_0103_01CE0AC2.E44FEEE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ekr said: "I had always assumed that bundle/fumble, etc. (I.e., anything under Cullen's Plan A) would potentially mux all m-lines together. I assumed that Plan B (multiple flows per m-line) would not.' [BA] Plan B multiplexes multiple SSRCs of the same media type (single m line) on the same transport address. Plan A additionally allows for multiplexing of different media types (multiple m lines). So I don't see them as really competing (e.g. it's possible to want to multiplex multiple SSRCs from multiple media types on the same transport address). ------=_NextPart_000_0103_01CE0AC2.E44FEEE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ekr said:

 

“I had always assumed that = bundle/fumble, etc. (I.e., anything under Cullen's

Plan A) would potentially mux all m-lines together. I = assumed that Plan B

(multiple flows per m-line) would not.’

 

[BA] Plan B multiplexes multiple SSRCs of the same media type (single = m line)  on the same transport address.   Plan A = additionally allows for multiplexing of different media types (multiple = m lines).  So I don’t see them as really competing (e.g. = it’s possible to want to multiplex multiple SSRCs from multiple = media types on the same transport address). =

 

 

------=_NextPart_000_0103_01CE0AC2.E44FEEE0-- From pkyzivat@alum.mit.edu Thu Feb 14 15:13:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2721F88F0 for ; Thu, 14 Feb 2013 15:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iipKHWcLps1 for ; Thu, 14 Feb 2013 15:13:21 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 918D721F88BC for ; Thu, 14 Feb 2013 15:13:21 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id 0Cqk1l0080Fqzac51PDMt1; Thu, 14 Feb 2013 23:13:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 0PDL1l01S3ZTu2S3UPDLWv; Thu, 14 Feb 2013 23:13:21 +0000 Message-ID: <511D6F90.2010603@alum.mit.edu> Date: Thu, 14 Feb 2013 18:13:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511D3320.2090001@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360883601; bh=ZCCpzMY+lEEMesqySSQX8hHvm52EUqEXFK4bNyy4H6w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a4H14MYLwgUrZT7FFsKYOIbWr/FeC8jzYuMUZYMNFj9bUZgpDfH1OF4qx20Oi5ex8 9f4Oryl5ckQXhSF7f4HHVC+1Bx9Y7aVwLkNno6RqEAd5bpaWZB3sEETjU/7GZ149mz TZOtSsRWu7gVCIyh62rWYnz2b26Wwda1XjIXnbn34qkTlvYMKDDlDIKoH70a7NF85G UfFTbBa6bWv7Qi1/vawFnP/fzKbu/7H8GwLzGe+bkshi5pU89HEZwNgApbO6d7FCyO rklnIdEx/KJBp+11Ja/oalrqg+iiCMhjR2AmD9jh8pw8d+1PUo+767ufXKOUmGx74p g84VIrzoy4Wxw== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:13:22 -0000 On 2/14/13 4:40 PM, Martin Thomson wrote: > On 14 February 2013 10:55, Paul Kyzivat wrote: >> I agree we don't need an algorithm to demux anything from anything. >> >> But we do need a specified way to look at the SDP and know what the >> mux/demux algorithm is. The rule for bundling should make that a >> prerequisite for any given bundle. > > That's only necessary if there is a choice of algorithm. As long as > you know that you are doing protocol DUCK and protocol GOOSE somehow - > and it matters not how, for now - then the DUCK/GOOSE multiplexing > rules apply. If DUCK and GOOSE are identified in the SDP, and its not necessary to have any other context than that SDP to discover the DUCK/GOOSE multiplexing rules, then I agree with you. (I realize that RTCWEB has another channel that can be used for anything. But depending on that to resolve this would render it inapplicable environments like SIP where the SDP is the only likely place to convey that information. I gather you are not suggesting going that way.) > Where the multiplexed things appear on multiple m= lines, seeing the > protocol labels should suffice. As Christer notes, the same applies > if you go with the one m= line for all, you still need a way to say > that you want to do SCTP over DTLS somewhere, presumably using the > same sort of label you would use for multiple m= lines. The protocol labels should suffice *if* there is some sort of standard or registry that provides a mapping from "bundled protos" to "multiplexing rules". Thanks, Paul From pkyzivat@alum.mit.edu Thu Feb 14 15:21:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0527321F8992 for ; Thu, 14 Feb 2013 15:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbLY+QayvAtN for ; Thu, 14 Feb 2013 15:21:47 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2226121F8600 for ; Thu, 14 Feb 2013 15:21:47 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0PJ21l0031YDfWL51PMmoH; Thu, 14 Feb 2013 23:21:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 0PMm1l0063ZTu2S3gPMmVy; Thu, 14 Feb 2013 23:21:46 +0000 Message-ID: <511D7189.2030003@alum.mit.edu> Date: Thu, 14 Feb 2013 18:21:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dan Wing References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> <07f401ce0afe$1aa84790$4ff8d6b0$@cisco.com> In-Reply-To: <07f401ce0afe$1aa84790$4ff8d6b0$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360884106; bh=FHsEXtBzPjDS0gPtuPVMd1JNc8qIczmBnBJ0b6J+LwM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mg1h+FsMlY2z+bQPdabqzAHX7tlR7REJ5S7Y55e3jY6nJydjW6Ik53/rYuh5UNJFQ aI2NriNHcnH2lerv4IbV+xo2Qs6YM27BJLtgCi7khXX1RZ4E4hE7v8Gf0LZ5YIiwa1 SJrCVwoSgJqdzuoOPtuJoq1MnaNVimietnEZFaNTEDm/P9txYPjVeCuFJ3raQBWpoI +g5LVlU4EaKMneJUGxYIhOYPsE/6A3Ll/RmX9O1NH1LODvqyQJm507zH/XdJgjamu2 KITFMWKMmsidoaR9yfe43cdKuLJQrLHUY+iFp3FQ6W179SIy4/JHTQA0Cj5P5yvNaH 9IyCIn0ycJoMQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:21:48 -0000 On 2/14/13 4:56 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Thursday, February 14, 2013 10:14 AM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE: RTP only? >> >> Harald, >> >> On 2/14/13 3:24 AM, Harald Alvestrand wrote: >>> RTCWEB has a requirement (or rather: it has assumed that there was a >>> solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the >>> same port pair as SRTP. >>> >>> If BUNDLE is not going to be that solution, we have to start designing >>> another. >> >> Yes, I know. But nobody has made a proposal that actually encompasses >> that desire. I think we have turned over a rock and found a large can of >> worms. >> >> There is a deep connection here between the mechanisms used to demux >> packets into separate logical "flows" and the SDP notations used to >> describe those flows. >> >> SDP was designed to describe flows that are demuxed by 3-tuple - >> incoming transport type, address, and port. SDP O/A extended that to >> describe symmetric pairs of such flows. Restriction to symmetry of >> send/recv address/port potentially extends that to demux by 5-tuple. But >> we are already on fuzzy ground of SDP expressiveness by that time. >> >> Now we want to extend that expressiveness to further levels and criteria >> for demuxing. The bundle *syntax* lets us describe the things we want to >> demux, but without any explicit indication of what demux algorithm to >> apply. The existing bundle proposal applies some restrictions on what >> can be bundled - presumably to limit it what can be demuxed - but >> doesn't explicitly say how to demux. (There are restrictions on use of >> payload types across m-lines that suggest an expectation that demux is >> to be done based on payload type.) The restrictions it imposes don't >> permit bundling RTP and SCTP. >> >> Unless we want to devolve into a Do What I Mean situation, we need to >> find a way to explicitly say what we mean. >> >> A good start would be to first be *specific* (and exhaustive) about what >> we would like to multiplex (without regard to how we will notate that), >> and how we propose to mux/demux it. >> >> There is info out there on how to mux/demux UDP/TLS/RTP/SAVP and >> DTLS/SCTP over the same DTLS connection. (Though it isn't immediately >> obvious where that is specified.) > > http://tools.ietf.org/html/rfc5764 explains how to demux RTP (and SRTP), > DTLS, and STUN: > > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | > packet --> | 19 < B < 64 -+--> forward to DTLS > | | > | B < 2 -+--> forward to STUN > +----------------+ > > To that, I believe we want to consider SCTP-over-UDP, which I believe > was going to be protected with DTLS. So, that looks like this, where > DTLS demuxes and processes DTLS handshakes itself and decrypts encrypted > payloads and sends them to SCTP. > > > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | /SCTP > packet --> | 19 < B < 64 -+--> forward to DTLS -< > | | \DTLS handshake > | B < 2 -+--> forward to STUN > +----------------+ > > -d Thanks for the reference. That still leaves unspecified how to demux the RTP relative to the bundled RTP m-lines. ISTM we are going to need a draft that discusses this. I don't know what WG that belongs in. Thanks, Paul From ekr@rtfm.com Thu Feb 14 15:31:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5769621F86DD for ; Thu, 14 Feb 2013 15:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VqjV6M7D+oy for ; Thu, 14 Feb 2013 15:31:04 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id ADA9E21F857B for ; Thu, 14 Feb 2013 15:31:04 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dx4so204150qab.16 for ; Thu, 14 Feb 2013 15:31:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=mfQwgFcLJuJbic+CPvciDF3Nu9L8GpDAqTNULwlnM+U=; b=c1fQg5ZNkmR1e5YFvYhU/3idESuA+gi3UB/+VueIpdtPJzMp2AFzn/jkpY1RjhnQNk 2hvs6G+/FU9eT6XTP6m6gGhLqNnNWbYSqfP78qiQy8xiuvCAePjAwtzg+KI93Kooxgv1 IXY4Sc+VV0PIeA/UZHB90rbaS7VF0XoWDm9qfC3e/Q6J3vPbqlklTeS8UE75l5Bysc1f HF5pe92xKQplOAjNy3mJ82XFt2o5HHS1mkFosA5yUaRFxyKKBmSY35eNd2K7Z0qGqp3n Icpjxc6pU8xNh+VO3lfW8SiyFMB9ULMYYdLQZZgKIQtrzkf3W5pu3kx1xGEOjdeHSvJf IEzQ== X-Received: by 10.229.193.160 with SMTP id du32mr46294qcb.82.1360884664138; Thu, 14 Feb 2013 15:31:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.130.198 with HTTP; Thu, 14 Feb 2013 15:30:23 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> From: Eric Rescorla Date: Thu, 14 Feb 2013 15:30:23 -0800 Message-ID: To: bernard_aboba@hotmail.com Content-Type: multipart/alternative; boundary=00504502b883fc7e3e04d5b7a64b X-Gm-Message-State: ALoCoQmuIaFtNVASQknZGDH24pEXo0C6ZHPa1zkxroOVx86hZ6qoC9NJgw0Te8DK/IEcBqc+/MKk Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:31:05 -0000 --00504502b883fc7e3e04d5b7a64b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2013 at 2:52 PM, Bernard Aboba w= rote: > Ekr said: **** > > ** ** > > =93I had always assumed that bundle/fumble, etc. (I.e., anything under > Cullen's**** > > Plan A) would potentially mux all m-lines together. I assumed that Plan B= * > *** > > (multiple flows per m-line) would not.=92**** > > ** ** > > [BA] Plan B multiplexes multiple SSRCs of the same media type (single m > line) on the same transport address. Plan A additionally allows for > multiplexing of different media types (multiple m lines). So I don=92t s= ee > them as really competing (e.g. it=92s possible to want to multiplex multi= ple > SSRCs from multiple media types on the same transport address). > My sense from what I heard at the interim meeting was that both plan A and plan B would have sufficient levels of multiplexing that people would be willing to forego the other. (though of course the more the better). Perhaps I misunderstood. -Ekr > > ** > --00504502b883fc7e3e04d5b7a64b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 14, 2013 at 2:52 PM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Ekr said:

=A0

= =93I had always assumed that bundle/fumble, etc. (I.e., anything und= er Cullen's

Plan A) would potentially mux all m-lines together. I assumed that Plan= B

(multiple flows per m-line) would n= ot.=92

=A0

[BA] Plan B multiplexes m= ultiple SSRCs of the same media type (single m line) =A0on the same transpo= rt address.=A0 =A0Plan A additionally allows for multiplexing of different = media types (multiple m lines). =A0So I don=92t see them as really competin= g (e.g. it=92s possible to want to multiplex multiple SSRCs from multiple m= edia types on the same transport address).


My sense from what I heard at = the interim meeting was that both plan
A and plan B would have su= fficient levels of multiplexing that people
would be willing to f= orego the other. (though of course the more
the better). Perhaps I misunderstood.

-Ekr

=A0


--00504502b883fc7e3e04d5b7a64b-- From pkyzivat@alum.mit.edu Thu Feb 14 15:31:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5795A21F86DD for ; Thu, 14 Feb 2013 15:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrteZH2B4wtd for ; Thu, 14 Feb 2013 15:31:33 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5E50821F857B for ; Thu, 14 Feb 2013 15:31:32 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id 0CoW1l0061swQuc5FPXXqW; Thu, 14 Feb 2013 23:31:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 0PXX1l00f3ZTu2S3bPXXkU; Thu, 14 Feb 2013 23:31:31 +0000 Message-ID: <511D73D3.5020608@alum.mit.edu> Date: Thu, 14 Feb 2013 18:31:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360884691; bh=L6LyKtKL9kQu9Sv1lt3A4oA3uuAoqKIwoS8gnDuoSjo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LHbkMv2CAaamRHyoxEnaIFyhXY/JBlVaRyrFFolYoJ89PNw2aWeFj4+M8giKbuGCi nPbmntBFCIiUaer22uQIwG4NcI9njdv78tXkBwJzZX+53fZEcO8VOMJfC5g6RzPBcg hcGY+SowirxZr2+fZAWDcfoQSbgazhsZsB6isVRHQPhpzCXW9OQD4scijwgSGH9e1E fq1s7vH+6ohXpq/iaTlyR1nAoqvlZDKyUFnCWqIeRtifbqY5Jb9yPF0JcDhiXzujhD lmtPyXezt/g1utvwMLhM2ccMjnjNzxO/X0kQ11kdbc1Knqvldoow6+l0tSis1SVCa3 MSBnjAWjtLITw== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:31:33 -0000 On 2/14/13 5:52 PM, Bernard Aboba wrote: > Ekr said: > > “I had always assumed that bundle/fumble, etc. (I.e., anything under > Cullen's > > Plan A) would potentially mux all m-lines together. I assumed that Plan B > > (multiple flows per m-line) would not.’ > > [BA] Plan B multiplexes multiple SSRCs of the same media type (single m > line) on the same transport address. Plan A additionally allows for > multiplexing of different media types (multiple m lines). So I don’t > see them as really competing (e.g. it’s possible to want to multiplex > multiple SSRCs from multiple media types on the same transport address). IIUC, Plan A expects a single "flow" (track) per m-line, and uses stuff in the SDP to identify exactly which track it is. So it requires demux of each "flow" to a particular m-line. I'm not sure how that was expected to work. Thanks, Paul From dwing@cisco.com Thu Feb 14 15:43:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D6D21F871C for ; Thu, 14 Feb 2013 15:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyvBvoiscs67 for ; Thu, 14 Feb 2013 15:43:22 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9069221F86FC for ; Thu, 14 Feb 2013 15:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6560; q=dns/txt; s=iport; t=1360885402; x=1362095002; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=SNh4diAv6R9CwAQKnIFsbo8aLTAVzXUKqdvgq46ztkw=; b=Rwtxq6TICuE5CPivSUsSuIu85mm4JFuFjikUk6/NuYYbclvqKPwDuvxV 7NHElbHM0w9z8TL34XQqnNJK773m06CkqkRbzHBOMs39f+Mg6ASKptcwu EBvcxW7kGjbK5x9Bxd0G0eZXPHUcyo0bfgOmSTVPHINq8HS5LcWHwYXRt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPh1HVGrRDoJ/2dsb2JhbABFwFYWc4IfAQEBAwEBAQEFAgJiCwUHAQECAgkRBAEBARUSBxkCDB8DAQUIAgQBEgsFh3wFDb0vBI1BBQGBA4M2A4gwNoUhiB2BHY82gyiBSQgX X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="69696544" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Feb 2013 23:43:22 +0000 Received: from DWINGWS01 ([10.154.36.85]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1ENhL04031474; Thu, 14 Feb 2013 23:43:21 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'Emil Ivov'" References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> In-Reply-To: <511D07F1.3070808@ericsson.com> Date: Thu, 14 Feb 2013 15:43:21 -0800 Message-ID: <085d01ce0b0d$12dbfb10$3893f130$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEzjPbQxUzVAxWufG5eY2LeHo6PAE3VhFkAl3CtsIB+REApAJspBJ/mEyj09A= Content-Language: en-us Cc: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'mmusic' Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:43:23 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, February 14, 2013 7:51 AM > To: Emil Ivov > Cc: Ari Ker=E4nen; 'mmusic'; Dan Wing > Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks >=20 > On 2013-02-14 16:36, Emil Ivov wrote: > > Any idea why there had to be different pacing for RTP and non-RTP > > flows in the first place? >=20 > I think our arguments where that in the context of a non-congestion > controlled voice application it would send with 20 ms interval anyway. > For other transports and protocols it was not obvious for what = intended > environment it would be used. For example a low power network > application that sends beyond 30 kbps could be problematic. Thus we = took > one of our conservative values from the transport books, i.e. 500 ms. >=20 > I would point out that this is a difficult transport issue. Compared = to > TCP IW10, that burst occurs first after the initial handshake when one > has actually established that there is a responder. >=20 > With ICE there is a clear issue with an attacker bloating a = offer/answer > with candidates that recreates the voice hammer attack using ICE's = STUN > checks towards a target address or domain. >=20 > Also the STUN checks will have different source address pairs which in > it self could be an issue for attack prevention firewalls etc. >=20 > Thus I would be careful with speeding up Ta for RTP to much, and I = think > someone needs to fine empiric data that it would work. >=20 > For the the 500 ms that can likely be significantly lowered without = any > issues. But some considerations around the wider usage needs to be = taken > into account. Most of those concerns are for the ICE connectivity checks (to the = remote peer). There are different concerns for the initial STUN (and TURN)=20 communications to the STUN/TURN servers, which are the communications that create the NAT (or firewall) mappings. I noticed the two different concerns are nicely written in http://tools.ietf.org/html/rfc5245#appendix-B.1 Question, playing devil's advocate: is the voice hammer attack (or a STUN connectivity check hammer attack) worse than a web page full of HTML IMG tags pointing at a victim's web server, which I believe has no protection or pacing? Has such an HTML IMG attack been a real problem, or do we consider it will be a problem? -d > Cheers >=20 > Magnus > One of the ADs responsible for the pacing in ICE. >=20 > > > > Emil > > > > On 14.02.13, 16:32, Ari Ker=E4nen wrote: > >> On 2/14/13 5:20 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Ari Ker=E4nen > >>>> Sent: Thursday, February 14, 2013 5:49 AM > >>>> To: mmusic > >>>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks > >>>> > >>>> Hi all, > >>>> > >>>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic = (for > >>>> background, see [1] and [2]), as discussed at the Atlanta = meeting, > >>>> will be one of the important changes in the new version of ICE. > >>>> > >>>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be > >>>> configurable, SHOULD have a default of 500 ms, and MUST NOT be > >>>> configurable to be less than 500 ms." > >>>> > >>>> This results in very slow pace of starting connectivity checks if > >>>> ICE is used with non-RTP traffic. With RTP, the Ta is calculated > >>>> based on the expected bandwidth used by the RTP stream and can be > down to 20 ms. > >>>> Therefore, many current implementations apparently ignore the = "MUST > NOT" > >>>> above and set Ta to something lower. > >>> > >>> That would explain failures claimed to justify the desire for > >>> running over one port. > >> > >> Interesting point. Does anyone know what kind of pacing was = actually > >> used when these failures were observed? > >> > >>> The 20ms threshold for the initial connectivity checks is because > >>> some NATs could not create new mappings quickly. This problems > >>> appears to persist today, considering that both Chrome and Windows = 8 > >>> limit their number of outstanding DNS queries in an apparent = attempt > >>> to work around that very same NAT UDP mapping behavior. > >>> > >>> If trying to create NAT mappings with 0ms pacing, it will = certainly > >>> cause NAT mapping failures and force retries. > >> > >> Yes, definitely. So we shouldn't go below 20ms with non-RTP either. > >> Perhaps need to add some more justification/warning text about this > too. > >> > >>>> The quite conservative value of 500 ms was originally chosen > >>>> because of the fear of congesting the links with the connectivity > check messages. > >>>> This is obviously still a valid concern, but would suggesting > >>>> something lower still make sense? How low would it be reasonably > >>>> safe to go? What is currently used in practice? Can we come up = with > >>>> a formula similar to RTP (perhaps based on expected bandwidth > usage)? > >>> > >>> A good question for the transport area, which is the origination = of > >>> the suggestion to send ICE connectivity checks paced to not exceed > >>> the bandwidth of the subsequent media. Perhaps the arguments that > >>> TCP > >>> IW=3D10 is not harmful could be brought to the party. > >> > >> FYI, I forwarded the original mail to the Transport ADs too. > >> > >> > >> Cheers, > >> Ari > >> > >>>> > >>>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 > >>>> [2] http://tools.ietf.org/html/rfc5245#section-16.2 > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From matthew@matthew.at Thu Feb 14 15:46:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5421F89FB for ; Thu, 14 Feb 2013 15:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v16p4UaZGmos for ; Thu, 14 Feb 2013 15:46:38 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06A21F89EF for ; Thu, 14 Feb 2013 15:46:38 -0800 (PST) Received: from [192.168.1.114] (unknown [71.92.88.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 4B2AC230005; Thu, 14 Feb 2013 15:46:38 -0800 (PST) References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <085d01ce0b0d$12dbfb10$3893f130$@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <085d01ce0b0d$12dbfb10$3893f130$@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Matthew Kaufman Date: Thu, 14 Feb 2013 15:46:40 -0800 To: Dan Wing Cc: Magnus Westerlund , =?utf-8?Q?Ari_Ker=C3=A4nen?= , mmusic Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:46:39 -0000 On Feb 14, 2013, at 3:43 PM, "Dan Wing" wrote: >=20 > Question, playing devil's advocate: is the voice hammer attack (or a > STUN connectivity check hammer attack) worse than a web page full of > HTML IMG tags pointing at a victim's web server, which I believe has > no protection or pacing? Has such an HTML IMG attack been a real > problem, or do we consider it will be a problem? Most browsers do have a limit for the number of simultaneous IMG loads, some= even more so if they all appear to be pointed at the same domain. Matthew Kaufman= From dwing@cisco.com Thu Feb 14 15:55:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672C621F85E6 for ; Thu, 14 Feb 2013 15:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.216 X-Spam-Level: X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx4ft7497kld for ; Thu, 14 Feb 2013 15:55:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 405E421F85DF for ; Thu, 14 Feb 2013 15:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1341; q=dns/txt; s=iport; t=1360886101; x=1362095701; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0SlCAH8pwK3Jupb7C5gdYwK6OP095GDXVMwwDm8PSy8=; b=XDom5SebXiOXDbOy1oRIogTqhKrRWa5BBQegN4bU3TmqIWyh9aMCbjPu eC6sa1RGD3XqQubUGrmgZfZT99eWLaaL4ey7RRzIk15lknR6O+LvCIrU1 NMjQydIFowhUYKEcoZvaxlMhYOPg6mTtRf35t/M4iuNpNVDJF3Jl/1EbF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABN4HVGrRDoJ/2dsb2JhbABFwFsWc4IfAQEBBAgCbwwBAwIJEQQBAQEnBxktCQgCBBMLBYgBvSeNRYQ/A4gwNoUhiB2QU4MogUk X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="72273701" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Feb 2013 23:55:00 +0000 Received: from DWINGWS01 ([10.154.36.85]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1ENt0sf004817; Thu, 14 Feb 2013 23:55:00 GMT From: "Dan Wing" To: "'Matthew Kaufman'" References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <085d01ce0b0d$12dbfb10$3893f130$@cisco.com> In-Reply-To: Date: Thu, 14 Feb 2013 15:55:00 -0800 Message-ID: <086d01ce0b0e$b35a2480$1a0e6d80$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEzjPbQxUzVAxWufG5eY2LeHo6PAE3VhFkAl3CtsIB+REApAJspBJ/AmM1OvkCVE8nupgm7a4w Content-Language: en-us Cc: 'Magnus Westerlund' , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'mmusic' Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:55:05 -0000 > -----Original Message----- > From: Matthew Kaufman [mailto:matthew@matthew.at] > Sent: Thursday, February 14, 2013 3:47 PM > To: Dan Wing > Cc: Magnus Westerlund; Emil Ivov; Ari Ker=E4nen; mmusic > Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks >=20 >=20 >=20 > On Feb 14, 2013, at 3:43 PM, "Dan Wing" wrote: >=20 > > > > Question, playing devil's advocate: is the voice hammer attack (or = a > > STUN connectivity check hammer attack) worse than a web page full of > > HTML IMG tags pointing at a victim's web server, which I believe has > > no protection or pacing? Has such an HTML IMG attack been a real > > problem, or do we consider it will be a problem? >=20 > Most browsers do have a limit for the number of simultaneous IMG = loads, > some even more so if they all appear to be pointed at the same domain. >=20 > Matthew Kaufman=3D I guess you are referring to the per-server HTTP connection limit, but=20 I am guessing on your reference. If so, perhaps modeling the ICEbis=20 limits (for ICE connectivity checks) on that design is a straw man=20 we should consider. If not, perhaps you could clarify what Most Browsers do regarding such a crafted web page (which of course need not be IMG, but any HTML tag that pulls content from another host). -d From pkyzivat@alum.mit.edu Thu Feb 14 16:25:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1096721F8630 for ; Thu, 14 Feb 2013 16:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csvPY7kf3wqp for ; Thu, 14 Feb 2013 16:25:12 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC121F8619 for ; Thu, 14 Feb 2013 16:25:12 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id 0QCW1l0030xGWP85FQRBZ6; Fri, 15 Feb 2013 00:25:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 0QRB1l00d3ZTu2S3YQRBCp; Fri, 15 Feb 2013 00:25:11 +0000 Message-ID: <511D8067.5030101@alum.mit.edu> Date: Thu, 14 Feb 2013 19:25:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> In-Reply-To: <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360887911; bh=RGnFtabq9Yl4qZDffDarJdVN1kNYYVFAoi96JouUJZU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HbIWfrvoHE/dWWq997A6kKkbEz+pIk5DDrlKZPbct529Ij3M4ca46yKMF1ZiK+4nC y8GqlyQa1lg/cuZqD/bvsmoEEkNSv7cp4fDQ0lDTQDHtk5JRBySeCgiaZQAoyw8ky7 4KD9E6dBlCIYhhinfwh0C71qWXksUkmGs+v7pnmesdK+85zkZinj28XiQ59BQ68wpr zWEkDuehAjVu7C7uBWkhyXArdxe9iEcU+ymCfXvMu5htPYDSj8zIrnSTfxWdzHbDWy zLg9WO1mecgeSpj0ZpaKE7eSRZRC6oTslznPMN1YAgqYSS9wwdgnDCTTCbPrXK9o8C HulG+sqeWZoLw== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 00:25:13 -0000 On 2/14/13 4:10 PM, Matthew Kaufman wrote: > > > On Feb 14, 2013, at 10:14 AM, Paul Kyzivat wrote: >>> >> >> Yes, I know. But nobody has made a proposal that actually encompasses that desire. I think we have turned over a rock and found a large can of worms. >> >> There is a deep connection here between the mechanisms used to demux packets into separate logical "flows" and the SDP notations used to describe those flows. >> >> SDP was designed to describe flows that are demuxed by 3-tuple - incoming transport type, address, and port. SDP O/A extended that to describe symmetric pairs of such flows. Restriction to symmetry of send/recv address/port potentially extends that to demux by 5-tuple. But we are already on fuzzy ground of SDP expressiveness by that time. >> >> Now we want to extend that expressiveness to further levels and criteria for demuxing. The bundle *syntax* lets us describe the things we want to demux, but without any explicit indication of what demux algorithm to apply. The existing bundle proposal applies some restrictions on what can be bundled - presumably to limit it what can be demuxed - but doesn't explicitly say how to demux. (There are restrictions on use of payload types across m-lines that suggest an expectation that demux is to be done based on payload type.) The restrictions it imposes don't permit bundling RTP and SCTP. >> >> Unless we want to devolve into a Do What I Mean situation, we need to find a way to explicitly say what we mean. >> > > Yes, and *only* because RTCWEB turned over the rock *and* continues to insist that SDP be the way for the developers to "explicitly say what we mean" are we here in MMUSIC with a big can of worms and some urgency around coming up with any solution, no matter how ugly. > > There are better ways to construct an API with which developers could tell the browser what they want it to do, and then MMUSIC could work on carefully standardizing only what is needed for interworking cases. I realize that for RTCWEB the browser is always in the middle, but this is really about telling the other endpoint what you want to do, since these media streams are e2e. If this isn't done in SDP then it won't be available to SIP endpoints. Thanks, Paul From matthew@matthew.at Thu Feb 14 16:55:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61A121F858B for ; Thu, 14 Feb 2013 16:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYUFF+u3WFZC for ; Thu, 14 Feb 2013 16:55:34 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4568221F857C for ; Thu, 14 Feb 2013 16:55:34 -0800 (PST) Received: from [192.168.1.114] (unknown [71.92.88.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 08E691480C4; Thu, 14 Feb 2013 16:55:34 -0800 (PST) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> <511D8067.5030101@alum.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <511D8067.5030101@alum.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <92841761-9A2D-45BA-B969-6F07A06F4900@matthew.at> X-Mailer: iPad Mail (10A523) From: Matthew Kaufman Date: Thu, 14 Feb 2013 16:55:37 -0800 To: Paul Kyzivat Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 00:55:34 -0000 On Feb 14, 2013, at 4:25 PM, Paul Kyzivat wrote: > On 2/14/13 4:10 PM, Matthew Kaufman wrote: >>=20 >>=20 >> On Feb 14, 2013, at 10:14 AM, Paul Kyzivat wrote:= >>>=20 >>> Yes, I know. But nobody has made a proposal that actually encompasses th= at desire. I think we have turned over a rock and found a large can of worms= . >>>=20 >>> There is a deep connection here between the mechanisms used to demux pac= kets into separate logical "flows" and the SDP notations used to describe th= ose flows. >>>=20 >>> SDP was designed to describe flows that are demuxed by 3-tuple - incomin= g transport type, address, and port. SDP O/A extended that to describe symme= tric pairs of such flows. Restriction to symmetry of send/recv address/port p= otentially extends that to demux by 5-tuple. But we are already on fuzzy gro= und of SDP expressiveness by that time. >>>=20 >>> Now we want to extend that expressiveness to further levels and criteria= for demuxing. The bundle *syntax* lets us describe the things we want to de= mux, but without any explicit indication of what demux algorithm to apply. T= he existing bundle proposal applies some restrictions on what can be bundled= - presumably to limit it what can be demuxed - but doesn't explicitly say h= ow to demux. (There are restrictions on use of payload types across m-lines t= hat suggest an expectation that demux is to be done based on payload type.) T= he restrictions it imposes don't permit bundling RTP and SCTP. >>>=20 >>> Unless we want to devolve into a Do What I Mean situation, we need to fi= nd a way to explicitly say what we mean. >>=20 >> Yes, and *only* because RTCWEB turned over the rock *and* continues to in= sist that SDP be the way for the developers to "explicitly say what we mean"= are we here in MMUSIC with a big can of worms and some urgency around comin= g up with any solution, no matter how ugly. >>=20 >> There are better ways to construct an API with which developers could tel= l the browser what they want it to do, and then MMUSIC could work on careful= ly standardizing only what is needed for interworking cases. >=20 > I realize that for RTCWEB the browser is always in the middle, > but this is really about telling the other endpoint what you want to do, > since these media streams are e2e. Browser to browser e2e streams can be signaled through whatever means the de= veloper of the end to end application comes up with... >=20 > If this isn't done in SDP then it won't be available to SIP endpoints. Right. But maybe not every possible combination is needed when working with S= IP endpoints, and maybe, just maybe, the artificial urgency created by RTCWE= B's need to have this fully specified yesterday wouldn't be putting us at se= rious risk of a bad solution to what is likely much more complicated than an= yone has yet imagined. Matthew Kaufman= From christer.holmberg@ericsson.com Thu Feb 14 23:35:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CFC21F8801 for ; Thu, 14 Feb 2013 23:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XMWqBs4mRJu for ; Thu, 14 Feb 2013 23:35:31 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFEBE21F8477 for ; Thu, 14 Feb 2013 23:35:30 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-47-511de54184f3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.D9.10459.145ED115; Fri, 15 Feb 2013 08:35:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 08:35:29 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: RTP only? Thread-Index: AQHOCuzxeB8ChmgfTeKF683MxdSffph5xzB1gAAd3oCAAKH8EA== Date: Fri, 15 Feb 2013 07:35:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu>, <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> In-Reply-To: <511D6A75.2030507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja7jU9lAg4PrjC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj+Z6rLAW/+CvubHrO3sD4maeLkZNDQsBE YsvVs6wQtpjEhXvr2boYuTiEBA4xSrw9fZsRwlnCKPH85nSgDAcHm4CFRPc/bZAGEQFfiWeP b7OB2MIC6hKzN29gh4hrSJx6fo8FwnaSuDDjE9gCFgFViXu7tzOB2LwC3hLrbl2Dmt/BJLHh 4T5mkASngI7E363XwYoYgS76fmoNmM0sIC5x68l8JohLBSSW7DnPDGGLSrx8/A/qA0WJnWfb mSHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye9 3HATIzAaDm75rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw mr9wPjeT2y/bKmxR/9SNInMumm5fIMzCUxuZWbs//thXj6Ijyydft/8RfH92Tp690d0Sk8ay C0uv8H/UETut8bdx172/ayKOH85xmqi4dOVtq3UC+3K9Zr4r8ioXjclOm89lvitK4Mi9uZ1/ +520wpmSlq689IZ5yuGEU5d/f/hYdex6m5HEEiWW4oxEQy3mouJEAKQ9iJlUAgAA Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 07:35:31 -0000 Hi, >> I see no reason why BUNDLE couldn't be used also for non-RTP. We would n= eed to consider it when we study the study the SDP attribute impact, though= , but that exercise we have to do for RTP anyway. > > Again this is all to do with how you do the demux. > E.g. if you bundled multiple m-lines with a UDP proto then it isn't clear= how you could demux them. Sure. If it is not possible to demux a protocol, then you obviously can't d= o it. But, the scope of BUNDLE is not really to solve those kind of problems. The= scope is to define how the demuxing, when it can be done, is negotiated on= a signaling level, and what restrictions etc there are associated with tha= t.. Regards, Christer > For MMT it is more tricky. As it only uses a single m=3D line for the who= le bundle, we would need to define a new "MMT" proto value for that m=3D li= ne (currently the draft uses RTP). Then we would need to, inside the m=3D l= ine, define a way to specify the proto value for each individual media. > > Regards, > > Christer > ________________________________________ > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of=20 > Dale R. Worley [worley@ariadne.com] > Sent: Thursday, 14 February 2013 9:53 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: RTP only? > >> From: Paul Kyzivat >> >> *If* there is a goal to share a single 5-tuple between RTP and SCTP=20 >> then we need a solution allows bundling them. > > Do any of the current proposed bundling techniques include both RTP=20 > and SCTP? > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri Feb 15 08:10:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D559F21F8738 for ; Fri, 15 Feb 2013 08:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXvBXWL1U-wH for ; Fri, 15 Feb 2013 08:10:26 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 12F7C21F8734 for ; Fri, 15 Feb 2013 08:10:25 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id 0eb91l0050QuhwU54gARiQ; Fri, 15 Feb 2013 16:10:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 0gAR1l00W3ZTu2S3NgARym; Fri, 15 Feb 2013 16:10:25 +0000 Message-ID: <511E5DF0.9020204@alum.mit.edu> Date: Fri, 15 Feb 2013 11:10:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu>, <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360944625; bh=vzaa4aIrkVlJkr9C+De0AOmfJxrAWKufAExbuy6DmOQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Wl6ZZ94gxcLz6FeT6QOt46tR8XyuHvzG8y+t9ImKN/aUNoeFnsvBGkJ3uHMO3WkOf BeRZwn5HNGmdmQdyEuf978e6f8SVRzD+mDXjVz37aH372uriCo3vfpOU7L4zJumZk/ VFwsXllxHtQrn/GYxTwKgxJ1vYhwS4jd6I+ygw3EdNTzhP5+09Uea670NH52prVvua zNp/zpuXc8K+uAHa9k0HsvQckPIzPSpZK0169zQqjSwZUNUSdgza+8LGZGxPHGgnAi uklWq/9e99rLq1RbrPv3mgCwIv1g3PszCFVnHAweE/xZ+KPkLtBiwRq1cHsltg6U4n K93omuc0wJ1Ig== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:10:27 -0000 On 2/15/13 2:35 AM, Christer Holmberg wrote: > Hi, > >>> I see no reason why BUNDLE couldn't be used also for non-RTP. We would need to consider it when we study the study the SDP attribute impact, though, but that exercise we have to do for RTP anyway. >> >> Again this is all to do with how you do the demux. >> E.g. if you bundled multiple m-lines with a UDP proto then it isn't clear how you could demux them. > > Sure. If it is not possible to demux a protocol, then you obviously can't do it. > > But, the scope of BUNDLE is not really to solve those kind of problems. The scope is to define how the demuxing, when it can be done, is negotiated on a signaling level, and what restrictions etc there are associated with that.. No, BUNDLE doesn't need to solve the problem. But it does require that there be a solution to the problem. And IMO it requires that the mux/demux mechanism be determinable from the SDP. ISTM that a *start* is to ensure that bundle combinations we care about have mux/demux algorithms documented someplace that can be referenced. Then we reference those in the bundle draft, or create a registry and reference that from the bundle draft. Thanks, Paul > Regards, > > Christer > > > > >> For MMT it is more tricky. As it only uses a single m= line for the whole bundle, we would need to define a new "MMT" proto value for that m= line (currently the draft uses RTP). Then we would need to, inside the m= line, define a way to specify the proto value for each individual media. >> >> Regards, >> >> Christer >> ________________________________________ >> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of >> Dale R. Worley [worley@ariadne.com] >> Sent: Thursday, 14 February 2013 9:53 PM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE: RTP only? >> >>> From: Paul Kyzivat >>> >>> *If* there is a goal to share a single 5-tuple between RTP and SCTP >>> then we need a solution allows bundling them. >> >> Do any of the current proposed bundling techniques include both RTP >> and SCTP? >> >> Dale >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri Feb 15 08:18:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE41A21F895F for ; Fri, 15 Feb 2013 08:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcbJf+cyNd0K for ; Fri, 15 Feb 2013 08:18:28 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id F2B5A21F8964 for ; Fri, 15 Feb 2013 08:18:27 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0fWB1l0230SCNGk53gJTSe; Fri, 15 Feb 2013 16:18:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 0gJT1l00J3ZTu2S3VgJTVr; Fri, 15 Feb 2013 16:18:27 +0000 Message-ID: <511E5FD1.1080602@alum.mit.edu> Date: Fri, 15 Feb 2013 11:18:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> <511D2982.6040506@alum.mit.edu> <9C09193B-1ABF-4A3B-9A92-C70314581BA9@matthew.at> <511D8067.5030101@alum.mit.edu> <92841761-9A2D-45BA-B969-6F07A06F4900@matthew.at> In-Reply-To: <92841761-9A2D-45BA-B969-6F07A06F4900@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360945107; bh=tqJC/jnuuOlhIn0bfH7As1R7xNcEGGA2/eTJZF1/e2U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hYTNPzIu1FpYzvJ9hPgHpzw2mqUsQXpVeA+3/vLv8svCiSvtw0ifckZBXbNbVrgHW cmzxD0LoSGWenuFUCSZot2TZLZkw1e8T8RMeY0nHqFTI0rVZGGC7F804ubXClAJuvT GdnfHZUxO1tImfHw7uyN8CahuJIm9eSX/eilocJRKd69NqxMRBHHgLoUEsbDhUW7X9 KPy8oWKfDE0X/oneN/FOrvcFz0BzT/8Uo1/q8d43Fqeg/exXKGsYga7+PfOm3UQfPt SZtKa+sQnWkchw9AlbsOdcc28pqv22u9TfIRp7ddmaqGKkkcYHlgxlUkYx+IDnrkVg I5aw+l3vbGBuQ== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:18:28 -0000 On 2/14/13 7:55 PM, Matthew Kaufman wrote: > > > On Feb 14, 2013, at 4:25 PM, Paul Kyzivat wrote: > >> On 2/14/13 4:10 PM, Matthew Kaufman wrote: >>> >>> >>> On Feb 14, 2013, at 10:14 AM, Paul Kyzivat wrote: >>>> >>>> Yes, I know. But nobody has made a proposal that actually encompasses that desire. I think we have turned over a rock and found a large can of worms. >>>> >>>> There is a deep connection here between the mechanisms used to demux packets into separate logical "flows" and the SDP notations used to describe those flows. >>>> >>>> SDP was designed to describe flows that are demuxed by 3-tuple - incoming transport type, address, and port. SDP O/A extended that to describe symmetric pairs of such flows. Restriction to symmetry of send/recv address/port potentially extends that to demux by 5-tuple. But we are already on fuzzy ground of SDP expressiveness by that time. >>>> >>>> Now we want to extend that expressiveness to further levels and criteria for demuxing. The bundle *syntax* lets us describe the things we want to demux, but without any explicit indication of what demux algorithm to apply. The existing bundle proposal applies some restrictions on what can be bundled - presumably to limit it what can be demuxed - but doesn't explicitly say how to demux. (There are restrictions on use of payload types across m-lines that suggest an expectation that demux is to be done based on payload type.) The restrictions it imposes don't permit bundling RTP and SCTP. >>>> >>>> Unless we want to devolve into a Do What I Mean situation, we need to find a way to explicitly say what we mean. >>> >>> Yes, and *only* because RTCWEB turned over the rock *and* continues to insist that SDP be the way for the developers to "explicitly say what we mean" are we here in MMUSIC with a big can of worms and some urgency around coming up with any solution, no matter how ugly. >>> >>> There are better ways to construct an API with which developers could tell the browser what they want it to do, and then MMUSIC could work on carefully standardizing only what is needed for interworking cases. >> >> I realize that for RTCWEB the browser is always in the middle, >> but this is really about telling the other endpoint what you want to do, >> since these media streams are e2e. > > Browser to browser e2e streams can be signaled through whatever means the developer of the end to end application comes up with... What about browser to non-browser app? E.g. CLUE in a browser to clue in a server. >> If this isn't done in SDP then it won't be available to SIP endpoints. > > Right. But maybe not every possible combination is needed when working with SIP endpoints, and maybe, just maybe, the artificial urgency created by RTCWEB's need to have this fully specified yesterday wouldn't be putting us at serious risk of a bad solution to what is likely much more complicated than anyone has yet imagined. There will be at least *some* combinations that are needed when working with SIP endpoints. Maybe we at least figure out a solution that works for those. Thanks, Paul From worley@shell01.TheWorld.com Fri Feb 15 08:35:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3B921F8801 for ; Fri, 15 Feb 2013 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXdbrt3+z1TZ for ; Fri, 15 Feb 2013 08:35:32 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CBBE921F87D2 for ; Fri, 15 Feb 2013 08:35:30 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FGYE8G016920 for ; Fri, 15 Feb 2013 11:34:17 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FGYE7X1890205 for ; Fri, 15 Feb 2013 11:34:14 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FGYETg1892895; Fri, 15 Feb 2013 11:34:14 -0500 (EST) Date: Fri, 15 Feb 2013 11:34:14 -0500 (EST) Message-Id: <201302151634.r1FGYETg1892895@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <085d01ce0b0d$12dbfb10$3893f130$@cisco.com> Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:35:32 -0000 > From: Matthew Kaufman > > Most browsers do have a limit for the number of simultaneous IMG > loads, some even more so if they all appear to be pointed at the > same domain. IIRC, browsers aren't supposed to have more than two TCP connections to any one server name. Though I suppose you can get around that by creating a zillion A records in your private domain that all point to the same IP address. RFC 2616 (HTTP/1.1) section 8.1.4 Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. Dale From fluffy@cisco.com Fri Feb 15 08:36:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E2921F8801 for ; Fri, 15 Feb 2013 08:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qrmdCoK1lWs for ; Fri, 15 Feb 2013 08:36:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8E21F87D2 for ; Fri, 15 Feb 2013 08:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6932; q=dns/txt; s=iport; t=1360946178; x=1362155778; h=from:to:cc:subject:date:message-id:references: mime-version; bh=Ot29BaD5IG0/R62cC+HPkOe84LlgGzI2DeoFKh8H+oQ=; b=NcegafzyiCzKvEe0t5qFGb9UKtSqoqQkEcYAHJM41RpGA2shHe6oXqIn j/GoekuEsak4obGW/aBcszxdx/nbHZNip5kMcPXl4baeLrlZYl70SUOZp edJXEyf2SELj5cbfzVsdY7VmgCodYJ+fHjatVjEGg6UEOsRQEcqXEq1hl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHpjHlGtJV2d/2dsb2JhbAAqFwO/b3wWc4IgAQEEZhMQAgEcDgoEDAoyJAECAQMODYgKDC2uT44ejV0bgQItBBgHgkdhA5dFjziCNlGBcjU X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; d="scan'208,217";a="177604207" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 15 Feb 2013 16:36:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1FGaH2X022420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 16:36:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 10:36:17 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org (E-mail)" Thread-Topic: Call about Bundle Ports Feb 21 Thread-Index: AQHOC5qT7lCiNcVIEk6g/IzOibGGRA== Date: Fri, 15 Feb 2013 16:36:17 +0000 Message-ID: References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: multipart/alternative; boundary="_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133E51C1xmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:36:22 -0000 --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133E51C1xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As discussed at the interim, Richard and I are planning to have a call to d= iscuss issues around the same port or different ports in bundle. This is no= t an official WG call or anything but anyone is welcome to join us on the c= all. Bridge info below. Cullen Cullen Jennings invites you to attend this online meeting. Topic: Bundle Ports Date: Thursday, February 21, 2013 Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 207 772 340 Meeting Password: ietf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID= =3D0&PW=3DNMjYwN2JjNzYz&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: ietf 4. Click "Join Now". To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&PW=3DN= MjYwN2JjNzYz&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3= e2Gw&RT=3DMiM0 --_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133E51C1xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2158D11E9C804A4295B58F1C2B975BA6@cisco.com> Content-Transfer-Encoding: quoted-printable

Hi All,

As discussed at the interim, Richard and I are planning to have a call= to discuss issues around the same port or different ports in bundle. This = is not an official WG call or anything but anyone is welcome to join us on = the call. Bridge info below. 

Cullen




Cullen Jennings invites you to attend this online meeting.

Topic: Bundle Ports
Date: Thursday, February 21, 2013
Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 207 772 340
Meeting Password: ietf


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&am= p;PW=3DNMjYwN2JjNzYz&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: ietf
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://c= iscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&PW=3DNM= jYwN2JjNzYz&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
ht= tps://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&= ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkvkBwPvL1IZY/a2pG= U6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=3DMiM0

--_000_C5E08FE080ACFD4DAE31E4BDBF944EB1133E51C1xmbalnx02ciscoc_-- From gonzalo.camarillo@ericsson.com Fri Feb 15 08:47:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66AB21F8869 for ; Fri, 15 Feb 2013 08:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy4Ur-6QQl9C for ; Fri, 15 Feb 2013 08:47:20 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E70921F8733 for ; Fri, 15 Feb 2013 08:47:20 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-23-511e6697747a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.B3.19728.7966E115; Fri, 15 Feb 2013 17:47:19 +0100 (CET) Received: from [131.160.126.243] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 15 Feb 2013 17:47:19 +0100 Message-ID: <511E6696.6090609@ericsson.com> Date: Fri, 15 Feb 2013 18:47:18 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> In-Reply-To: <511D07F1.3070808@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje70NLlAg30v9C0uXnvIZLFm5wQW i6nLH7M4MHtM+b2R1WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBltN5aylSwlLViZc9x9gbG qSxdjJwcEgImEofu/4GyxSQu3FvP1sXIxSEkcJJRomHvZChnLaPE6d2HmUGqeAW0JT58+c4I YrMIqEq0tC0Ai7MJWEhsuXUfbJKoQJTE+6tNUPWCEidnPgGLiwiYSTycsB9sKLPAdEaJlYsO soEkhAVcJF43fYPatoVR4k7XTaYuRg4OTgEdiUdnCiHOk5RYNK0TbBCzgJ7ElKstjBC2vMT2 t3PAlgkBHbf8WQvLBEahWUh2z0LSMgtJywJG5lWM7LmJmTnp5UabGIEBfHDLb9UdjHfOiRxi lOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUWWLKPcExkb+HNbDi40OTfpV 3tM84+aj1smfH3wqSvP6fevU0p3+XjtWRb/r2NeRYVNbcEWBifvbmk8VF9I1nUyEN/ZPE776 LfzLg2eMjoed9bWmeSZd333gy5xD32YoTQo5dsZwWkD7K/dpN973/puwdr2tVPNSpy39tqLp 133PbRIpdy1lna/EUpyRaKjFXFScCAC8yrT0LgIAAA== Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:47:21 -0000 Hi, to add to what Magnus said, it is important that we understand what implementations have been doing so far (regardless of what the RFC says) and that we come up with recommendations implementers will actually follow. Keep in mind we are here to write specifications, not fiction ;-) Thanks, Gonzalo On 14/02/2013 5:51 PM, Magnus Westerlund wrote: > Thus I would be careful with speeding up Ta for RTP to much, and I think > someone needs to fine empiric data that it would work. > > For the the 500 ms that can likely be significantly lowered without any > issues. But some considerations around the wider usage needs to be taken > into account. From emil@sip-communicator.org Fri Feb 15 09:16:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A3021F884C for ; Fri, 15 Feb 2013 09:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3oX6uOcadxz for ; Fri, 15 Feb 2013 09:16:40 -0800 (PST) Received: from mail-we0-x233.google.com (we-in-x0233.1e100.net [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A871621F856E for ; Fri, 15 Feb 2013 09:16:39 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p43so1318401wea.10 for ; Fri, 15 Feb 2013 09:16:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=IfMjzpDsOIgFiWrTAV8p9XeZmJQ2MP2o0WoIoGRR4FA=; b=j6qKwCjV9ys/2f3Rw4KS+gs9V8ZFyNti9ntrAO5/OzRpqqt5H2SRJz2Rpx2DBDxIIU k8InzzX0Y5tZssWhVsIlLTyhkHM6UGJKlRcK4f3RcqxR82uBf9/+6A8QX0tkZa9ve6UK M9i/5h5teyAyejYjYN8SfliiPDQjoGlCH3MRWuIz6bD2GkZjm1RS/TlzAW9n7pdGSmBk PzXdqgUIT9soexyiI2mi5LU2Rq5KeLlYOHv7vT2ypFNK5w0dG36J6C2rSspYBOfbdk3Y Aio1ia91TZ35i0CmWEolbC3b7cw4HDD8MObxu9XxTxRU3WVmbZO3odqZqd9iHbMEDQK8 Lgug== X-Received: by 10.180.85.97 with SMTP id g1mr7484060wiz.29.1360948598756; Fri, 15 Feb 2013 09:16:38 -0800 (PST) Received: from camionet.local ([2a01:e35:8a55:abc0:c9b9:db6d:6cf3:9fb]) by mx.google.com with ESMTPS id eo10sm6514051wib.9.2013.02.15.09.16.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 09:16:37 -0800 (PST) Message-ID: <511E6D72.7070206@jitsi.org> Date: Fri, 15 Feb 2013 18:16:34 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <511E6696.6090609@ericsson.com> In-Reply-To: <511E6696.6090609@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlj4MjUWkjhAR2xO8189/unIlWhGFR0fVI6Nl0bSE6cY6DrM1Xemtdl6EiYmn8G7HvQSrqU Cc: Magnus Westerlund , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , 'mmusic' , Dan Wing Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:16:40 -0000 Well for one, we hadn't even noticed that there was different pacing for non-RTP traffic, so when we added support for Pseudo TCP to ice4j.org, we just let it use the default timers. It really didn't cross our collective minds that the same stack in the same application would have the right of going down to 20ms if it used the magic word (and RTP header) but then go back up to 500 ms if it didn't. It's almost as if it were punished for having bad non-RTP thoughts ;) Anyways, I think that, had we known about the "MUST NOT drop below 500 ms" limitation, we would have simply ignored it: these are user perceptible delays after all, and no one would like to wayt 10+ seconds for a file to start transferring. Cheers, Emil On 15.02.13, 17:47, Gonzalo Camarillo wrote: > Hi, > > to add to what Magnus said, it is important that we understand what > implementations have been doing so far (regardless of what the RFC says) > and that we come up with recommendations implementers will actually > follow. Keep in mind we are here to write specifications, not fiction ;-) > > Thanks, > > Gonzalo > > > On 14/02/2013 5:51 PM, Magnus Westerlund wrote: >> Thus I would be careful with speeding up Ta for RTP to much, and I think >> someone needs to fine empiric data that it would work. >> >> For the the 500 ms that can likely be significantly lowered without any >> issues. But some considerations around the wider usage needs to be taken >> into account. > > -- https://jitsi.org From rlb@ipv.sx Fri Feb 15 09:50:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B6F21F8803 for ; Fri, 15 Feb 2013 09:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQZSxAPrwx3I for ; Fri, 15 Feb 2013 09:50:57 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 950EC21F87D2 for ; Fri, 15 Feb 2013 09:50:56 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so3980704oag.20 for ; Fri, 15 Feb 2013 09:50:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5HXJ6ju4Aw4p3bDpX0vl8Pwg3Vfg4yGvGvT4V90ou3o=; b=JBUczckf2fCLbU8HFXpeZkYLtPN/7F5HI2NqNsHXnL8rXObLoNXuXcdd+pd1Ji52Do S6qYAFN+zUZ18YAiRPu9RNIW1QGKk3hNZXhIu9Q4zTSdAh04PfO4K1OR2OdPbiFMu+dd RkfLpZcq4PDS+wo8FgGyli5C2rQk/jAlr1eZx7NzBgKrmTd26QLpsDVnmpQwivT+CF4d vWa92an/iqbsZ81jEuTETO5F8v0/0s/E9LtpPlu9Ji3f/2MH69FJOL8zS+yqlSEFZIDc 5qSQZyCn0J8NfFylaPdEkN5+kXePlb8FLS6n6LlG983u8QXbonhaoLv5lPjgIJuYbeHz uOmA== MIME-Version: 1.0 X-Received: by 10.60.169.231 with SMTP id ah7mr2253580oec.142.1360950655872; Fri, 15 Feb 2013 09:50:55 -0800 (PST) Received: by 10.60.59.163 with HTTP; Fri, 15 Feb 2013 09:50:55 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> Date: Fri, 15 Feb 2013 12:50:55 -0500 Message-ID: From: Richard Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec54ee608666edb04d5c70428 X-Gm-Message-State: ALoCoQnJ5dIrWdiHwmH2xAueQ7PFIIUZnCOC8y5GDNMWSBLBrbTB9aaY0uCoIFA/BzkCxY2RatTD Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:50:58 -0000 --bcaec54ee608666edb04d5c70428 Content-Type: text/plain; charset=ISO-8859-1 On Friday, February 15, 2013, Christer Holmberg wrote: > Hi, > > >> I see no reason why BUNDLE couldn't be used also for non-RTP. We would > need to consider it when we study the study the SDP attribute impact, > though, but that exercise we have to do for RTP anyway. > > > > Again this is all to do with how you do the demux. > > E.g. if you bundled multiple m-lines with a UDP proto then it isn't > clear how you could demux them. > > Sure. If it is not possible to demux a protocol, then you obviously can't > do it. > > But, the scope of BUNDLE is not really to solve those kind of problems. > The scope is to define how the demuxing, when it can be done, is negotiated > on a signaling level, and what restrictions etc there are associated with > that.. > > Regards, > > Christer > > This seems right to me. The SDP just needs to allow the offeror to declare "I am going to send packets of types DUCK and GOOSE and AVOCADO over this channel." The mux part is trivial. The offerer shouldn't offer a combination he can't demux. The answerer shouldn't accept a combination he can't demux. In other words, this is a local matter, like codec support. That's not to say that demux recommendations shouldn't be written -- they should -- but the SDP does not need to account for demux algorithms. Just my $.02, --Richard > > > > > For MMT it is more tricky. As it only uses a single m= line for the > whole bundle, we would need to define a new "MMT" proto value for that m= > line (currently the draft uses RTP). Then we would need to, inside the m= > line, define a way to specify the proto value for each individual media. > > > > Regards, > > > > Christer > > ________________________________________ > > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] > on behalf of > > Dale R. Worley [worley@ariadne.com ] > > Sent: Thursday, 14 February 2013 9:53 PM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] BUNDLE: RTP only? > > > >> From: Paul Kyzivat > > >> > >> *If* there is a goal to share a single 5-tuple between RTP and SCTP > >> then we need a solution allows bundling them. > > > > Do any of the current proposed bundling techniques include both RTP > > and SCTP? > > > > Dale > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --bcaec54ee608666edb04d5c70428 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Friday, February 15, 2013, Christer Holmberg wrote:
Hi,

>> I see no reason why BUNDLE couldn't be used also for non-RTP. = We would need to consider it when we study the study the SDP attribute impa= ct, though, but that exercise we have to do for RTP anyway.
>
> Again this is all to do with how you do the demux.
> E.g. if you bundled multiple m-lines with a UDP proto then it isn'= t clear how you could demux them.

Sure. If it is not possible to demux a protocol, then you obviously can'= ;t do it.

But, the scope of BUNDLE is not really to solve those kind of problems. The= scope is to define how the demuxing, when it can be done, is negotiated on= a signaling level, and what restrictions etc there are associated with tha= t..

Regards,

Christer


This seems right to me. =A0The SDP jus= t=A0needs to allow the offeror to=A0declare "I am going to send packet= s of types DUCK and GOOSE and AVOCADO over this channel." The mux part= is trivial.=A0

The offerer shouldn't offer a combination he can= 9;t demux. The answerer shouldn't accept a combination he can't dem= ux. =A0In other words, this is a local matter, like codec support.=A0

That's not to say that demux recommendations should= n't be written -- they should -- but the SDP does not need to account f= or demux algorithms.=A0

Just my $.02,=
--Richard

=A0



> For MMT it is more tricky. As it only uses a single m=3D line for the = whole bundle, we would need to define a new "MMT" proto value for= that m=3D line (currently the draft uses RTP). Then we would need to, insi= de the m=3D line, define a way to specify the proto value for each individu= al media.
>
> Regards,
>
> Christer
> ________________________________________
> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of
> Dale R. Worley [worley@ariadne.com]
> Sent: Thursday, 14 February 2013 9:53 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] BUNDLE: RTP only?
>
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu<= /a>>
>>
>> *If* there is a goal to share a single 5-tuple between RTP and SCT= P
>> then we need a solution allows bundling them.
>
> Do any of the current proposed bundling techniques include both RTP > and SCTP?
>
> Dale
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--bcaec54ee608666edb04d5c70428-- From palmarti@cisco.com Fri Feb 15 10:43:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5398F21F861C for ; Fri, 15 Feb 2013 10:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjobrvOgVtwO for ; Fri, 15 Feb 2013 10:43:12 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4621F8610 for ; Fri, 15 Feb 2013 10:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2229; q=dns/txt; s=iport; t=1360953792; x=1362163392; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S+7YqTkw+nJJdBxDIlJ1s1yjhRy7DhjEraaA3VynLNU=; b=WblkruyY4Lxm590GBXXlXtzrv4TxrLrMJBJXGk05B1cKa0LGDhnQzZUO GZVN269NqA4BlssbP3D3l8uEvXtKcAPObFzLfHV1O1yCYUd3HE4iOdm7D Ase+4o8pAvH0fT6O9neW1jVDHIxMyh96yVk45Ag2wBNaHBXDAm6ojM97S c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN6AHlGtJV2d/2dsb2JhbABEv3F+FnOCHwEBAQMBAQEBawsFCwIBCA4KCgsZJwslAgQKBAUIiAQGDL0rBI54AjEHCoJVYQOIMIoClEuDB4In X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; d="scan'208";a="177702513" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 15 Feb 2013 18:43:11 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1FIhB5H021998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Feb 2013 18:43:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 12:43:10 -0600 From: "Pal Martinsen (palmarti)" To: Emil Ivov Thread-Topic: [MMUSIC] Updating the pacing of ICE connectivity checks Thread-Index: AQHOCrofrROk5ZwYIk+tTqAB1gS4jJh53LKAgAADjYCAAAEfAIAAA/2AgAGiAQCAAAgtAIAAGDaA Date: Fri, 15 Feb 2013 18:43:09 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB1134C1D2@xmb-rcd-x06.cisco.com> References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <511E6696.6090609@ericsson.com> <511E6D72.7070206@jitsi.org> In-Reply-To: <511E6D72.7070206@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.102] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Magnus Westerlund , =?iso-8859-1?Q?Ari_Ker=E4nen?= , Gonzalo Camarillo , "Dan Wing \(dwing\)" , mmusic Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:43:15 -0000 On Feb 15, 2013, at 18:16 PM, Emil Ivov wrote: > Well for one, we hadn't even noticed that there was different pacing for > non-RTP traffic, so when we added support for Pseudo TCP to ice4j.org, > we just let it use the default timers. It really didn't cross our > collective minds that the same stack in the same application would have > the right of going down to 20ms if it used the magic word (and RTP > header) but then go back up to 500 ms if it didn't. It's almost as if it > were punished for having bad non-RTP thoughts ;) >=20 Ha,ha. For us it was opposite. Never noticed the non-RTP stream limitation.= .. > Anyways, I think that, had we known about the "MUST NOT drop below 500 > ms" limitation, we would have simply ignored it: these are user > perceptible delays after all, and no one would like to wayt 10+ seconds > for a file to start transferring. >=20 On a side note I think simpler is better. Choosing a 20ms timer (or any val= ue) is better than calculating something from what bandwidth you are using.= It is hard to say what bandwidth a H.264 encoder is going to use, depends = on how much movement in the picture and so on. .-. P=E5l-Erik > Cheers, > Emil >=20 > On 15.02.13, 17:47, Gonzalo Camarillo wrote: >> Hi, >>=20 >> to add to what Magnus said, it is important that we understand what >> implementations have been doing so far (regardless of what the RFC says) >> and that we come up with recommendations implementers will actually >> follow. Keep in mind we are here to write specifications, not fiction ;-= ) >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >>=20 >> On 14/02/2013 5:51 PM, Magnus Westerlund wrote: >>> Thus I would be careful with speeding up Ta for RTP to much, and I thin= k >>> someone needs to fine empiric data that it would work. >>>=20 >>> For the the 500 ms that can likely be significantly lowered without any >>> issues. But some considerations around the wider usage needs to be take= n >>> into account. >>=20 >>=20 >=20 > --=20 > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri Feb 15 10:52:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9797F21F8883 for ; Fri, 15 Feb 2013 10:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOUSEU8OpC7t for ; Fri, 15 Feb 2013 10:52:53 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id CF6EA21F8849 for ; Fri, 15 Feb 2013 10:52:52 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0bhz1l0020SCNGk51issDL; Fri, 15 Feb 2013 18:52:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:dde8:a1b7:24cc:c25d]) by omta09.westchester.pa.mail.comcast.net with comcast id 0isq1l00L1BKwcM3VisqAp; Fri, 15 Feb 2013 18:52:52 +0000 Message-ID: <511E8401.7010907@alum.mit.edu> Date: Fri, 15 Feb 2013 13:52:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360954372; bh=G1Q3XyeB3m8vCTDzZ4qdKtLfr0iGAK3b7HbKMe6atu4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J3c8L52M+fnLQItDjc30Fpc6p34pOPbd4o9DDcKRDUrj5TE2iVlDhM06zeKJw/VC0 3WadGJ1DowZeTVUH/ECucZdW1tjO989TRrrnYBHWI9yBCtkIoPpGzHBWL3GhNF7ZBC sLS4xsG1PmmStD1JrA0UFHS9ELOQyCtBjCp2ZNea/en1v0+CALusCZ/u1gRj1KXnB7 sME6kkOKu2StjzJEcJQ9ZtPzDsAQ8pFgu2N3gslUZnHZfYemGPNkWdnJSB+Pl7yfHH JLWEnwNKSaQnqJPB1ZAipkANCqpvHc+KiA5+ytBfaCXFRmr6zz3dPVjod4knh2XDzv mG4gEfks9qsRw== Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:52:53 -0000 On 2/15/13 12:50 PM, Richard Barnes wrote: > On Friday, February 15, 2013, Christer Holmberg wrote: > > Hi, > > >> I see no reason why BUNDLE couldn't be used also for non-RTP. We > would need to consider it when we study the study the SDP attribute > impact, though, but that exercise we have to do for RTP anyway. > > > > Again this is all to do with how you do the demux. > > E.g. if you bundled multiple m-lines with a UDP proto then it > isn't clear how you could demux them. > > Sure. If it is not possible to demux a protocol, then you obviously > can't do it. > > But, the scope of BUNDLE is not really to solve those kind of > problems. The scope is to define how the demuxing, when it can be > done, is negotiated on a signaling level, and what restrictions etc > there are associated with that.. > > Regards, > > Christer > > > This seems right to me. The SDP just needs to allow the offeror > to declare "I am going to send packets of types DUCK and GOOSE and > AVOCADO over this channel." The mux part is trivial. > > The offerer shouldn't offer a combination he can't demux. The answerer > shouldn't accept a combination he can't demux. In other words, this is > a local matter, like codec support. This doesn't work unless the offerer and the answerer *agree* on the mux/demux algorithm. E.g. It would be bad if the offerer uses a unique payload type for each "flow"/track and switches among SSRCs within it, while the answerer demuxes into flows/tracks based on SSRC. > That's not to say that demux recommendations shouldn't be written -- > they should -- but the SDP does not need to account for demux algorithms. You used an analogy to codec support. SDP doesn't define particular codecs, but it does provide the mechanism for the offerer and answerer to agree on which codecs will be used. The same would be true here *if* the SDP allowed the mux/demux algorithm to be declared or negotiated. Thanks, Paul > Just my $.02, > --Richard > > > > > > For MMT it is more tricky. As it only uses a single m= line for > the whole bundle, we would need to define a new "MMT" proto value > for that m= line (currently the draft uses RTP). Then we would need > to, inside the m= line, define a way to specify the proto value for > each individual media. > > > > Regards, > > > > Christer > > ________________________________________ > > From: mmusic-bounces@ietf.org > [mmusic-bounces@ietf.org ] on behalf of > > Dale R. Worley [worley@ariadne.com ] > > Sent: Thursday, 14 February 2013 9:53 PM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] BUNDLE: RTP only? > > > >> From: Paul Kyzivat > > >> > >> *If* there is a goal to share a single 5-tuple between RTP and SCTP > >> then we need a solution allows bundling them. > > > > Do any of the current proposed bundling techniques include both RTP > > and SCTP? > > > > Dale > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From dwing@cisco.com Fri Feb 15 10:57:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F124621F88D1 for ; Fri, 15 Feb 2013 10:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqYHxywpSXd1 for ; Fri, 15 Feb 2013 10:57:41 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2721F8883 for ; Fri, 15 Feb 2013 10:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2431; q=dns/txt; s=iport; t=1360954661; x=1362164261; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=pfQmeyJvr+RVfCdmbD7CzyP2lIC/WLwmBLwtCnrqer0=; b=Jlmv/o0C+8Wt0L+7wANTXJsTsUihNLlftR8BOc9D5fXZmwFQHihQkd2V qBgXPlrV+Kt+AtsC+gOV2dpx11YXqY15ZAf4us//sr9MiEC+DF4zv/xio gK9Ni2udPTmvlVsGocHAEsmCtqMu6dm2BTcYcBEFDx91qUnju1utBvyDj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF+EHlGrRDoI/2dsb2JhbABEv3J9FnOCHwEBAQMBCAJvBQcBAwIJDgMEAQEBFRIHGS0JCAIEAQkJCwWHfAW9OgSNVIFMCwcGBIM2A4gwNoUjhCmDdpBVgyg X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; d="scan'208";a="69771973" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Feb 2013 18:57:40 +0000 Received: from DWINGWS01 (sjc-vpn7-1289.cisco.com [10.21.149.9]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1FIvbnu012175; Fri, 15 Feb 2013 18:57:40 GMT From: "Dan Wing" To: "'Emil Ivov'" , "'Gonzalo Camarillo'" References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <511E6696.6090609@ericsson.com> <511E6D72.7070206@jitsi.org> In-Reply-To: <511E6D72.7070206@jitsi.org> Date: Fri, 15 Feb 2013 10:57:36 -0800 Message-ID: <0a3c01ce0bae$540df920$fc29eb60$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEzjPbQxUzVAxWufG5eY2LeHo6PAE3VhFkAl3CtsIB+REApAJspBJ/Ahsgqy4BfH3ULpgxFLEA Content-Language: en-us Cc: 'Magnus Westerlund' , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'mmusic' Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:57:43 -0000 > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Friday, February 15, 2013 9:17 AM > To: Gonzalo Camarillo > Cc: Magnus Westerlund; Ari Ker=E4nen; 'mmusic'; Dan Wing > Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks >=20 > Well for one, we hadn't even noticed that there was different pacing = for > non-RTP traffic, so when we added support for Pseudo TCP to ice4j.org, > we just let it use the default timers. It really didn't cross our > collective minds that the same stack in the same application would = have > the right of going down to 20ms if it used the magic word (and RTP > header) but then go back up to 500 ms if it didn't. It's almost as if = it > were punished for having bad non-RTP thoughts ;) >=20 > Anyways, I think that, had we known about the "MUST NOT drop below 500 > ms" limitation, we would have simply ignored it: these are user > perceptible delays after all, and no one would like to wayt 10+ = seconds > for a file to start transferring. A quick a analysis of what browsers have been doing in this area: The=20 TCP retransmit timer on most OSs is 3 seconds. But Firefox and Chrome=20 have backup connection timers that are more aggressive (250ms and 300ms, if I recall correctly). IE does not have a backup connection timer. So they are not as aggressive as 20ms (which would be too aggressive on a = lot of networks) but they also do not strictly follow the IETF TCP transport guidelines to retry a TCP connection after a long 3 seconds. -d > Cheers, > Emil >=20 > On 15.02.13, 17:47, Gonzalo Camarillo wrote: > > Hi, > > > > to add to what Magnus said, it is important that we understand what > > implementations have been doing so far (regardless of what the RFC > > says) and that we come up with recommendations implementers will > > actually follow. Keep in mind we are here to write specifications, = not > > fiction ;-) > > > > Thanks, > > > > Gonzalo > > > > > > On 14/02/2013 5:51 PM, Magnus Westerlund wrote: > >> Thus I would be careful with speeding up Ta for RTP to much, and I > >> think someone needs to fine empiric data that it would work. > >> > >> For the the 500 ms that can likely be significantly lowered without > >> any issues. But some considerations around the wider usage needs to > >> be taken into account. > > > > >=20 > -- > https://jitsi.org From martin.thomson@gmail.com Fri Feb 15 11:41:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12D21F86A6 for ; Fri, 15 Feb 2013 11:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.774 X-Spam-Level: X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2+rpBj7CL6g for ; Fri, 15 Feb 2013 11:41:35 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5561121F86A5 for ; Fri, 15 Feb 2013 11:41:35 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so1579340wid.11 for ; Fri, 15 Feb 2013 11:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qv0tu6AAVmHB/X4xgxms9EFUXtpcqSVOyt5MOxzg2UQ=; b=sHgn8uebG5+Ct1OR8ou6yc2o0IdDIGnb9FDCweOdOZVghZ+gPxHgCpm6FQ4OXr1NYR nWrdzOzVjYTYq05hB0ODtrY3PaqLD6j0qubShwI+Sq8nVqTd+fHZ6xuUfH/vMTVjRbai 9NaiF1nWLGuoJKB/Di0TpvTSZ2HcVyvdkvv4y/12t9MMfpuHQIIsfVWE7jmJK4obLEP1 6OY/M7tbo7d9mewXVHxzm7Hj1gmKGvh8NhQ+rG3wnmXoomG6cRq3fOTIXU4+b31vPHym YaWJbawvBLwbRrBNcLqPJctu4rX89fR8P43gk7vqLNv1YhWbMjf4AtdbstOLHxb7SV2G T2yA== MIME-Version: 1.0 X-Received: by 10.180.80.35 with SMTP id o3mr8331191wix.9.1360957294354; Fri, 15 Feb 2013 11:41:34 -0800 (PST) Received: by 10.194.5.135 with HTTP; Fri, 15 Feb 2013 11:41:34 -0800 (PST) In-Reply-To: <0a3c01ce0bae$540df920$fc29eb60$@cisco.com> References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com> <511E6696.6090609@ericsson.com> <511E6D72.7070206@jitsi.org> <0a3c01ce0bae$540df920$fc29eb60$@cisco.com> Date: Fri, 15 Feb 2013 11:41:34 -0800 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: Magnus Westerlund , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Gonzalo Camarillo , mmusic Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:41:36 -0000 On 15 February 2013 10:57, Dan Wing wrote: > A quick a analysis of what browsers have been doing in this area: The > TCP retransmit timer on most OSs is 3 seconds. But Firefox and Chrome > have backup connection timers that are more aggressive (250ms and 300ms, > if I recall correctly). IE does not have a backup connection timer. So > they are not as aggressive as 20ms (which would be too aggressive on a lot > of networks) but they also do not strictly follow the IETF TCP transport > guidelines to retry a TCP connection after a long 3 seconds. That's good info. I could only find that for Firefox easily. Given that they also ignore the limit Dale pointed out and create 6 connections to any given server, this leads to an aggregate rate of SYN packets of one every 50ms, though it's probably more bursty than the even pacing required by RFC 5245. From adam@nostrum.com Fri Feb 15 13:10:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE621F861C for ; Fri, 15 Feb 2013 13:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxHBk8Poy0WS for ; Fri, 15 Feb 2013 13:10:58 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A221F861A for ; Fri, 15 Feb 2013 13:10:58 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1FLAuBu058508 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 15:10:57 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <511EA460.2040701@nostrum.com> Date: Fri, 15 Feb 2013 15:10:56 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070702040402030806020106" Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:10:59 -0000 This is a multi-part message in MIME format. --------------070702040402030806020106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit During SIPit? /a On 2/15/13 10:36, Cullen Jennings (fluffy) wrote: > > Hi All, > > As discussed at the interim, Richard and I are planning to have a call > to discuss issues around the same port or different ports in bundle. > This is not an official WG call or anything but anyone is welcome to > join us on the call. Bridge info below. > > Cullen > > > >> >> Cullen Jennings invites you to attend this online meeting. >> >> Topic: Bundle Ports >> Date: Thursday, February 21, 2013 >> Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) >> Meeting Number: 207 772 340 >> Meeting Password: ietf >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&RT=MiM0 >> >> 2. Enter your name and email address. >> 3. Enter the meeting password: ietf >> 4. Click "Join Now". >> >> To view in other time zones or languages, please click the link: >> https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&ORT=MiM0 >> >> >> ---------------------------------------------------------------- >> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes >> ---------------------------------------------------------------- >> >> The affected toll free numbers are: (866) 432-9903 for the San >> Jose/Milpitas area and (866) 349-3520 for the RTP area. >> >> Please dial the local access number for your area from the list below: >> - San Jose/Milpitas (408) area: 525-6800 >> - RTP (919) area: 392-3330 >> >> ------------------------------------------------------- >> To join the teleconference only >> ------------------------------------------------------- >> 1. Dial into Cisco WebEx (view all Global Access Numbers at >> http://cisco.com/en/US/about/doing_business/conferencing/index.html >> 2. Follow the prompts to enter the Meeting Number (listed above) or >> Access Code followed by the # sign. >> >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >> >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >> >> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >> >> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >> >> ------------------------------------------------------- >> >> >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 >> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------070702040402030806020106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
During SIPit?

/a

On 2/15/13 10:36, Cullen Jennings (fluffy) wrote:

Hi All,

As discussed at the interim, Richard and I are planning to have a call to discuss issues around the same port or different ports in bundle. This is not an official WG call or anything but anyone is welcome to join us on the call. Bridge info below. 

Cullen




Cullen Jennings invites you to attend this online meeting.

Topic: Bundle Ports
Date: Thursday, February 21, 2013
Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 207 772 340
Meeting Password: ietf


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&RT=MiM0
2. Enter your name and email address.
3. Enter the meeting password: ietf
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&ORT=MiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

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


To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 



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

--------------070702040402030806020106-- From worley@shell01.TheWorld.com Fri Feb 15 13:28:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CDD21F8634 for ; Fri, 15 Feb 2013 13:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwmcLX0NJ8iI for ; Fri, 15 Feb 2013 13:28:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 25E0321F86AD for ; Fri, 15 Feb 2013 13:28:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FLRoRf025146 for ; Fri, 15 Feb 2013 16:27:52 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FLRoeD1896037 for ; Fri, 15 Feb 2013 16:27:50 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FLRnNd1899111; Fri, 15 Feb 2013 16:27:49 -0500 (EST) Date: Fri, 15 Feb 2013 16:27:49 -0500 (EST) Message-Id: <201302152127.r1FLRnNd1899111@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Some comments on draft-ietf-mmusic-sctp-sdp-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:28:02 -0000 * section 4.3 The following example is given: m=application 54111 DTLS/SCTP 5000 5001 5002 c=IN IP4 79.97.215.79 a=sctpmap:5000 webrtc-DataChannel 2 a=sctpmap:5001 bfcp 1 a=sctpmap:5002 t38 1 a=webrtc-DataChannel:5000 stream=1;label="channel 1";subprotocol="chat"; a=webrtc-DataChannel:5000 stream=2;label="channel 2";subprotocol="file transfer";max_retr=3 This example is missing the a=fingerprint attribute, which is mandatory according to section 3. This specifies that SCTP-over-DTLS-over-DCCP will be used, with the near-end DCCP port being 54111. However, the numbers "5000", "5001", and "5002" seem to have no function, in that they appear nowhere on the wire. At least one "format" number is syntactically required in the m= line, but there seems to be no reason to provide multiple format numbers. A more natural organization of the attributes for DTLS/SCTP use seems to be this, which identifies the component media by their SCTP stream identifiers (which is how they will be demultiplexed): m=application 54111 DTLS/SCTP 0 c=IN IP4 79.97.215.79 a=sctpmap:webrtc-DataChannel 2 a=sctpmap:bfcp 1 a=sctpmap:t38 1 a=webrtc-DataChannel:5000 stream=1;label="channel 1";subprotocol="chat"; a=webrtc-DataChannel:5000 stream=2;label="channel 2";subprotocol="file transfer";max_retr=3 Or perhaps use the SCTP stream identifiers could be used as the primary identifiers in the a=webrtc-DataChannel attributes: a=webrtc-DataChannel:1;label="channel 1";subprotocol="chat"; a=webrtc-DataChannel:2;label="channel 2";subprotocol="file transfer";max_retr=3 It's also not clear why the BFCP and T.38 media are assigned the same SCCP stream identifier (i.e., 1). That seems to be a mistake. * section 5 There are a number of attributes with the generic format "a==". I believe this should be "a=:". stream-attr = "a=stream=" streamnumber label-attr = "a=label=" labelstring subprotocol-attr = "a=subprotocol=" labelstring maxretr-attr = "a=maxretr=" maxretrvalue maxtime-attr = "a=maxtime=" maxtimevalue * section 5.3 This section defines an apparently new "a=label" attribute: label-attr = "a=label=" labelstring labelstring = text text = byte-string But the label syntax is incompatible with the existing label attribute: RFC 4574 section 4 label-attribute = "a=label:" pointer pointer = token token = 1*(token-char) token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E And it's not clear why this "new" attribute is defined at all, since there is a label carried in the a=webrtc-DataChannel attribute already. Dale From worley@shell01.TheWorld.com Fri Feb 15 14:24:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0C521E8045 for ; Fri, 15 Feb 2013 14:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMgnKM5HQ7+V for ; Fri, 15 Feb 2013 14:24:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6E21E803C for ; Fri, 15 Feb 2013 14:24:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FMNDgJ011192 for ; Fri, 15 Feb 2013 17:23:15 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FMNCrh1910359 for ; Fri, 15 Feb 2013 17:23:12 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FMNCsk1909115; Fri, 15 Feb 2013 17:23:12 -0500 (EST) Date: Fri, 15 Feb 2013 17:23:12 -0500 (EST) Message-Id: <201302152223.r1FMNCsk1909115@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <511C9F44.3010806@alvestrand.no> (harald@alvestrand.no) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se>, <511BF229.1090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D81BD@ESESSMB209.ericsson.se> <511C56CB.1080609@alum.mit.edu> <511C9F44.3010806@alvestrand.no> Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:24:03 -0000 > From: Harald Alvestrand > > RTCWEB has a requirement (or rather: it has assumed that there was a > solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the > same port pair as SRTP. More exactly, RTCWEB has an assumption that there is a strategy for sending SCTP/DTLS/UDP over the same port as SRTP, and that we will figure out how to signal it. (It appears that sending RTP and RTCP (or SRTP and SRTP) over the same port is already solved.) The question is whether this is a *requirement*, and if so, to put it in the requirements document -- I don't see it in draft-ietf-rtcweb-use-cases-and-requirements-10. However what I do see in that draft is: F29 The browser MUST be able to send streams and data to a peer in the presence of NATs that block UDP traffic. and we seem to be assuming that the carrier protocol for multiplexing is UDP... Dale From worley@shell01.TheWorld.com Fri Feb 15 14:24:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4B521E803C for ; Fri, 15 Feb 2013 14:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4rvefhFD52S for ; Fri, 15 Feb 2013 14:24:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 022E121E8043 for ; Fri, 15 Feb 2013 14:24:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FMMYE0022190 for ; Fri, 15 Feb 2013 17:22:36 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FMMUo71896957 for ; Fri, 15 Feb 2013 17:22:30 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FMMUpo1903639; Fri, 15 Feb 2013 17:22:30 -0500 (EST) Date: Fri, 15 Feb 2013 17:22:30 -0500 (EST) Message-Id: <201302152222.r1FMMUpo1903639@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <511E8401.7010907@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> <511E8401.7010907@alum.mit.edu> Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:24:08 -0000 The problem is divisible into two parts. One part is just clarifying what needs to be supported. The second, harder part is specifying all the mechanisms. When multiplexing, we have to establish: 1. What is the nature of the constituent data streams that can be multiplexed? 2. What method is used to multiplex the constituents? Does there need to be an encapsulation protocol? 3. What method is used to demultiplex the incoming PDUs of the multiplexed data? 4. What carrier protocol is used to carry the multiplexed data? 5. How will we signal whatever information is needed to control the demultiplexing process? (This is affected by any need to interoperate with existing systems.) 6. Where in the stack of protocols do we apply encryption, and what is its nature? Items 1 and 3 are the ones that are most constrained by the requirements of the situation. As far as I can tell from what I've seen, the nature of the constituent data streams is: - the RTP or SRTP traffic arising from zero or more SDP media descriptions (Here we assume that it is important when demultiplexing RTP that it is important to identify the correct constituent media description for each incoming RTP packet; that RTP cannot be interpreted except in the context of the correct media description.) - the corresponding RTCP or Secure RTCP traffic (assuming we want to have RTP/RTCP multiplexing) - the data carried over a single SCTP connection (which includes a number of SCTP streams), or possibly more than one SCTP connection if that is to be supported (It is not clear if the multiplexing process has access to the data in the individual SCTP streams, or whether the constituent data stream is the packets generated by SCTP's multiplexing process, or whether it must handle the packets generated by DTLS encrypting the SCTP packets.) The carrier protocol seems to be assumed to be UDP supplemented by the STUN and ICE traffic needed to support a UDP association with the far-end. However there may be value in using SCTP-over-DTLS-over-UDP as the carrier protocol. In regard to encryption, it would be more efficient to apply encryption only to the multiplexed data. That suggests that the constituent data is unencrypted: RTP instead of SRTP, SCTP instead of DTLS/SCTP. There tends to be an assumption that the demultiplexing process is trivial, that all incoming PDUs can be identified and routed to their correct destinations without any additional encapsulation information. We might be lucky enough that that is true, but it is not the common case. Dale From ron.even.tlv@gmail.com Fri Feb 15 22:45:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B415B21F85AB for ; Fri, 15 Feb 2013 22:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhfU0ZH3bfkq for ; Fri, 15 Feb 2013 22:45:05 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id F32A321F8644 for ; Fri, 15 Feb 2013 22:45:04 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so1692388eaa.7 for ; Fri, 15 Feb 2013 22:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:content-language:thread-index; bh=5FaXAbEA+su+V4CMpTBu7kIOHQAfW/XkpGwHrmmGNzc=; b=agcuBifecN2jwkJyRmiCe4ElrA75r4XuRaKLPTuAtfc/GQSZUAoISN/Liv+ORjEd8W yeTYnmrRtM3BQujEom5EmorgMOAuOVpbOvRRAmommk1qBXWvbWFKDyprP0PRiBJBn2QO B2hnY/nIE23mYKrAJAQ1KVWmveBM5njscNgQM318ZFTEsAsKgYLLmSGfomcZFoB/OE2u 9aIV/o0f+nvZJXVHZ5FNFzZiU5LsZ3BEKfL3/Rn0a6MwY77ngMpKA63adaDHZfhS1/oX sDZb5o/jJP3w/D7WrFX8cJRgHvnbnXRWsXhV6kVKSsvt3TwvB2MGDEtLNzoz/1U7ramH jhOQ== X-Received: by 10.14.209.131 with SMTP id s3mr17331735eeo.26.1360997104149; Fri, 15 Feb 2013 22:45:04 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id u44sm27081146eel.7.2013.02.15.22.45.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Feb 2013 22:45:03 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'Adam Roach'" References: <5111247B.8060904@nostrum.com> <511CEDFF.7060001@ericsson.com> In-Reply-To: <511CEDFF.7060001@ericsson.com> Date: Sat, 16 Feb 2013 08:41:54 +0200 Message-ID: <019f01ce0c10$b7c69d20$2753d760$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: AQJvIytZRgs1P9YZREJhle3noIrn/AFm7fQ4AwbnxDCXFmv/EA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 06:45:18 -0000 Hi, I fully agree with Magnus cases and I think they should be addressed.=20 At CLUE when working on RTP mapping we addressed this used cases by = having multiple RTP streams in a single m-line Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: 14 February, 2013 4:01 PM To: Adam Roach Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a = single m=3D line On 2013-02-05 16:25, Adam Roach wrote: > On 2/4/13 02:45, Justin Uberti wrote: >> Sorry for the short lead time, but here's a quick read for the plane. >=20 > I addressed several of the assertions made in this draft in my=20 > previous response (e.g. the need for glare resolution regardless of=20 > which solution we select). Some additional thoughts: >=20 >> o Adding or removing a source requires sending a full list of all >> sources, which doesn't scale well to 10s or 100s of sources, >> especially when they are added or removed frequently. >=20 > Realistically, this isn't how multiparty conferences are handled. It's = > unrealistic to think that my DSL connection is going to be sucking=20 > down hundreds of video streams just because I'm in a video conference=20 > with hundreds of people. >=20 > In practice, the way existing conferencing systems handle this is to=20 > send a small, manageable number of streams to each participant,=20 > changing them out as necessary to have a reasonable user experience=20 > (either under the control of the user, its own algorithms, or a combination of the two). >=20 > Which is to say: even with hundreds of source streams being fed into a = > conference system, you're really looking at a realistic upper bound on = > m=3D sections of a dozen or two, simply because you can't reasonably=20 > expect recipients to receive more than that many streams = simultaneously. >=20 Hi, I definitely want to comment on this from an RTP usage perspective that might be very relevant to remember. Even with a centralized conference solution there is two very distinct solutions in RTP how to transmit a session where you have total of 100 participants and you receive 5 video streams. A) Central point with conceptual sources In this case the central entity creates conceptual RTP streams that carries all the media intended for a specific usage, for example main video, thumbnail one, thumbnail two, thumbnail three, thumbnail four. B) Central point doing source projection In this case there exist 100 potential RTP streams and SSRC from the central point down to the = receiver. However, at any point no more than five will actually have RTP packets. = But as activity changes and which is most relevant for the receiver the = SSRCs in use will switch. For a solution where each SSRC requires its own m=3D line A) is = definitely preferable as it will not require renegotiating the properties for these five conceptual streams. However, B will require a large number of m=3D = lines and dynamic updates as participants comes and go. IF one had a single m=3D line per RTP session and media type, the amount = of updates/renegotiation depends on the amount of meta data about streams = that you have put in the SDP. They solutions A) and B) can be identical from = an SDP perspective. The above two cases I am quite certain we did discuss in the CLUE = interim meeting in Stockholm when discussing topologies and also the relation = ship between RTP streams (SSRC) and their origin, i.e. media source/capture. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Sat Feb 16 04:07:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B821F877B for ; Sat, 16 Feb 2013 04:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.991 X-Spam-Level: X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ePLhz-zFw7 for ; Sat, 16 Feb 2013 04:07:03 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63521F86AC for ; Sat, 16 Feb 2013 04:06:55 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so1794802eaa.5 for ; Sat, 16 Feb 2013 04:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; bh=0x1UQX05vSMZ4MJALpJ3X24rt+twm6fHkuqroV+bJRM=; b=q6nL20k/2QtCxdH5fsZPmRIN+maDbtkbhjjwfT20M5av0zXyHwepxJxeLXam0XbtRB 4H/cmMTdM3Ktd00WKtmo555JrGTb6EJ9y+AnlMHmD/zQAWkUP3TZWJACACsPFAV9U2Sf InvXRVxuikFxhqCvN6NbFeBpJyoVnSRvaSLwBB6/i+ASI140un2D80+qbeRju+iUV8ON gXi52nrxJ4CEFQdEsjrKRkYWIYLUf+ucPm4OEN+k6/1ebubC9mHalrcaKQaXw1SpL4JD q/8VKc5sH89K3SAs/LEet6aAmW91GOc/Sq1nU+tA4Wrh577U0obbBO/2Cfe0+8uoiNA7 BgTQ== X-Received: by 10.14.183.67 with SMTP id p43mr20029165eem.10.1361016414351; Sat, 16 Feb 2013 04:06:54 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id s3sm17696629eem.4.2013.02.16.04.06.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Feb 2013 04:06:53 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'Adam Roach'" Date: Sat, 16 Feb 2013 14:03:43 +0200 Message-ID: <01bf01ce0c3d$ad50dfe0$07f29fa0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: Ac4MPaK6CwZOjU23SbmPx2LyzVOoUg== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line - requirements for "fumble"!!! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:07:04 -0000 Hi, The second topology brings the following requirement that I assume also relate to what is called "fumble" "it should be possible to support receipt of multiple RTP sources = without explicit per-source signaling or negotiation." Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: 14 February, 2013 4:01 PM To: Adam Roach Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a = single m=3D line On 2013-02-05 16:25, Adam Roach wrote: > On 2/4/13 02:45, Justin Uberti wrote: >> Sorry for the short lead time, but here's a quick read for the plane. >=20 > I addressed several of the assertions made in this draft in my=20 > previous response (e.g. the need for glare resolution regardless of=20 > which solution we select). Some additional thoughts: >=20 >> o Adding or removing a source requires sending a full list of all >> sources, which doesn't scale well to 10s or 100s of sources, >> especially when they are added or removed frequently. >=20 > Realistically, this isn't how multiparty conferences are handled. It's = > unrealistic to think that my DSL connection is going to be sucking=20 > down hundreds of video streams just because I'm in a video conference=20 > with hundreds of people. >=20 > In practice, the way existing conferencing systems handle this is to=20 > send a small, manageable number of streams to each participant,=20 > changing them out as necessary to have a reasonable user experience=20 > (either under the control of the user, its own algorithms, or a combination of the two). >=20 > Which is to say: even with hundreds of source streams being fed into a = > conference system, you're really looking at a realistic upper bound on = > m=3D sections of a dozen or two, simply because you can't reasonably=20 > expect recipients to receive more than that many streams = simultaneously. >=20 Hi, I definitely want to comment on this from an RTP usage perspective that might be very relevant to remember. Even with a centralized conference solution there is two very distinct solutions in RTP how to transmit a session where you have total of 100 participants and you receive 5 video streams. A) Central point with conceptual sources In this case the central entity creates conceptual RTP streams that carries all the media intended for a specific usage, for example main video, thumbnail one, thumbnail two, thumbnail three, thumbnail four. B) Central point doing source projection In this case there exist 100 potential RTP streams and SSRC from the central point down to the = receiver. However, at any point no more than five will actually have RTP packets. = But as activity changes and which is most relevant for the receiver the = SSRCs in use will switch. For a solution where each SSRC requires its own m=3D line A) is = definitely preferable as it will not require renegotiating the properties for these five conceptual streams. However, B will require a large number of m=3D = lines and dynamic updates as participants comes and go. IF one had a single m=3D line per RTP session and media type, the amount = of updates/renegotiation depends on the amount of meta data about streams = that you have put in the SDP. They solutions A) and B) can be identical from = an SDP perspective. The above two cases I am quite certain we did discuss in the CLUE = interim meeting in Stockholm when discussing topologies and also the relation = ship between RTP streams (SSRC) and their origin, i.e. media source/capture. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mary.ietf.barnes@gmail.com Sat Feb 16 12:06:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61CB21F8857 for ; Sat, 16 Feb 2013 12:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0W2rNhbwhyd for ; Sat, 16 Feb 2013 12:06:14 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6621F86AB for ; Sat, 16 Feb 2013 12:06:13 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id a11so1948484qen.31 for ; Sat, 16 Feb 2013 12:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=znnIE40rp9G3NwtBKAxNx3n7Nyq1bGMwrjBRskkqCsE=; b=z7RVAe2b6TSQc4FcsN7sbuzxKp/RpdWGAd5hSlCRQrlCi9h9yX5+0nauGCXgLf4XjQ uee1cCNgvAwcnWUXIs5MzF9P4nkkDQ+/cA08Ew4tissZbsrO6Y9PBh9XvI1htm2Kkr4C 7aIWrT6Orf8BLpXjAeQwSADk7ZK+ZNcYlLfWt+ZQakB5r50i9DnzHrIjJJUVxzQNYeaK k7+sxOHuqEaxuF5g2HbwzdnhjXze/QkacEGPUs2h2pyATUcUTi0mZWmEDW1P3lNdjaPK WoMBOuV+CLikbqVjxhL6cAW+v8+ffUwXqqzMmNUOZf3aYmcZ8xM9Xj2AKazujAS6NXlI L22w== MIME-Version: 1.0 X-Received: by 10.229.37.231 with SMTP id y39mr579396qcd.14.1361045173245; Sat, 16 Feb 2013 12:06:13 -0800 (PST) Received: by 10.49.131.199 with HTTP; Sat, 16 Feb 2013 12:06:13 -0800 (PST) In-Reply-To: References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> Date: Sat, 16 Feb 2013 14:06:13 -0600 Message-ID: From: Mary Barnes To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 20:06:15 -0000 At this point, it's going to be difficult for several of the CLUE WG participants to attend at this point. A doodle would be nice to ensure you have a reasonable representation from the groups involved. Thanks, Mary. On Fri, Feb 15, 2013 at 10:36 AM, Cullen Jennings (fluffy) wrote: > > Hi All, > > As discussed at the interim, Richard and I are planning to have a call to > discuss issues around the same port or different ports in bundle. This is > not an official WG call or anything but anyone is welcome to join us on the > call. Bridge info below. > > Cullen > > > > > Cullen Jennings invites you to attend this online meeting. > > Topic: Bundle Ports > Date: Thursday, February 21, 2013 > Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 207 772 340 > Meeting Password: ietf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&RT=MiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: ietf > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&ORT=MiM0 > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas > area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or Access > Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Sat Feb 16 12:53:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F09A21F8899 for ; Sat, 16 Feb 2013 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.769 X-Spam-Level: X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCIzfVE+a4Wq for ; Sat, 16 Feb 2013 12:53:19 -0800 (PST) Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by ietfa.amsl.com (Postfix) with ESMTP id 908AA21F8658 for ; Sat, 16 Feb 2013 12:53:19 -0800 (PST) Received: from BLU002-W11 ([65.55.116.74]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Feb 2013 12:53:19 -0800 X-EIP: [R3TIoO3v3PBSDzxoYK2lBMgebKN6I4Qs] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fcff5571-3b4e-4ade-b6c5-34281a6cd7a2_" From: Bernard Aboba To: Magnus Westerlund Date: Sat, 16 Feb 2013 12:53:18 -0800 Importance: Normal In-Reply-To: <511CEDFF.7060001@ericsson.com> References: , <5111247B.8060904@nostrum.com>, <511CEDFF.7060001@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2013 20:53:19.0334 (UTC) FILETIME=[A6784060:01CE0C87] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 20:53:20 -0000 --_fcff5571-3b4e-4ade-b6c5-34281a6cd7a2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below.=20 > I definitely want to comment on this from an RTP usage perspective that > might be very relevant to remember. Even with a centralized conference > solution there is two very distinct solutions in RTP how to transmit a > session where you have total of 100 participants and you receive 5 video > streams. >=20 > A) Central point with conceptual sources > In this case the central entity creates conceptual RTP streams that > carries all the media intended for a specific usage=2C for example main > video=2C thumbnail one=2C thumbnail two=2C thumbnail three=2C thumbnail f= our. >=20 > B) Central point doing source projection > In this case there exist 100 potential RTP streams and SSRC from the > central point down to the receiver. However=2C at any point no more than > five will actually have RTP packets. But as activity changes and which > is most relevant for the receiver the SSRCs in use will switch. >=20 > For a solution where each SSRC requires its own m=3D line A) is definitel= y > preferable as it will not require renegotiating the properties for these > five conceptual streams. However=2C B will require a large number of m=3D > lines and dynamic updates as participants comes and go. [BA] I think there are advantages to A even if multiple SSRCs are declared = within a m-line. If the "main" video and "thumbnails" change SSRCs=2C even= with multiple SSRCs on an m-line=2C you'd still need to renegotiate unless= SVC is being used=2C right?=20 =20 > If one had a single m=3D line per RTP session and media type=2C the amoun= t > of updates/renegotiation depends on the amount of meta data about > streams that you have put in the SDP. The solutions A) and B) can be > identical from an SDP perspective. [BA] That's not obvious to me. Even if you have a single m=3Dline per RTP s= ession and media type=2C=20 you can still have individual a=3Dssrc lines within a m=3D line. In case B= =2C as participants come and go=2C aren't dynamic updates still required? Also=2C instead of many m=3Dlines= =2C you'll have many a=3Dssrc lines.=20 > The above two cases I am quite certain we did discuss in the CLUE > interim meeting in Stockholm when discussing topologies and also the > relationship between RTP streams (SSRC) and their origin=2C i.e. media > source/capture. [BA] Were there any specific requirements that arose in the CLUE discussion= ? In general=2C given some of the context issues=2C it would be helpful to= understand whether we're engineering a solution for RTCWEB use cases=2C CL= UE use cases=2C or both.=20 = --_fcff5571-3b4e-4ade-b6c5-34281a6cd7a2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Comments below.

>= =3B I definitely want to comment on this from an RTP usage perspective that=
>=3B might be very relevant to remember. Even with a centralized conf= erence
>=3B solution there is two very distinct solutions in RTP how t= o transmit a
>=3B session where you have total of 100 participants and= you receive 5 video
>=3B streams.
>=3B
>=3B A) Central poi= nt with conceptual sources
>=3B In this case the central entity create= s conceptual RTP streams that
>=3B carries all the media intended for = a specific usage=2C for example main
>=3B video=2C thumbnail one=2C th= umbnail two=2C thumbnail three=2C thumbnail four.
>=3B
>=3B B) C= entral point doing source projection
>=3B In this case there exist 100= potential RTP streams and SSRC from the
>=3B central point down to th= e receiver. However=2C at any point no more than
>=3B five will actual= ly have RTP packets. But as activity changes and which
>=3B is most re= levant for the receiver the SSRCs in use will switch.
>=3B
>=3B = For a solution where each SSRC requires its own m=3D line A) is definitely<= br>>=3B preferable as it will not require renegotiating the properties fo= r these
>=3B five conceptual streams. However=2C B will require a larg= e number of m=3D
>=3B lines and dynamic updates as participants comes = and go.

[BA] I think there are advantages to A even if multiple SSRC= s are declared within a m-line. =3B If the "main" video and "thumbnails= " change SSRCs=2C even with multiple SSRCs on an m-line=2C you'd still need= to renegotiate unless SVC is being used=2C right?
 =3B
>=3B I= f one had a single m=3D line per RTP session and media type=2C the amount>=3B of updates/renegotiation depends on the amount of meta data about<= br>>=3B streams that you have put in the SDP. The solutions A) and B) can= be
>=3B identical from an SDP perspective.

[BA] That's not obv= ious to me. Even if you have a single m=3Dline per RTP session and media ty= pe=2C
you can still have individual a=3Dssrc lines within a m=3D line.&= nbsp=3B In case B=2C as participants come and go=2C
aren't dynamic updat= es still required? =3B Also=2C instead of many m=3Dlines=2C you'll have= many a=3Dssrc
lines.

>=3B The above two cases I am quite cert= ain we did discuss in the CLUE
>=3B interim meeting in Stockholm when = discussing topologies and also the
>=3B relationship between RTP strea= ms (SSRC) and their origin=2C i.e. media
>=3B source/capture.

[= BA] Were there any specific requirements that arose in the CLUE discussion?=  =3B In general=2C given some of the context issues=2C it would be help= ful to understand whether we're engineering a solution for RTCWEB use cases= =2C CLUE use cases=2C or both.
= --_fcff5571-3b4e-4ade-b6c5-34281a6cd7a2_-- From bernard_aboba@hotmail.com Sat Feb 16 13:07:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564AD21F84D9 for ; Sat, 16 Feb 2013 13:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4j02FUlvAiB for ; Sat, 16 Feb 2013 13:07:15 -0800 (PST) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id D062921F896B for ; Sat, 16 Feb 2013 13:07:14 -0800 (PST) Received: from BLU002-W129 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Feb 2013 13:07:08 -0800 X-EIP: [aDLrxFtrVzvugH6/tXE+6itlb22cXnh1] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_4691e436-1b66-4ee5-8cc6-17bde45e537d_" From: Bernard Aboba To: Roni Even Date: Sat, 16 Feb 2013 13:07:07 -0800 Importance: Normal In-Reply-To: <01bf01ce0c3d$ad50dfe0$07f29fa0$@gmail.com> References: <01bf01ce0c3d$ad50dfe0$07f29fa0$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2013 21:07:08.0338 (UTC) FILETIME=[94983920:01CE0C89] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line - requirements for "fumble"!!! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 21:07:20 -0000 --_4691e436-1b66-4ee5-8cc6-17bde45e537d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] If A/V multiplexing is negotiated=2C then the only RTP de-multiplexin= g points you have left are the SSRC and the Payload type. If you rule out = "explicit per-source signaling"=2C that rules out SSRC de-multiplexing=2C w= hich leaves you only with Payload Type. Am I missing something?=20 I do agree that without A/V multiplexing=2C it is possible to avoid explici= t per-source signaling=2C since we can use the RTP session to de-multiplex= =2C so that we're still ok. But then we're not talking about Bundle/Grumbl= e/Fumble/Humble=2C right?=20 > The second topology brings the following requirement that I assume also > relate to what is called "fumble" >=20 > "it should be possible to support receipt of multiple RTP sources without > explicit per-source signaling or negotiation." >=20 > Roni Even = --_4691e436-1b66-4ee5-8cc6-17bde45e537d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] =3B If A/V multiplexing= is negotiated=2C then the only RTP de-multiplexing points you have left ar= e the SSRC and the Payload type. =3B If you rule out "explicit per-sour= ce signaling"=2C that rules out SSRC de-multiplexing=2C which leaves you on= ly with Payload Type. =3B Am I missing something?

I do agree th= at without A/V multiplexing=2C it is possible to avoid explicit per-source = signaling=2C since we can use the RTP session to de-multiplex=2C so that we= 're still ok. =3B But then we're not talking about Bundle/Grumble/Fumbl= e/Humble=2C right?

>=3B The second topology brings the follo= wing requirement that I assume also
>=3B relate to what is called "fum= ble"
>=3B
>=3B "it should be possible to support receipt of mult= iple RTP sources without
>=3B explicit per-source signaling or negotia= tion."
>=3B
>=3B Roni Even

= --_4691e436-1b66-4ee5-8cc6-17bde45e537d_-- From fluffy@cisco.com Sat Feb 16 15:56:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3FC21F8A6E for ; Sat, 16 Feb 2013 15:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1n4IVNM7PfM for ; Sat, 16 Feb 2013 15:56:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC4F721F8A6B for ; Sat, 16 Feb 2013 15:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=663; q=dns/txt; s=iport; t=1361059014; x=1362268614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6pUHWTV5OvpF3R1nCUvjrjcuvAjYkkFIO+kCfWi/H/0=; b=hjZkzqd/Qxovhb3l+ND7CR6znM2Ea+DaRWSRmmgtU51iM01zFGfcD56q AmzkaYHFr2fG6qdg/XlIGzUjOWgtEj2Dn4A9l/cULCSo2w2APwDqV2njw gL/a9vdSG5GHDwDfQAfjd6ZngJBB5fnuSycvnbF7s6+LfVNnkKOkitm6M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAOgbIFGtJV2Z/2dsb2JhbABEhgK6HYEBFnOCHwEBAQMBAQEBNzQLEAIBCBUNFBAnCyUCBA4FCBOHcQYMvHMEjwQCJgsHgl9hA6cEgweCJw X-IronPort-AV: E=Sophos;i="4.84,680,1355097600"; d="scan'208";a="177931851" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 16 Feb 2013 23:56:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1GNurGT023271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Feb 2013 23:56:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 17:56:53 -0600 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] BUNDLE: RTP only? Thread-Index: AQHODKFKqKnd3RPOU0Ohq6Kb7lUFiw== Date: Sat, 16 Feb 2013 23:56:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> In-Reply-To: <201302141953.r1EJrMT01840535@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <7810B33C240CA84F881D9072C1F04088@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 23:56:54 -0000 Sort of - I think the right question is can SCTP over DTLS over UDP demux f= rom SRTP over UDP and from STUN over UDP and the answer to that is yes.=20 On Feb 14, 2013, at 12:53 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >>=20 >> *If* there is a goal to share a single 5-tuple between RTP and SCTP then= =20 >> we need a solution allows bundling them. >=20 > Do any of the current proposed bundling techniques include both RTP > and SCTP? >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ekr@rtfm.com Sat Feb 16 16:08:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD30921F8A71 for ; Sat, 16 Feb 2013 16:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aS+w3qD3-c9 for ; Sat, 16 Feb 2013 16:08:11 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1954221F8A6F for ; Sat, 16 Feb 2013 16:08:11 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so1949642qec.5 for ; Sat, 16 Feb 2013 16:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=6/5qyYUCFzGajqB7/T8+tbeuzM3G7z10g6x1QsxvfcY=; b=PHq0rGSCzL1tkgut7j6GLRDjCnxpL7UJ1DL/vQrvpjcqhogkoYSpoGI22MCFStug/s yf3a2+5BNTuhPln+QzwWpz/FzFCqgeMzuAMWw880ruKNlrYZnEbbAYWNmLKtuHXz95/T sXAZtBEEd+GXZfu5yRN7mtarL5jktxbRH8wQp8dktozPZ1yc1fu/mXx6TuPCh72gEy0V 8MqO4K+Q/RcQ8JVr3zXAgdIP0ENTGZYXNJzy94rFr7qyhACHKlRozZsP9SfE+NObWZl/ ec+k6dhM2h0Mvz+BsASssfdAtGMFZH1iFTy4//3GlubxEPRvrIUAGouYqhZK9+M3tDSH honA== X-Received: by 10.49.127.101 with SMTP id nf5mr3050285qeb.20.1361059688543; Sat, 16 Feb 2013 16:08:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.28.230 with HTTP; Sat, 16 Feb 2013 16:07:28 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201302152222.r1FMMUpo1903639@shell01.TheWorld.com> References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> <511E8401.7010907@alum.mit.edu> <201302152222.r1FMMUpo1903639@shell01.TheWorld.com> From: Eric Rescorla Date: Sat, 16 Feb 2013 16:07:28 -0800 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b6dc0bc40f6d204d5e067d1 X-Gm-Message-State: ALoCoQl5tkkHm5HvNkDxVbe6zE1MtQRDeJIl/RY2zPDyhY4ggiFfwcwmt+ZHgdrq1qxtSqH7iSz1 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 00:08:12 -0000 --047d7b6dc0bc40f6d204d5e067d1 Content-Type: text/plain; charset=ISO-8859-1 Dale, I had assumed that the layering diagram looked as follows: SCTP DTLS SRT(C)P STUN UDP This means that the demux problem becomes something like - If packet is STUN, forward to ICE stack. - If packet is SRT(C)P: + Primary demux on payload type + Secondary demux on SSRC - If packet is DTLS + Demux SCTP associations by port number . SCTP streams are demuxed by stream ID 1. The first level of demux is described in RFC 5764 S 5.1.2. 2. The SRT(C)P demux appears to be specified in: http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-01 3. SCTP over DTLS encapsulation (and the elevant muxing) appears to be specified in: http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-01.txt and since the port is part of SCTP, this seems straightforward if we wish to allow it. Obviously, one could, as you suggest, tunnel everything over SCTP, but this seems like it would be less efficient in terms of bandwidth (since you would add a bunch of headers to the RTP) and would also be less compatible with existing SRTP endpoints. Best, -Ekr On Fri, Feb 15, 2013 at 2:22 PM, Dale R. Worley wrote: > The problem is divisible into two parts. One part is just clarifying > what needs to be supported. The second, harder part is specifying all > the mechanisms. > > When multiplexing, we have to establish: > > 1. What is the nature of the constituent data streams that can be > multiplexed? > > 2. What method is used to multiplex the constituents? Does there need > to be an encapsulation protocol? > > 3. What method is used to demultiplex the incoming PDUs of the > multiplexed data? > > 4. What carrier protocol is used to carry the multiplexed data? > > 5. How will we signal whatever information is needed to control the > demultiplexing process? (This is affected by any need to > interoperate with existing systems.) > > 6. Where in the stack of protocols do we apply encryption, and what is > its nature? > > Items 1 and 3 are the ones that are most constrained by the > requirements of the situation. > > As far as I can tell from what I've seen, the nature of the > constituent data streams is: > > - the RTP or SRTP traffic arising from zero or more SDP media > descriptions (Here we assume that it is important when > demultiplexing RTP that it is important to identify the correct > constituent media description for each incoming RTP packet; that RTP > cannot be interpreted except in the context of the correct media > description.) > > - the corresponding RTCP or Secure RTCP traffic (assuming we want to > have RTP/RTCP multiplexing) > > - the data carried over a single SCTP connection (which includes a > number of SCTP streams), or possibly more than one SCTP connection > if that is to be supported (It is not clear if the multiplexing > process has access to the data in the individual SCTP streams, or > whether the constituent data stream is the packets generated by > SCTP's multiplexing process, or whether it must handle the packets > generated by DTLS encrypting the SCTP packets.) > > The carrier protocol seems to be assumed to be UDP supplemented by the > STUN and ICE traffic needed to support a UDP association with the > far-end. However there may be value in using SCTP-over-DTLS-over-UDP > as the carrier protocol. > > In regard to encryption, it would be more efficient to apply > encryption only to the multiplexed data. That suggests that the > constituent data is unencrypted: RTP instead of SRTP, SCTP instead of > DTLS/SCTP. > > There tends to be an assumption that the demultiplexing process is > trivial, that all incoming PDUs can be identified and routed to their > correct destinations without any additional encapsulation > information. We might be lucky enough that that is true, but it is > not the common case. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7b6dc0bc40f6d204d5e067d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dale,

I had assumed that the layering diagram= looked as follows:

=A0 =A0 =A0SCTP
=A0 = =A0 =A0DTLS =A0 =A0SRT(C)P =A0 =A0 =A0 STUN
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0UDP


This means that the demux problem becomes something like

- If packet is STUN, forward to ICE stack.
= - If packet is SRT(C)P:
=A0 + Primary demux on payload type
=A0 + Secondary demux on SSRC
- If packet is DTLS
= =A0 + Demux SCTP associations by port number
=A0 =A0 . SCTP strea= ms are demuxed by stream ID

1. The first level of = demux is described in RFC 5764 S 5.1.2.
2. The SRT(C)P demux appears to be specified in:
3. SCTP over DTLS encapsulation (and the elevant muxing) appears to
=A0 =A0be specified in:
=A0 =A0and since the port is part of SCTP, this seems straightforward<= /div>
=A0 =A0if we wish to allow it.


Obviously, one could, as you suggest, tunnel everything over SCTP,
but this seems like it would be less efficient in terms of bandwidth
<= div>(since you would add a bunch of headers to the RTP) and would also
be less compatible with existing SRTP endpoints.

Best,
-Ekr
=A0 =A0 =A0 =A0





=A0 =A0
=
=A0 =A0


On Fri, Feb= 15, 2013 at 2:22 PM, Dale R. Worley <worley@ariadne.com> w= rote:
The problem is divisible into two parts. =A0= One part is just clarifying
what needs to be supported. =A0The second, harder part is specifying all the mechanisms.

When multiplexing, we have to establish:

1. What is the nature of the constituent data streams that can be
=A0 =A0multiplexed?

2. What method is used to multiplex the constituents? =A0Does there need =A0 =A0to be an encapsulation protocol?

3. What method is used to demultiplex the incoming PDUs of the
=A0 =A0multiplexed data?

4. What carrier protocol is used to carry the multiplexed data?

5. How will we signal whatever information is needed to control the
=A0 =A0demultiplexing process? =A0(This is affected by any need to
=A0 =A0interoperate with existing systems.)

6. Where in the stack of protocols do we apply encryption, and what is
=A0 =A0its nature?

Items 1 and 3 are the ones that are most constrained by the
requirements of the situation.

As far as I can tell from what I've seen, the nature of the
constituent data streams is:

- the RTP or SRTP traffic arising from zero or more SDP media
=A0 descriptions (Here we assume that it is important when
=A0 demultiplexing RTP that it is important to identify the correct
=A0 constituent media description for each incoming RTP packet; that RTP =A0 cannot be interpreted except in the context of the correct media
=A0 description.)

- the corresponding RTCP or Secure RTCP traffic (assuming we want to
=A0 have RTP/RTCP multiplexing)

- the data carried over a single SCTP connection (which includes a
=A0 number of SCTP streams), or possibly more than one SCTP connection
=A0 if that is to be supported (It is not clear if the multiplexing
=A0 process has access to the data in the individual SCTP streams, or
=A0 whether the constituent data stream is the packets generated by
=A0 SCTP's multiplexing process, or whether it must handle the packets<= br> =A0 generated by DTLS encrypting the SCTP packets.)

The carrier protocol seems to be assumed to be UDP supplemented by the
STUN and ICE traffic needed to support a UDP association with the
far-end. =A0However there may be value in using SCTP-over-DTLS-over-UDP
as the carrier protocol.

In regard to encryption, it would be more efficient to apply
encryption only to the multiplexed data. =A0That suggests that the
constituent data is unencrypted: RTP instead of SRTP, SCTP instead of
DTLS/SCTP.

There tends to be an assumption that the demultiplexing process is
trivial, that all incoming PDUs can be identified and routed to their
correct destinations without any additional encapsulation
information. =A0We might be lucky enough that that is true, but it is
not the common case.

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

--047d7b6dc0bc40f6d204d5e067d1-- From ron.even.tlv@gmail.com Sun Feb 17 00:41:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783D021F86F8 for ; Sun, 17 Feb 2013 00:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAG-XL7oEqXL for ; Sun, 17 Feb 2013 00:41:08 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6251421F86E6 for ; Sun, 17 Feb 2013 00:41:08 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so1848516eaa.24 for ; Sun, 17 Feb 2013 00:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:content-language :thread-index; bh=GOn+5d1HF16EEA00v2lxk0m68ag1sOG/0bmavXiv5gk=; b=uv6WapppXBvbyaSP1XRCVsFrcFuOXXyqx4Eenew2wh0QX0o4LjQhUL0mSqQ0/Tk8Uh ROmOa4MFVzXYwyY6cG4o/xYCLuPCm0eCrdtdm9fZicTRdxfZhgF1qFalwHWtRHiQrsXG ewJ9olN3IPC6ZHMW6O3uXOQt667HD2iX7IUamCLMsdDAycKwy2YI7NCRLlwK891y0BeS nE1B630LscTuBoxZsDKyHe0G4AXDZD75K9wIdZw9Obm6jd6pQJq9n7GBYMmMyAyqKzTk TJGhsaxUxLeVsDEtB12ClH65wC7ZNtmCe9zpn/0D9cPqLwTsNhvtBWzEi1niKggBacSB UuJg== X-Received: by 10.14.0.73 with SMTP id 49mr30202422eea.21.1361090467394; Sun, 17 Feb 2013 00:41:07 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id r4sm47792187eeo.12.2013.02.17.00.41.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Feb 2013 00:41:06 -0800 (PST) From: "Roni Even" To: "'Bernard Aboba'" References: <01bf01ce0c3d$ad50dfe0$07f29fa0$@gmail.com> In-Reply-To: Date: Sun, 17 Feb 2013 10:37:57 +0200 Message-ID: <023301ce0cea$186f48f0$494ddad0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0234_01CE0CFA.DBF8DC40" X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: AQGFYCXVY5mjGiO5yaiWJok/bDiVGALsTS7JmPevTnA= Cc: mmusic@ietf.org Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m= line - requirements for "fumble"!!! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 08:41:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0234_01CE0CFA.DBF8DC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The SSRCs will still be unique in the RTP session, I assume that what you are asking is how do you know what this SSRC is. It is not only if it is audio or video but may also apply to what is this audio and video is. For example, in a video conferencing systems with three monitors and cameras, how do we know where this SSRC should go. In CLUE we use a Capture ID that can be defined for each SSRC but can also be carried as a RTP header extension to provide the information. So when a new RTP stream with an SSRC that was not in the SDP it will have an RTP header extension with the CaptureID allowing the receiver to know what the stream is for. Roni Even From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 16 February, 2013 11:07 PM To: Roni Even Cc: mmusic@ietf.org Subject: RE: [MMUSIC] More thoughts on multiple media streams in a single m= line - requirements for "fumble"!!! [BA] If A/V multiplexing is negotiated, then the only RTP de-multiplexing points you have left are the SSRC and the Payload type. If you rule out "explicit per-source signaling", that rules out SSRC de-multiplexing, which leaves you only with Payload Type. Am I missing something? I do agree that without A/V multiplexing, it is possible to avoid explicit per-source signaling, since we can use the RTP session to de-multiplex, so that we're still ok. But then we're not talking about Bundle/Grumble/Fumble/Humble, right? > The second topology brings the following requirement that I assume also > relate to what is called "fumble" > > "it should be possible to support receipt of multiple RTP sources without > explicit per-source signaling or negotiation." > > Roni Even ------=_NextPart_000_0234_01CE0CFA.DBF8DC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The SSRCs will still be unique in the RTP session, I assume that what = you are asking is how do you know what this SSRC is. It is not only if = it is audio or video but may also apply to what is this audio and video = is. For example, in a video conferencing systems with three monitors and = cameras, how do we know where this SSRC should go. =

In CLUE we use a Capture ID that can be defined for each SSRC but can = also be carried as a RTP header extension to provide the information. So = when a new RTP stream with an SSRC that was not in the SDP it will have = an RTP header extension with the CaptureID allowing the receiver to know = what the stream is for.

 

Roni Even

 

From:= = Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 16 = February, 2013 11:07 PM
To: Roni Even
Cc: = mmusic@ietf.org
Subject: RE: [MMUSIC] More thoughts on = multiple media streams in a single m=3D line - requirements for = "fumble"!!!

 

[BA]  If A/V = multiplexing is negotiated, then the only RTP de-multiplexing points you = have left are the SSRC and the Payload type.  If you rule out = "explicit per-source signaling", that rules out SSRC = de-multiplexing, which leaves you only with Payload Type.  Am I = missing something?

I do agree that without A/V multiplexing, it = is possible to avoid explicit per-source signaling, since we can use the = RTP session to de-multiplex, so that we're still ok.  But then = we're not talking about Bundle/Grumble/Fumble/Humble, right? =

> The second topology = brings the following requirement that I assume also
> relate to = what is called "fumble"
>
> "it should be = possible to support receipt of multiple RTP sources without
> = explicit per-source signaling or negotiation."
>
> = Roni Even

------=_NextPart_000_0234_01CE0CFA.DBF8DC40-- From fluffy@cisco.com Sun Feb 17 11:52:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731F21F8438 for ; Sun, 17 Feb 2013 11:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBGDsSMpFrB1 for ; Sun, 17 Feb 2013 11:52:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 88C8B21F8A85 for ; Sun, 17 Feb 2013 11:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4004; q=dns/txt; s=iport; t=1361130775; x=1362340375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5ew7Azwx7+9+IIstJWYGBAZ6lezVon159xUeEL5xz1U=; b=fSp0ADceR6PoqRTvh4iGGeTteplUWQUXGZ/+MHbsA+d6Gz5kFA7M5E8H KlmYXLmsacWvDBT+H4tX+DsoIdRUw2gRZGtDhwhii0Aqe2KRE1GgrrkJt Kys2qsusbJ6R36ct4CEfUMCmKpCRYCMhebhAzzwS5wUZP0QNBG91+kxfK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGM0IVGtJXHA/2dsb2JhbAAqFwPAHX8Wc4IfAQEBAwEBAQFjCAsFCwIBCBQECgoEDAohBgskAQIBAw4FCId4AwkGDC2wP4NHDYlajFmBDQoRgQMCIRACBREHgkdhA4gxjCCCeIomhRWCNlGBaQkXHg X-IronPort-AV: E=Sophos;i="4.84,683,1355097600"; d="scan'208";a="178108258" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Feb 2013 19:52:55 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1HJqsmO024162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Feb 2013 19:52:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 13:52:54 -0600 From: "Cullen Jennings (fluffy)" To: Mary Barnes Thread-Topic: [MMUSIC] Call about Bundle Ports Feb 21 Thread-Index: AQHODIEYDx8V7J82L02mLqBV7r7eH5h+3FGA Date: Sun, 17 Feb 2013 19:52:53 +0000 Message-ID: References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <85CC251DC37262488B24AD2EBCB257FF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 19:52:57 -0000 When Richard and I went throughout times that might work for Europe and US = and our schedules it was pretty limited down to just two slots. I just pick= ed one. It's an awful time - it's during SIPIT, it's in the middle of the d= raft deadlines, it's pretty much not going to work for most people. That sa= id, Richard and I wanted to talk and figured there was no reason not to hav= e anyone else who was interested join in. It's not a WG meeting - clearly n= o decisions will be made at it. The problem is, given we want to talk befor= e the -01 deadline, and we want to talk after the -00 deadline so the new d= rafts are out, there was really no good time.=20 On Feb 16, 2013, at 1:06 PM, Mary Barnes wrote= : > At this point, it's going to be difficult for several of the CLUE WG > participants to attend at this point. A doodle would be nice to > ensure you have a reasonable representation from the groups involved. >=20 > Thanks, > Mary. >=20 > On Fri, Feb 15, 2013 at 10:36 AM, Cullen Jennings (fluffy) > wrote: >>=20 >> Hi All, >>=20 >> As discussed at the interim, Richard and I are planning to have a call t= o >> discuss issues around the same port or different ports in bundle. This i= s >> not an official WG call or anything but anyone is welcome to join us on = the >> call. Bridge info below. >>=20 >> Cullen >>=20 >>=20 >>=20 >>=20 >> Cullen Jennings invites you to attend this online meeting. >>=20 >> Topic: Bundle Ports >> Date: Thursday, February 21, 2013 >> Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) >> Meeting Number: 207 772 340 >> Meeting Password: ietf >>=20 >>=20 >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&PW= =3DNMjYwN2JjNzYz&RT=3DMiM0 >> 2. Enter your name and email address. >> 3. Enter the meeting password: ietf >> 4. Click "Join Now". >>=20 >> To view in other time zones or languages, please click the link: >> https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&PW= =3DNMjYwN2JjNzYz&ORT=3DMiM0 >>=20 >> ---------------------------------------------------------------- >> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes >> ---------------------------------------------------------------- >>=20 >> The affected toll free numbers are: (866) 432-9903 for the San Jose/Milp= itas >> area and (866) 349-3520 for the RTP area. >>=20 >> Please dial the local access number for your area from the list below: >> - San Jose/Milpitas (408) area: 525-6800 >> - RTP (919) area: 392-3330 >>=20 >> ------------------------------------------------------- >> To join the teleconference only >> ------------------------------------------------------- >> 1. Dial into Cisco WebEx (view all Global Access Numbers at >> http://cisco.com/en/US/about/doing_business/conferencing/index.html >> 2. Follow the prompts to enter the Meeting Number (listed above) or Acce= ss >> Code followed by the # sign. >>=20 >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >>=20 >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >>=20 >> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >>=20 >> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >>=20 >> ------------------------------------------------------- >>=20 >>=20 >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&ICS= =3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiM= wm3e2Gw&RT=3DMiM0 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 From worley@shell01.TheWorld.com Mon Feb 18 07:06:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526F421F8A84 for ; Mon, 18 Feb 2013 07:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ8rAecKInrd for ; Mon, 18 Feb 2013 07:06:03 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id ADB2721F8BBB for ; Mon, 18 Feb 2013 07:06:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1IF5fUe021160; Mon, 18 Feb 2013 10:05:43 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1IF5fvS2071754; Mon, 18 Feb 2013 10:05:41 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IF5dlr2046615; Mon, 18 Feb 2013 10:05:39 -0500 (EST) Date: Mon, 18 Feb 2013 10:05:39 -0500 (EST) Message-Id: <201302181505.r1IF5dlr2046615@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Eric Rescorla In-reply-to: (ekr@rtfm.com) References: <7594FB04B1934943A5C02806D1A2204B0D8131@ESESSMB209.ericsson.se> <511BF229.1090702@alum.mit.edu> <201302141953.r1EJrMT01840535@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B0D8A67@ESESSMB209.ericsson.se> <511D6A75.2030507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0D8CE4@ESESSMB209.ericsson.se> <511E8401.7010907@alum.mit.edu> <201302152222.r1FMMUpo1903639@shell01.TheWorld.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: RTP only? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:06:04 -0000 > From: Eric Rescorla > > I had assumed that the layering diagram looked as follows: > > SCTP > DTLS SRT(C)P STUN > UDP And though you don't state it explicitily, no additional framing info on the second step. But it seems to me that it's inefficient in that encryption is done separately for every input stream. Or is datagram encryption a lot more clever than I think it is? Dale From internet-drafts@ietf.org Mon Feb 18 11:49:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6166721F8BE8; Mon, 18 Feb 2013 11:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNF0Lg1ZY3UJ; Mon, 18 Feb 2013 11:49:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46421F8C22; Mon, 18 Feb 2013 11:49:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218194943.18197.25189.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 11:49:43 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:49:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-03.txt Pages : 19 Date : 2013-02-18 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation= -03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon Feb 18 11:50:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9257421F8943 for ; Mon, 18 Feb 2013 11:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl4Gk7x8ELIc for ; Mon, 18 Feb 2013 11:50:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 77D4A21F8C38 for ; Mon, 18 Feb 2013 11:50:24 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-f5-512285ff3a4c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DC.29.32353.FF582215; Mon, 18 Feb 2013 20:50:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 20:50:22 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: Ac4OENvQrjUr6KWHTMaYkeb/AHwyXg== Date: Mon, 18 Feb 2013 19:50:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje7/VqVAg7U/NS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEubr7MXHOKo+P/5O3sD4yu2LkZODgkBE4memY9YIGwxiQv3 1gPFuTiEBA4xSrw4M5UJwlnMKNF56BCQw8HBJmAh0f1PG6RBREBd4uveHmYQW1jAXWLCn4eM EHEfiTUfbjFD2HoS/w82gcVZBFQl+l/dAlvGK+AtceL/cSYQmxFo8fdTa8BsZgFxiVtP5jNB HCQgsWTPeWYIW1Ti5eN/rBC2osTOs+3MEPU6Egt2f2KDsLUlli18zQwxX1Di5MwnLBMYhWch GTsLScssJC2zkLQsYGRZxciem5iZk15uvokRGMYHt/w22MG46b7YIUZpDhYlcd5w1wsBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhiTw5T+PU7bv0Dc1u95h2yjU8WLewuZFkm3nDnzSSb8 b25dzMMlxyUO7OeuYrwqty1qX/CPKRFJq3YuOJwqtOt0o/nKi+1bq/NiX+XPlTDtrU5h73vM o6HAzbsgUML7lhjHcsbunV8DmU8ycqRqaqvM/R0e5FMQziEUMP/iLdktDn6OFw+t/6jEUpyR aKjFXFScCAAIExSIMQIAAA== Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:50:29 -0000 Hi, I've submitted a new version (-03) of BUNDLE. Based on discussions with Cullen, and exchange of the concerns we had with = the different port alternatives (different-ports vs identical-port), this v= ersion now describes a mechanism where both alternatives more or less are c= ombined. When the first BUNDLE offer is sent, and it is now known whether t= he answerer supports BUNDLE (or, even identical ports), different ports are= used (read: the one-rtp alterntaive). Once BUNDLE answer has been received= , a new offer, with identical port numbers, is sent. We think that having to send a second offer is not going to increase comple= xity and delay, because in many use-cases subsequent offer(s) will be sent = anyway. For example, RTCWEB entities will do it because of ICE. Cullen has also been added as co-author. Now, we do realize that there are still issues that have to be described, a= nd hopefully we will be able to focus on those from now on, but our wish is= that this proposal will unite the different "port camps" :) Regards, Christer= From ari.keranen@ericsson.com Mon Feb 18 11:59:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82621F8B0E for ; Mon, 18 Feb 2013 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ymoG0vRrl2C for ; Mon, 18 Feb 2013 11:59:29 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1458A21F86FB for ; Mon, 18 Feb 2013 11:59:28 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-55-5122881fff59 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3C.A9.32353.F1882215; Mon, 18 Feb 2013 20:59:27 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 18 Feb 2013 20:59:27 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E68BA22E1; Mon, 18 Feb 2013 21:59:26 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 770F2543AE; Mon, 18 Feb 2013 21:59:24 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3024854062; Mon, 18 Feb 2013 21:59:24 +0200 (EET) Message-ID: <5122881D.7030909@ericsson.com> Date: Mon, 18 Feb 2013 21:59:25 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic References: <20130218195107.10589.50005.idtracker@ietfa.amsl.com> In-Reply-To: <20130218195107.10589.50005.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130218195107.10589.50005.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvja58h1KgwaJd+hbNz5exW0xd/pjF gcljyZKfTB6t62cyBjBFcdmkpOZklqUW6dslcGXcnXaIuWA9b8W62QdYGhhbuLsYOTkkBEwk Lu1YzQRhi0lcuLeerYuRi0NI4CSjxK3PX5ggnA2MEq++3GQDqRIS2MUoMemkCIS9llGi+YUm RNFyRokf17YygiR4BbQl3jf8ZgGxWQRUJe73fAGz2QRsJVa/uglmiwokS3y8c40Vol5Q4uTM J2BxEQEZib2bNjOD2MICgRJ3H29nhVjmKHH32y+w+ZwCThL7t/cCxTmAzvaV2HXKFyTMLGAh sfjNQXYIW15i+9s5zBCfqUlcPbeJGWKMqsTVf68YJzCKzkKyeRaS9llI2hcwMq9iZM9NzMxJ LzffxAgM+oNbfhvsYNx0X+wQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jCEOhwp//WVa8thuwqekaWoNL49Z1P38uTQ4ehnnhZc3zk4SctsssUTiygGLWFt5FmthI14f Xf/iMy+lrJ/8uH3hRESYyCXhw8tf9Sr2h81fNunOZZ/T67Ya6W/duumM5XonpZBfTc0sMuY3 N/ZNP1+9J9XaLmit43cX9/xyW8cLfQeZrRiTzyqxFGckGmoxFxUnAgArDHT9SAIAAA== Subject: [MMUSIC] Fwd: New Version Notification for draft-keranen-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:59:30 -0000 Hi all, We have submitted a -00 version of the ICE-bis draft. This version is almost identical to RFC5245; only editorial changes (typo fixes, reference updates, etc.) have been done to give a proper basis for diffing. A diff between the RFC5245 and the bis-00: http://tools.ietf.org/rfcdiff?url2=draft-keranen-mmusic-rfc5245bis-00.txt The -01 version (to be submitted in a week) will have the SDP split from the base draft as discussed at Atlanta. Cheers, Ari -------- Original Message -------- A new version of I-D, draft-keranen-mmusic-rfc5245bis-00.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-mmusic-rfc5245bis Revision: 00 Title: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Creation date: 2013-02-18 Group: Individual Submission Number of pages: 118 URL: http://www.ietf.org/internet-drafts/draft-keranen-mmusic-rfc5245bis-00.txt Status: http://datatracker.ietf.org/doc/draft-keranen-mmusic-rfc5245bis Htmlized: http://tools.ietf.org/html/draft-keranen-mmusic-rfc5245bis-00 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). From richard.ejzak@alcatel-lucent.com Mon Feb 18 14:08:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE721F8B51; Mon, 18 Feb 2013 14:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.12 X-Spam-Level: X-Spam-Status: No, score=-9.12 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx8l1oTMD+hm; Mon, 18 Feb 2013 14:08:45 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 886F421F88AE; Mon, 18 Feb 2013 14:08:44 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1IM8hLW027475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Feb 2013 23:08:43 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 18 Feb 2013 23:08:43 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 18 Feb 2013 17:08:41 -0500 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHODiLaQ3NGrbmfrEqTjL/GIyKINpiAKZHw Date: Mon, 18 Feb 2013 22:08:40 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 22:08:46 -0000 UGxlYXNlIG5vdGUgdGhhdCBJIGhhdmUgYWxzbyBzdWJtaXR0ZWQgYSBkcmFmdCBvbiBob3cgdG8g Zml4IEJVTkRMRS4gIFRoaXMgZG9jIGlzIGJhc2VkIG9uIHRoZSBtb2RpZmllZCBCVU5ETEUgcHJv cG9zYWwgd2l0aCBkaWZmZXJlbnQgcG9ydCBpbmZvcm1hdGlvbiBmb3IgZWFjaCBtIGxpbmUgYW5k IGNvbXBhcmVzIHNldmVyYWwgZGlmZmVyZW50IGFkZGl0aW9uYWwgbW9kaWZpY2F0aW9ucyB0byBC VU5ETEUuICBUaGUgZG9jIGVuZHMgdXAgcmVjb21tZW5kaW5nIHRoZSB1c2Ugb2YgdGhlIHVuc3Bl Y2lmaWVkIGFkZHJlc3MgZm9yIHN1YnNlcXVlbnQgbSBsaW5lcyBpbiBhIGJ1bmRsZSBncm91cCBp biB0aGUgU0RQIGFuc3dlciAobm90IG9mZmVyKS4gIFBsZWFzZSBzZWUgdGhlIGRvYyBmb3IgZGV0 YWlscy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDE4LCAyMDEzIDM6NTcgUE0NClRvOiBFanphaywgUmljaGFyZCBQIChSaWNo YXJkKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1lanphay1t bXVzaWMtYnVuZGxlLWFsdGVybmF0aXZlcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRsZS1hbHRlcm5hdGl2ZXMtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJpY2hhcmQgRWp6YWsgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWVqemFrLW1tdXNpYy1idW5k bGUtYWx0ZXJuYXRpdmVzDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBBbHRlcm5hdGl2ZXMgdG8g QlVORExFDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0xOA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRsZS1hbHRl cm5hdGl2ZXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRsZS1hbHRlcm5hdGl2ZXMNCkh0bWxpemVk OiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZWp6YWstbW11c2ljLWJ1 bmRsZS1hbHRlcm5hdGl2ZXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgcGFwZXIgZGlzY3Vz c2VzIHNvbWUgcG90ZW50aWFsIG1vZGlmaWNhdGlvbnMgdG8gdGhlIEJVTkRMRQ0KICAgcHJvcG9z YWwgZm9yIG11bHRpcGxleGluZyBvZiBtdWx0aXBsZSBtZWRpYSB0eXBlcyB3aXRoaW4gYSBzaW5n bGUNCiAgIDUtdHVwbGUgdG8gYWRkcmVzcyBsaW1pdGF0aW9ucyBvZiB0aGUgY3VycmVudCBwcm9w b3NhbCBhbmQNCiAgIGFsdGVybmF0aXZlcyBhbHJlYWR5IGNvbnNpZGVyZWQgYnkgTU1VU0lDLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From internet-drafts@ietf.org Mon Feb 18 15:10:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF421E804B; Mon, 18 Feb 2013 15:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b30XEW6PoTo; Mon, 18 Feb 2013 15:10:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6221E804C; Mon, 18 Feb 2013 15:10:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218231041.24452.334.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 15:10:41 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 23:10:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass' At= tribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-03.txt Pages : 27 Date : 2013-02-18 Abstract: This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-traffic-class-for-sdp-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From partha@parthasarathi.co.in Tue Feb 19 10:46:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2C41F0D05 for ; Tue, 19 Feb 2013 10:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swNvxCF1lim1 for ; Tue, 19 Feb 2013 10:46:12 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.230]) by ietfa.amsl.com (Postfix) with ESMTP id 779A821F8E64 for ; Tue, 19 Feb 2013 10:46:12 -0800 (PST) Received: from userPC (unknown [122.179.89.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 549641EBFE25; Tue, 19 Feb 2013 18:46:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1361299571; bh=2p7iWoQgINRehvVk4n7INsZahAeEAqEegOcscLvRWyM=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FzFBoXuIKgEIPBFxWwMMXSeg2r19TCctAxR6CWno87lRNOFBeAGgTJ8NvFVakTP4k 7UG7ZwaUzmp58KCNcHUfXGaLKY19LQOlaLOwcVxBExy5Q/C9bsf4ADMy8mGq0Qsol2 cQXcZn7NNC56ZTEBttxeFjzDy+eU9QJ0GwevsFe8= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> Date: Wed, 20 Feb 2013 00:16:03 +0530 Message-ID: <003f01ce0ed1$61991860$24cb4920$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4OENvQrjUr6KWHTMaYkeb/AHwyXgAu/kYQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.5123C873.00FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:46:24 -0000 Hi Christer, The updated draft looks good as 1) The different port is passed in the offer which reduces interop issue with most of the SIP devices. 2) The mechanism allows to select same port and different port in the answerer side My comments & clarification queries are as follows: 1) The details Multiple answer for single bundled offer is not clear in the draft. The multiple answer may be due to SIP forking or WebRTC FedEx usecase sort of scenario. 2) Whether it is allowed in answerer side to generate new offer before receiving the identical port new offer from offerer? It is allowed from RFC 3264 perspective. 3) Open issue #2 in Sec 6.2: Please explain the side-effect in case bundle is done in the middle of the session. 4) Nits in Sec 8.2 para 2 Line 2: "generates an SDP" instead of "generates and SDP" Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, February 19, 2013 1:20 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > negotiation-03 > > > Hi, > > I've submitted a new version (-03) of BUNDLE. > > Based on discussions with Cullen, and exchange of the concerns we had > with the different port alternatives (different-ports vs identical- > port), this version now describes a mechanism where both alternatives > more or less are combined. When the first BUNDLE offer is sent, and it > is now known whether the answerer supports BUNDLE (or, even identical > ports), different ports are used (read: the one-rtp alterntaive). Once > BUNDLE answer has been received, a new offer, with identical port > numbers, is sent. > > We think that having to send a second offer is not going to increase > complexity and delay, because in many use-cases subsequent offer(s) > will be sent anyway. For example, RTCWEB entities will do it because of > ICE. > > Cullen has also been added as co-author. > > Now, we do realize that there are still issues that have to be > described, and hopefully we will be able to focus on those from now on, > but our wish is that this proposal will unite the different "port > camps" :) > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Feb 19 11:12:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B1621F8E7E for ; Tue, 19 Feb 2013 11:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zD+rl2Ejbi2 for ; Tue, 19 Feb 2013 11:12:03 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDEE21F8E79 for ; Tue, 19 Feb 2013 11:12:02 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-2d-5123ce812c5a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 09.77.19728.18EC3215; Tue, 19 Feb 2013 20:12:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 20:12:01 +0100 From: Christer Holmberg To: Parthasarathi R , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: AQHODtF0fxIiHQlm2k2UYTqYiwS3lpiBiyZR Date: Tue, 19 Feb 2013 19:12:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FACB0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se>, <003f01ce0ed1$61991860$24cb4920$@co.in> In-Reply-To: <003f01ce0ed1$61991860$24cb4920$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW7jOeVAg5sTFS2mLn/MYjH5Ux+r A5PHkiU/mTw+zP/CHsAUxWWTkpqTWZZapG+XwJXx7PkM5oLTEhVzp2xha2B8KNzFyMkhIWAi cXbxWWYIW0ziwr31bF2MXBxCAocYJRYe/c8O4SxmlNh6dztLFyMHB5uAhUT3P22QBhGBcImu VVvYQWxhgTCJznVNLDDxc5eOMkHYRhLzG26D1bAIqEosOn8XzOYV8JZ4v3s2K4gtJFAscb/t JSOIzQl0UPelmWAHMQId9P3UGrA5zALiEreezGeCOFRAYsme81BHi0q8fPyPFeQ0CQFFieX9 chDlOhILdn9ig7C1JZYtfM0MsVZQ4uTMJywTGEVnIZk6C0nLLCQts5C0LGBkWcXInpuYmZNe brSJERgJB7f8Vt3BeOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY m88ZikZp2y4OORWl8mrWAvV/r6vKMkMq9RRy5eNLws5tcAna8Y2R6Vm+ZjhTs/y6meomM4ou /iza5Dt7tei7BkMrCenW0J+uH7gc/u5PfTmtdltXlS2f87cru4QyL3X+nln2YeMSj+S3y+Wm 31W02Bv/J6R0zj0VOe/av6+NV861vc20ILhMiaU4I9FQi7moOBEA2Z9gBFICAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:12:03 -0000 Hi Partha, >The updated draft looks good as >1) The different port is passed in the offer which reduces interop issue >with most of the SIP devices. >2) The mechanism allows to select same port and different port in the >answerer side > >My comments & clarification queries are as follows: > >1) The details Multiple answer for single bundled offer is not clear in th= e >draft. The multiple answer may be due to SIP forking or WebRTC FedEx useca= se >sort of scenario. With "Multiple answer", do you mean answers received on different early dia= logs? If so, each answer will be handled separately, and a new offer has to= be sent on each early dialog (assuming the answer indicated support of BUN= DLE). >2) Whether it is allowed in answerer side to generate new offer before >receiving the identical port new offer from offerer? It is allowed from RF= C >3264 perspective. I see no reason to forbid it. However, in order to prevent a race condition= , maybe we should recommend that the answerer side does not generate an off= er by itself, until it has received the single-port offer? >3) Open issue #2 in Sec 6.2: Please explain the side-effect in case bundle >is done in the middle of the session. I am not sure I understand what you mean by "side-effect"? >4) Nits in Sec 8.2 para 2 Line 2: "generates an SDP" instead of "generates= and SDP" Will be fixed :) Thanks! Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, February 19, 2013 1:20 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > negotiation-03 > > > Hi, > > I've submitted a new version (-03) of BUNDLE. > > Based on discussions with Cullen, and exchange of the concerns we had > with the different port alternatives (different-ports vs identical- > port), this version now describes a mechanism where both alternatives > more or less are combined. When the first BUNDLE offer is sent, and it > is now known whether the answerer supports BUNDLE (or, even identical > ports), different ports are used (read: the one-rtp alterntaive). Once > BUNDLE answer has been received, a new offer, with identical port > numbers, is sent. > > We think that having to send a second offer is not going to increase > complexity and delay, because in many use-cases subsequent offer(s) > will be sent anyway. For example, RTCWEB entities will do it because of > ICE. > > Cullen has also been added as co-author. > > Now, we do realize that there are still issues that have to be > described, and hopefully we will be able to focus on those from now on, > but our wish is that this proposal will unite the different "port > camps" :) > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Tue Feb 19 12:51:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A3121F88FB for ; Tue, 19 Feb 2013 12:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n3gdL0AEknC for ; Tue, 19 Feb 2013 12:51:02 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id F3DFC21F887F for ; Tue, 19 Feb 2013 12:51:01 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so3157007eaa.41 for ; Tue, 19 Feb 2013 12:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=MaS+XZI6yljPda+/8tFzSINUNCOUnErzIYrmmOo3UzM=; b=jp91jDFNyJndAag5FkB3eb4Qe2xwQ3UlWfSM8ftuiMaKHhN+lIUhFQPrHb69jQtt8y Dtxpv2joXiqpzfMwW0J64pZg6n17YKcqfCaI2vw1FRl3krGJdImu86p3kjUGZj+sYy7h fQxFsyKa5Eg2YN1yjGXePzc38ELdPuiPaiCTTwvXtGeLtBvo5PUqY4lVyEoqWBzlqu0H ioC9qL7D1zS+BpOXbsLIn+4Y14MD0i8dQK3vE7/bgR2oNTmolf1yiB9b283zOpZGClKB 5BwhmYVBb6Sw5Spm5nWXBpFgut1ivTlrvcCRd253wlZzmzlSOIP0fMkRnfTDmAVYmZg3 UBew== X-Received: by 10.14.218.71 with SMTP id j47mr60437562eep.28.1361307060999; Tue, 19 Feb 2013 12:51:00 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id m46sm41738936eeo.16.2013.02.19.12.50.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 12:51:00 -0800 (PST) From: "Roni Even" To: References: <20130217082635.25082.70739.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B80814@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B80814@szxpml504-mbx.exmail.huawei.com> Date: Tue, 19 Feb 2013 22:47:51 +0200 Message-ID: <01ac01ce0ee2$63cd4dc0$2b67e940$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWpNFiQVtRQzTG4dCaOvaRvxCDYQJsk1O5l90Wb3A= Content-Language: en-us Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-multiple-streams-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:51:04 -0000 FYI From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, February 17, 2013 10:26 AM To: Roni Even Cc: jonathan@vidyo.com; bill.wu@huawei.com Subject: New Version Notification for draft-even-mmusic-multiple-streams-02.txt A new version of I-D, draft-even-mmusic-multiple-streams-02.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-multiple-streams Revision: 02 Title: Describing multiple RTP media streams in SDP Creation date: 2013-02-17 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-multiple-streams-02.tx t Status: http://datatracker.ietf.org/doc/draft-even-mmusic-multiple-streams Htmlized: http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-even-mmusic-multiple-streams-02 Abstract: This document describes issues when describing multiple RTP streams in a single RTP session using SDP and considers the different RTP topologies that should be supported. The document looks at current solutions and provides paths toward addressing the issues. The IETF Secretariat= From christer.holmberg@ericsson.com Wed Feb 20 04:27:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CFA21F87CB; Wed, 20 Feb 2013 04:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7lzB69NK3eW; Wed, 20 Feb 2013 04:27:56 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51421F87D5; Wed, 20 Feb 2013 04:27:56 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-37-5124c14ba63b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A0.23.32353.B41C4215; Wed, 20 Feb 2013 13:27:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 13:27:54 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHODiLaQ3NGrbmfrEqTjL/GIyKINpiAKZHwgAJ/clA= Date: Wed, 20 Feb 2013 12:27:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvja73QZVAg44+MYupyx+zWPQ2hFus /dfO7sDs0fpsL6vHkiU/mQKYorhsUlJzMstSi/TtErgy/p0/x1QwQ6riQtMz5gbGFyJdjJwc EgImEsfP/GaHsMUkLtxbz9bFyMUhJHCIUeLj4TusEM5iRonVn08CVXFwsAlYSHT/0waJiwj0 M0p0f1vMCNItLJAmMXNSExuILSKQLvHq4gMo20rizMs1YDUsAqoSD96tAZvDK+AtcfmOFYgp JBAjMeFWFEgFp0CsxKkF71lBbEage76fWsMEYjMLiEvcejKfCeJOAYkle84zQ9iiEi8f/2OF sBUlrk5fDlWvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG 9tzEzJz0cvNNjMCIOLjlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAKFXFW6tztKQqa2lhgsPdaLOWiIdNNVum9ZS4beNQ45R5v7v1Q3LVlJO7NutPkrBo /bP2VLi6A4vmPaOHW65+er7AX0I7JyYkuUdMbmvodo2g/o2bQpTdfEtXVibf4EuZI9s9YUK8 /ew+s5f5Nx0uyxnflvnCzZravum8UoNKoqTBQ1PTEzeVWIozEg21mIuKEwH8jnfFVgIAAA== Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 12:27:58 -0000 Hi Richard, It would have been good with some example messages/flows, but I'll give my = comments based on my understanding of the text. Also, I'll focus on the "Un= specified address for subsequent m lines in SDP answer" alternative, as it = is the one you recommend, but I believe my comments also apply to some of t= he other alternatives. In general, you only focus on one single issue, but leave a number of quest= ions unanswered. First, as you will now have a single non-zero m- line, you still assume tha= t entities (including intermediaries) will take information (media types, p= ayload type mappings etc etc etc - even protocol, if we decide to also allo= w the data channel in the bundle) from all m- lines. Or, do you intend to p= ut all that information into a single m- line? If so, in my opinion MMT is = a much better approach. Second, what if a user wants the disable, or reject, a specific stream, usi= ng port zero? How is it done in case the stream is already represented by a= zero m- line? How is it done in case the stream is represented by the non-= zero m- line which contains the port number value used for the whole bundle= ? Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 19. helmikuuta 2013 0:09 To: mmusic@ietf.org; rtcweb@ietf.org Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundl= e-alternatives-00.txt Please note that I have also submitted a draft on how to fix BUNDLE. This = doc is based on the modified BUNDLE proposal with different port informatio= n for each m line and compares several different additional modifications t= o BUNDLE. The doc ends up recommending the use of the unspecified address = for subsequent m lines in a bundle group in the SDP answer (not offer). Pl= ease see the doc for details. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, February 18, 2013 3:57 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-mmusic-bundle-alternative= s-00.txt A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF rep= ository. Filename: draft-ejzak-mmusic-bundle-alternatives Revision: 00 Title: Alternatives to BUNDLE Creation date: 2013-02-18 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-bun= dle-alternatives-00.txt Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic-bundle-= alternatives Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-bundle-alter= natives-00 Abstract: This paper discusses some potential modifications to the BUNDLE proposal for multiplexing of multiple media types within a single 5-tuple to address limitations of the current proposal and alternatives already considered by MMUSIC. = =20 The IETF Secretariat _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Wed Feb 20 07:24:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7081B21F87BA; Wed, 20 Feb 2013 07:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.41 X-Spam-Level: X-Spam-Status: No, score=-7.41 tagged_above=-999 required=5 tests=[AWL=-1.420, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuizP09qZpsp; Wed, 20 Feb 2013 07:24:54 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D021F869A; Wed, 20 Feb 2013 07:24:53 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1KFOBb5011730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2013 16:24:51 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 20 Feb 2013 16:24:41 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 20 Feb 2013 10:24:36 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHOD2W+toYseWtIxEKEwtE+xBCEiZiCxbWg Date: Wed, 20 Feb 2013 15:24:35 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:24:55 -0000 Hi Christer, Thanks for your comments! See below. Richard > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >=20 > First, as you will now have a single non-zero m- line, you still assume > that entities (including intermediaries) will take information (media > types, payload type mappings etc etc etc - even protocol, if we decide > to also allow the data channel in the bundle) from all m- lines. Or, do > you intend to put all that information into a single m- line? If so, in > my opinion MMT is a much better approach. The intent is to reuse all of the existing information in the subsequent m = lines except the connection, candidate and non-zero port information. That= excludes the crypto info as well. >=20 > Second, what if a user wants the disable, or reject, a specific stream, > using port zero? How is it done in case the stream is already > represented by a zero m- line? How is it done in case the stream is > represented by the non-zero m- line which contains the port number > value used for the whole bundle? A zero port value would retain its original semantic of disabling/rejecting= an individual m line. In my proposal all subsequent m lines in the SDP an= swer that are accepted would have valid and unique non-zero port values tha= t are different from the port value in the first m line of the bundle group= .=20 I admit that I did not think through how to disable the first m line in the= group, but let me propose the following: Let's specify that we get the connection and port information for the bundl= e from the first valid (non-zero port) m line in the bundle group of the SD= P answer (not offer). If the answerer wants to disable the first valid m l= ine(s) of the bundle group in the first SDP offer, both ends use the connec= tion and port information from the next valid m line in the SDP answer (and= its corresponding m line in the SDP offer). The offerer had valid informa= tion for each m line in the SDP offer so it doesn't matter which set we use= after the first offer/answer transaction. But we don't want to change the= 5-tuple or crypto info for the bundle with any subsequent offer/answer. If the offerer wants to disable the first valid m line(s) of a bundle group= in a subsequent offer, it places the connection and port information for t= he bundle group in the next valid m line of the bundle group in the SDP off= er (it would actually move this information from the previous first valid m= line to the new one to avoid restarting crypto or changing ports). In res= ponse to the new offer disabling the initial valid m line(s), the answerer = similarly places the connection and port information for the bundle group i= n the corresponding m line of the SDP answer. The answerer is not allowed = to disable the first valid m line of a bundle group in the SDP answer it se= nds in response to a subsequent offer. If the answerer needs to disable th= e first valid m line(s), it must instead accept the m line(s) in response t= o the latest pending offer (if there is one) and immediately send a new SDP= offer disabling the line by following the SDP offerer rule above. =20 The only other rule to add is that the SDP offerer will never re-enable (se= t port to a non-zero value) a disabled m line before the first valid m line= in a bundle group but will instead create a new m line and add it to the g= roup. This makes it unlikely that the answerer will reject the first valid= m line of the bundle group in a subsequent SDP offer since it had previous= ly accepted it and did not initiate the new transaction due to any changes = in the configuration of local resources. This isn't particularly elegant, but it applies the definition consistently= and I think it works in all cases. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ejzak, Richard P (Richard) > Sent: 19. helmikuuta 2013 0:09 > To: mmusic@ietf.org; rtcweb@ietf.org > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic- > bundle-alternatives-00.txt >=20 > Please note that I have also submitted a draft on how to fix BUNDLE. > This doc is based on the modified BUNDLE proposal with different port > information for each m line and compares several different additional > modifications to BUNDLE. The doc ends up recommending the use of the > unspecified address for subsequent m lines in a bundle group in the SDP > answer (not offer). Please see the doc for details. >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, February 18, 2013 3:57 PM > To: Ejzak, Richard P (Richard) > Subject: New Version Notification for draft-ejzak-mmusic-bundle- > alternatives-00.txt >=20 >=20 > A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt > has been successfully submitted by Richard Ejzak and posted to the IETF > repository. >=20 > Filename: draft-ejzak-mmusic-bundle-alternatives > Revision: 00 > Title: Alternatives to BUNDLE > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-ejzak- > mmusic-bundle-alternatives-00.txt > Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic- > bundle-alternatives > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-bundle- > alternatives-00 >=20 >=20 > Abstract: > This paper discusses some potential modifications to the BUNDLE > proposal for multiplexing of multiple media types within a single > 5-tuple to address limitations of the current proposal and > alternatives already considered by MMUSIC. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Wed Feb 20 09:40:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397321F8992 for ; Wed, 20 Feb 2013 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkDPiVRRwDcc for ; Wed, 20 Feb 2013 09:40:43 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.151]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8421F87CC for ; Wed, 20 Feb 2013 09:40:41 -0800 (PST) Received: from userPC (unknown [122.179.33.141]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 291F3868533; Wed, 20 Feb 2013 17:40:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1361382034; bh=LTnbGECLXs9SXReDFWJ8F04OCmWxT0mDNIcWzebLxrQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dpQcgPOWaEE6fRSOK8p7tnPP73Wgb8SGCR9cVFn73NghQJiXmgbJ9IJhF/3t0wWh+ JUh6CF3PEiloeXZQLwvuzslnXZ2HCfDvBI18Abb2lFLm66PEWKSps7ZvhCZW4J8kWM P81sUwsw2tCer4Xw9pMXtxVWZLsfKv8HUZVtpmXs= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se>, <003f01ce0ed1$61991860$24cb4920$@co.in> <7594FB04B1934943A5C02806D1A2204B0FACB0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FACB0@ESESSMB209.ericsson.se> Date: Wed, 20 Feb 2013 23:10:19 +0530 Message-ID: <002301ce0f91$60b1e970$2215bc50$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHODtF0fxIiHQlm2k2UYTqYiwS3lpiBiyZRgAFzjfA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.51250A92.010D, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.151 Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:40:48 -0000 Hi Christer, The main usecase for "Multiple answer" is different answer in early dialog/dialog (SIP forking). It is possible to see each answer as a separate dialog (offer-answer) in case the applicability of the bundle draft is RFC 3261(SIP). As per this draft applicability is currently RFC 3264 (offer-answer), So, is there a need to define/clarify about the higher aggregation like (early) dialog for handling "multiple answer" within bundle negotiation? Please read inline for more comments. Thanks Partha > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, February 20, 2013 12:42 AM > To: Parthasarathi R; mmusic@ietf.org > Subject: RE: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > negotiation-03 > > > Hi Partha, > > >The updated draft looks good as > >1) The different port is passed in the offer which reduces interop > issue > >with most of the SIP devices. > >2) The mechanism allows to select same port and different port in the > >answerer side > > > >My comments & clarification queries are as follows: > > > >1) The details Multiple answer for single bundled offer is not clear > in the > >draft. The multiple answer may be due to SIP forking or WebRTC FedEx > usecase > >sort of scenario. > > With "Multiple answer", do you mean answers received on different early > dialogs? If so, each answer will be handled separately, and a new offer > has to be sent on each early dialog (assuming the answer indicated > support of BUNDLE). > > >2) Whether it is allowed in answerer side to generate new offer before > >receiving the identical port new offer from offerer? It is allowed > from RFC > >3264 perspective. > > I see no reason to forbid it. However, in order to prevent a race > condition, maybe we should recommend that the answerer side does not > generate an offer by itself, until it has received the single-port > offer? I agree with you. Could you please add the recommendation in the next revision > > >3) Open issue #2 in Sec 6.2: Please explain the side-effect in case > bundle > >is done in the middle of the session. > > I am not sure I understand what you mean by "side-effect"? I'm not seeing any issue in modify the bundle negotiation after the session is established. IMO, the bundle should be allowed in the middle of the session. I'm asking any known side-effect in case bundle is done in the middle of the session > > >4) Nits in Sec 8.2 para 2 Line 2: "generates an SDP" instead of > "generates and SDP" > > Will be fixed :) > > Thanks! > > Regards, > > Christer > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, February 19, 2013 1:20 AM > > To: mmusic@ietf.org > > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > > negotiation-03 > > > > > > Hi, > > > > I've submitted a new version (-03) of BUNDLE. > > > > Based on discussions with Cullen, and exchange of the concerns we had > > with the different port alternatives (different-ports vs identical- > > port), this version now describes a mechanism where both alternatives > > more or less are combined. When the first BUNDLE offer is sent, and > it > > is now known whether the answerer supports BUNDLE (or, even identical > > ports), different ports are used (read: the one-rtp alterntaive). > Once > > BUNDLE answer has been received, a new offer, with identical port > > numbers, is sent. > > > > We think that having to send a second offer is not going to increase > > complexity and delay, because in many use-cases subsequent offer(s) > > will be sent anyway. For example, RTCWEB entities will do it because > of > > ICE. > > > > Cullen has also been added as co-author. > > > > Now, we do realize that there are still issues that have to be > > described, and hopefully we will be able to focus on those from now > on, > > but our wish is that this proposal will unite the different "port > > camps" :) > > > > Regards, > > > > Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Wed Feb 20 09:47:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3C21F8947 for ; Wed, 20 Feb 2013 09:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIJf3sjiHnaf for ; Wed, 20 Feb 2013 09:47:30 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9228021F86FF for ; Wed, 20 Feb 2013 09:47:29 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2bLU1l0081uE5Es53hnUrP; Wed, 20 Feb 2013 17:47:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 2hnU1l00i3ZTu2S3chnUMC; Wed, 20 Feb 2013 17:47:28 +0000 Message-ID: <51250C30.4040509@alum.mit.edu> Date: Wed, 20 Feb 2013 12:47:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se>, <003f01ce0ed1$61991860$24cb4920$@co.in> <7594FB04B1934943A5C02806D1A2204B0FACB0@ESESSMB209.ericsson.se> <002301ce0f91$60b1e970$2215bc50$@co.in> In-Reply-To: <002301ce0f91$60b1e970$2215bc50$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361382448; bh=/CEOjRCJoEeLGRuy84MbvUoo7Umj63PfKJ+T1TPr3zs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HjPDiTm1OwnopGp4UGsXAvg7XubO4qACxhqSf4sb/mj6FT7oXusn5XEgtUjsXeOWt DjJoH/Mh4r0/1IgTIVWFFAg+ExsOYoNtkwC8vMcHITgP07e7oFG9h7J5XXPweuvpIN S7t1Ov2EnmNKl8ZazYsnYMAsvqC+LkOVtyhfwhRvbhsQgW8hykolJYlWVlJMOtZVCV Wpbt2Xqa58GlKZ0Rg8pRLI9eHluW/4K+U96z5AxAvUOXQxE2rNO4WzCqGnEjCknx6F QFreXwMj1xgpctJ8U369qZjT2gqKuh8rAvOGW7kPhPEj2JxwiloEbWNJXWZg40c8/V tJDyedrBMQFBQ== Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:47:31 -0000 On 2/20/13 12:40 PM, Parthasarathi R wrote: >>> 2) Whether it is allowed in answerer side to generate new offer before >>> receiving the identical port new offer from offerer? It is allowed >> from RFC >>> 3264 perspective. >> >> I see no reason to forbid it. However, in order to prevent a race >> condition, maybe we should recommend that the answerer side does not >> generate an offer by itself, until it has received the single-port >> offer? > I agree with you. Could you please add the recommendation in the > next revision IMO this is a bad idea. The UAS may not be able to wait, or it may complicate the programming to wait. Thanks, Paul From christer.holmberg@ericsson.com Wed Feb 20 12:03:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90921E8041 for ; Wed, 20 Feb 2013 12:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YArUJTG8uNdO for ; Wed, 20 Feb 2013 12:03:11 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6245E21E803A for ; Wed, 20 Feb 2013 12:03:11 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-16-51252bfe36d5 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EC.EB.32353.EFB25215; Wed, 20 Feb 2013 21:03:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 21:03:09 +0100 From: Christer Holmberg To: Parthasarathi R , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: AQHOD5Fk9I8mGq8jgU+CtEpEW8CmgZiDKh1e Date: Wed, 20 Feb 2013 20:03:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FD816@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se>, <003f01ce0ed1$61991860$24cb4920$@co.in> <7594FB04B1934943A5C02806D1A2204B0FACB0@ESESSMB209.ericsson.se>, <002301ce0f91$60b1e970$2215bc50$@co.in> In-Reply-To: <002301ce0f91$60b1e970$2215bc50$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje4/bdVAgx9LZSymLn/MYjH5Ux+r A5PHkiU/mTw+zP/CHsAUxWWTkpqTWZZapG+XwJXRsespW8F1mYqNJ7awNTD+Eeti5OCQEDCR mPu0vIuRE8gUk7hwbz1bFyMXh5DAIUaJVTeaWSGcxYwSzT8OsoM0sAlYSHT/0wZpEBEIl+ha tYUdxBYWCJPoXNfEAhM/d+koE0i5iICRxIQ55iBhFgFViY1975lBbF4Bb4md22cyQ4y/yyjx 8MwUsPGcQPes3S4KUsMIdM/3U2uYQGxmAXGJW0/mM0HcKSCxZM95ZghbVOLl43+sELaixMdX +xgh6nUkFuz+xAZha0ssW/gaaq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye9 3HwTIzAODm75bbCDcdN9sUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw Wj5/3P0scdXPpfI9b/RavqccmF3xcIuBNZeb+nzzKV1erSVhgeI7lM0Pzb35a73MggWlvStS VFpPddzd0z3p1ssT/f5rJ17W/qi4OUpAZjnH5pmr8l5J827t2ZF+qK/nDztDDZdX8HvLMJO6 /ReVX22X43mp84RPoKH4qFBJ5cEZ2VYXJf13KrEUZyQaajEXFScCANTQS2FRAgAA Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:03:12 -0000 Hi Partha, >The main usecase for "Multiple answer" is different answer in early >dialog/dialog (SIP forking). It is possible to see each answer as a separa= te >dialog (offer-answer) in case the applicability of the bundle draft is RFC >3261(SIP). As per this draft applicability is currently RFC 3264 >(offer-answer), So, is there a need to define/clarify about the higher >aggregation like (early) dialog for handling "multiple answer" within bund= le >negotiation? I have difficulties to understand what you are asking. There is no such thi= ng as "multiple answer" in RFC 3264. There is an offer, followed by an answ= er.=20 >>>2) Whether it is allowed in answerer side to generate new offer before >>>receiving the identical port new offer from offerer? It is allowed >>>from RFC 3264 perspective. >>> >>I see no reason to forbid it. However, in order to prevent a race >>condition, maybe we should recommend that the answerer side does not >>generate an offer by itself, until it has received the single-port >offer? > I agree with you. Could you please add the recommendation in the >next revision We can discuss such details later (and I noted that Paul has another opinon= :), but first I would like to know whether the WG on a high level can agre= e on moving forward with this :) >>>3) Open issue #2 in Sec 6.2: Please explain the side-effect in case >>>bundle is done in the middle of the session. >> >> I am not sure I understand what you mean by "side-effect"? > I'm not seeing any issue in modify the bundle negotiation after t= he >session is established. IMO, the bundle should be allowed in the middle of >the session. I'm asking any known side-effect in case bundle is done in th= e >middle of the session I can't think of any side-effects. Regards, Christer > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, February 19, 2013 1:20 AM > > To: mmusic@ietf.org > > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > > negotiation-03 > > > > > > Hi, > > > > I've submitted a new version (-03) of BUNDLE. > > > > Based on discussions with Cullen, and exchange of the concerns we had > > with the different port alternatives (different-ports vs identical- > > port), this version now describes a mechanism where both alternatives > > more or less are combined. When the first BUNDLE offer is sent, and > it > > is now known whether the answerer supports BUNDLE (or, even identical > > ports), different ports are used (read: the one-rtp alterntaive). > Once > > BUNDLE answer has been received, a new offer, with identical port > > numbers, is sent. > > > > We think that having to send a second offer is not going to increase > > complexity and delay, because in many use-cases subsequent offer(s) > > will be sent anyway. For example, RTCWEB entities will do it because > of > > ICE. > > > > Cullen has also been added as co-author. > > > > Now, we do realize that there are still issues that have to be > > described, and hopefully we will be able to focus on those from now > on, > > but our wish is that this proposal will unite the different "port > > camps" :) > > > > Regards, > > > > Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ekr@rtfm.com Wed Feb 20 16:27:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1921E8049 for ; Wed, 20 Feb 2013 16:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBD08MyidOte for ; Wed, 20 Feb 2013 16:27:45 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id E63B421E803C for ; Wed, 20 Feb 2013 16:27:44 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id a22so3303586qcs.40 for ; Wed, 20 Feb 2013 16:27:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=rSFQ/bSa4/gRn1w3r6D48J14VCt39OQM/AmHB9OJ43M=; b=G27cilTgTz9cKJsCIO9TBrE7cqoxVoyhy8dZs9WVBekZYhhEgyIwky2G9a4lqS89tM qnQcr5NgJ0f4O1kMCwpsEAy34BKrbsZQ00JEJ/H0f5H7PH5d0irhBqxOb90aZpiJ0LAm 4JaqoxpoVf8IW3Jewp03NmDOv9uBz5V/MUCLai13mbXE03WaKi3yHrTepHXnhPMMYSS3 t+fXoRvwoGXcWN9jR6jR1ko/k8gnoaKCcIMqK+dKIf6eH1hBye98Xb5Harg2+qm6pO1a 0t0fDH31AsfZ2eT91/vr5RZBgIk0ou+5VQGI24yt0rlbfyxkH8hCdGQnJJ8PDylvTnQM 7OSA== X-Received: by 10.49.127.101 with SMTP id nf5mr11401141qeb.20.1361406464174; Wed, 20 Feb 2013 16:27:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.28.230 with HTTP; Wed, 20 Feb 2013 16:27:03 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Wed, 20 Feb 2013 16:27:03 -0800 Message-ID: To: rtcweb@ietf.org, mmusic WG Content-Type: multipart/alternative; boundary=047d7b6dc0bcb147b304d6312431 X-Gm-Message-State: ALoCoQlqstWEFbRdAL2f9XO69DZ7IMCFNVDUPyD/UonwIZXye5vgdQKiar6V4So/Fdh9NoShABfw Subject: [MMUSIC] Proposed Agenda For WG Meetings X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:27:46 -0000 --047d7b6dc0bcb147b304d6312431 Content-Type: text/plain; charset=ISO-8859-1 In the tradition of the Interim, I tried to sit down and work out an agenda that reflects that I think the important concerns are, namely: - Video codecs (as promised) - Multiplexing of media flows - Trickle ICE - DataChannels Two notes about cross-WG interaction: - I'm assuming that most of the MMUSIC time will be used for RTCWEB-type stuff, though I left 30 min for other MMUSIC business on Tue. - I don't know how much time AVTEXT needs given the AVTEXT/ MMUSIC merger on Fri. We can reduce the draft-jennings-rtcweb-plan time accordingly based on agenda requests. Hope this is useful. I'm of course happy to get on a call to discuss this if that helps. -Ekr RTCWEB I: Tuesday 0900-1130 0900 - 0905 Administrivia 0905 - 1100 Video Codec MTI discussion - draft-alvestrand-rtcweb-vp8-00 (30 mins) - draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-00+draft-marjou-rtcweb-video-codec-00 (30 mins) - General discussion 30 min) - Call the question of which mandatory to implement video codec to select (5 min) - Next steps (20 min) 1100 - 1115 draft-ietf-rtcweb-use-cases-and-requirements (LC comments) 1115 - 1130 draft-ietf-draft-ietf-rtcweb-overview (LC comments) MMUSIC I: Tuesday 1520-1830 1520 - 1525 Administrivia 1525 - 1605 Trickle ICE (Ivov) - Under what conditions can you do full trickle (discovery) - When can checking stop? [UPDATE vs. in-band vs...?] - SDP/SIP encoding for additional trickle candidates 1605 - 1650 - Bundle - draft-ejzak-mmusic-bundle-alternatives (15 min) - draft-ietf-mmusic-sdp-bundle-negotiation (15 min) - discussion/consensus calls (15 min) 1650 - 1700 [Break] 1700 - 1800 SDP attribute analysis for multiplexing - draft-nandakumar-mmusic-sdp-mux-attributes 1800 - 1830 [Other MMUSIC business] RTCWEB II: Thursday 0900-1130 0900 - 0905 Administrivia 0905 - 1025 Data Channel negotiation - draft-jesup-rtcweb-data-protocol (15 min) - draft-thomson-rtcweb-data (15 min) - draft-marcon-rtcweb-data-channel-management (15 min) - Discussion (30 min) - Consensus call (5 min) 1025 - 1100 JSEP Update (Uberti) - draft-ietf-rtcweb-jsep 1100 - 1115 RTCP-XR (Westerlund) 1115 - 1130 RTP Concepts and relation - daft-burman-rtcweb-mmusic-media-structure MMUSIC II: Friday 0900-1100 0900 - 0905 Administrivia 0905 - 0925 Requirements (draft-jennings-mmusic-media-req) 0925 - 1015 PC-track to m-line mapping (draft-jennings-rtcweb-plan) 1015 - 1100 MSID changes to match multiplexing (draft-jennings-rtcweb-plan) --047d7b6dc0bcb147b304d6312431 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the tradition of the Interim, I tried to sit down and work out an
agenda that reflects that I think the important concerns are, name= ly:

- Video codecs (as promised)
- Multi= plexing of media flows
- Trickle ICE
- DataChannels

Two no= tes about cross-WG interaction:

- I'm assuming= that most of the MMUSIC time will be used for
=A0 RTCWEB-type st= uff, though I left 30 min for other MMUSIC
=A0 business on Tue.

- I don't know how m= uch time AVTEXT needs given the AVTEXT/
=A0 MMUSIC merger on Fri.= We can reduce the draft-jennings-rtcweb-plan
=A0 time accordingl= y based on agenda requests.

Hope this is useful. I'm of course happy to get on = a call to discuss
this if that helps.

-E= kr


RTCWEB I: Tuesday 0900-1130
0900 - 0905 =A0Administrivia
0905 - 1100 =A0Video Codec MTI = discussion
=A0 - draft-alvestrand-rtcweb-vp8-00 (30 mins)
=A0 - draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-= 00+draft-marjou-rtcweb-video-codec-00 (30 mins)
=A0 - General discussion 30 min)
=A0 - Call the question of = which mandatory to implement video codec to select (5 min)
=A0 - = Next steps (20 min)
=A01100 - 1115 =A0draft-ietf-rtcweb-use-cases= -and-requirements (LC comments)
=A01115 - 1130 =A0draft-ietf-draft-ietf-rtcweb-overview (LC comments)<= /div>
=A0 =A0=A0

MMUSIC I: Tuesday 1520-1830
1520 - 1525 =A0Administrivia
1525 - 1605 =A0Trickle ICE = (Ivov)
- Under what conditions can you do full trickle (discovery)
= - When can checking stop? [UPDATE vs. in-band vs...?]
- SDP/SIP e= ncoding for additional trickle candidates
1605 - 1650 =A0- Bundle= =A0
=A0- draft-ejzak-mmusic-bundle-alternatives (15 min)
=A0- dr= aft-ietf-mmusic-sdp-bundle-negotiation (15 min)
=A0- discussion/c= onsensus calls (15 min)
1650 - 1700 =A0[Break]
1700 - 1= 800 =A0SDP attribute analysis for multiplexing
=A0- draft-nandakumar-mmusic-sdp-mux-attributes
1800 - 1830 = =A0[Other MMUSIC business]


RTCWEB I= I: Thursday 0900-1130
0900 - 0905 =A0Administrivia
0905= - 1025 =A0Data Channel negotiation
=A0- draft-jesup-rtcweb-data-protocol (15 min)
=A0- draft-th= omson-rtcweb-data (15 min)
=A0- draft-marcon-rtcweb-data-channel-= management (15 min)
=A0- Discussion (30 min)
=A0- Conse= nsus call (5 min)
1025 - 1100 JSEP Update (Uberti)
=A0- draft-ietf-rtcweb-jsep=
1100 - 1115 =A0RTCP-XR (Westerlund)
1115 - 1130 =A0RTP= Concepts and relation
- daft-burman-rtcweb-mmusic-media-structur= e


MMUSIC II: Friday 0900-1100
09= 00 - 0905 =A0Administrivia
0905 - 0925 =A0Requirements (draft-jen= nings-mmusic-media-req)
0925 - 1015 =A0PC-track to m-line mapping= (draft-jennings-rtcweb-plan)
1015 - 1100 =A0MSID changes to match multiplexing (draft-jennings-rtcw= eb-plan)

--047d7b6dc0bcb147b304d6312431-- From eckelcu@cisco.com Wed Feb 20 21:42:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDFB21F8DB6 for ; Wed, 20 Feb 2013 21:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.591 X-Spam-Level: X-Spam-Status: No, score=-7.591 tagged_above=-999 required=5 tests=[AWL=3.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3SLcfw+Kxy2 for ; Wed, 20 Feb 2013 21:42:31 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0153221F8DAE for ; Wed, 20 Feb 2013 21:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5017; q=dns/txt; s=iport; t=1361425348; x=1362634948; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=otWUPKUDcgXf5/gR7Q6dHIdRECFdaCksbKvzhSU+HXY=; b=F8O2U8idUNCTxUm76Xlyw7HaL3HIAxyatiGRav84+rz0mx9F6+6F429F /1DX7EADTeOCHBZe+v3KpiOXqrFvRUL6WI+a1ik/ICqRH6gJ8/zw54RF9 pd2MBGlamMN570zG0DBCx3JZKigiNzUxsPINhQaBpKzXdwLFyB2WnFdEx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOayJVGtJV2a/2dsb2JhbABFwF2BBRZzgh8BAQEEAQEBNw0nFwQCAQgRBAEBCxQJBycLFAkIAQEEARIIiAoMsU+ONwSOXSYSBoJZYQOnB4MHgic X-IronPort-AV: E=Sophos;i="4.84,706,1355097600"; d="scan'208";a="179246669" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2013 05:42:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1L5gRcX030121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 05:42:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 23:42:27 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: Ac4OENvQrjUr6KWHTMaYkeb/AHwyXgB4TAVQ Date: Thu, 21 Feb 2013 05:42:26 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047BAA17@xmb-aln-x08.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:42:34 -0000 Hi Christer, I read the draft and I think it is a good step forward. I like the overall = approach and think it can work. I do have questions about some of the speci= fics, and also some suggested changes and additions. 1) In section 1, the 4th paragraph ends as follows: The port number value associated with the first "m=3D" line associated with the "BUNDLE" group represents the port value number offered to be used in the single 5-tuple. I think this is no longer necessary per the rules in section 6.1, and it sh= ould be removed. 2) Section 2 says the following about RTCP: Bundled media: Two or more RTP streams using a single 5-tuple. The RTCP streams associated with the RTP streams also use a single 5-tuple, which might be the same, but can also be different, as the one used by the RTP streams. This is contradicted by section 6.1, which says the SDP offer MUST o 5. Insert an SDP 'rtpc-mux' attribute. So one of these needs to be changed, and replace 'rtpc-mux' with 'rtcp-mux'= :) 3) OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate that "m=3D" lines must be grouped in the same way in the SDP Answer as they are grouped in the SDP Offer? I'd say yes, because otherwise you are not sure if something is wrong (e.g.= an intermediary has changed the ports, or something does not really unders= tand bundle). I think if the ports in the SDP answer are not grouped the sa= me as in the offer, it should be interpreted as a failure to bundle, and an= other offer should be sent to use different ports. 4) I do not understand the intent of the following text in section 6.2: However, if the "m=3D" lines associated with the "BUNDLE" group contain different port number values (i.e. the SDP Offer is generated until it is known whether the SDP Answerer supports the "BUNDLE" grouping extension) the SDP Offerer MUST NOT set the port number value of the first "m=3D" line associated with the "BUNDLE" group to zero. Perhaps there is a typo, but in any case, I do not think the first "m=3D" l= ines needs to be treated specially any more. This is similar to comment (1)= . 5) OPEN ISSUE #2: If the session has been established without BUNDLE, do we allow BUNDLE to be enabled later during the session? Yes, but need to use different ports until it is known that both offerer an= d answerer support bundle. 6) OPEN ISSUE #3: If the session has been established with BUNDLE, do we allow BUNDLE to be disabled later during the session, meaning that Yes, for failure recovery.=20 7) Section 6.3 ends as follows: Until the SDP Answerer receives the new SDP Offer, which contains an identical port number value for each "m=3D" line associated with a "BUNDLE" group, it MUST use the port, and related information (ICE candidates, SDES keys etc) associated with the first "m=3D" line in the "BUNDLE" group. I think the SDP Answerer needs to wait for the next offer and not assume th= e first "m=3D" line contains the port to be used for the bundle. 8) Section 10 The SDP Answer shows the same port being used in the "m=3D" lines. I was th= inking this first answer would use different ports, and only if there is an= other offer/answer exchange would both the offer and the answer switch to u= sing the same port. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Monday, February 18, 2013 11:50 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > negotiation-03 >=20 >=20 > Hi, >=20 > I've submitted a new version (-03) of BUNDLE. >=20 > Based on discussions with Cullen, and exchange of the concerns we had > with the different port alternatives (different-ports vs identical-port),= this > version now describes a mechanism where both alternatives more or less > are combined. When the first BUNDLE offer is sent, and it is now known > whether the answerer supports BUNDLE (or, even identical ports), differen= t > ports are used (read: the one-rtp alterntaive). Once BUNDLE answer has > been received, a new offer, with identical port numbers, is sent. >=20 > We think that having to send a second offer is not going to increase > complexity and delay, because in many use-cases subsequent offer(s) will > be sent anyway. For example, RTCWEB entities will do it because of ICE. >=20 > Cullen has also been added as co-author. >=20 > Now, we do realize that there are still issues that have to be described,= and > hopefully we will be able to focus on those from now on, but our wish is > that this proposal will unite the different "port camps" :) >=20 > Regards, >=20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Feb 20 23:10:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43C21F8DCD for ; Wed, 20 Feb 2013 23:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+siBN0UhYXT for ; Wed, 20 Feb 2013 23:10:06 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B1C8321F8DD4 for ; Wed, 20 Feb 2013 23:10:05 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-0a-5125c84c1ad6 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D9.B7.19728.C48C5215; Thu, 21 Feb 2013 08:10:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 08:10:04 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 - Charles' comments Thread-Index: Ac4QAnfKtcZYT/MbQ4exDfkvD+TtAw== Date: Thu, 21 Feb 2013 07:10:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FDB87@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvja7PCdVAg+dX1S02zfrCZjF1+WMW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSuje0pNwXLNiukr7rM2MC5X6GLk5JAQMJF4 8OE4I4QtJnHh3no2EFtI4BCjxN++wC5GLiB7MaPEgpXrWbsYOTjYBCwkuv9pg9SICERIvJy2 nQXEFhbIkjjcN40dIp4tcXndLEYIW09i06L1TCA2i4CqxNqZfewgY3gFvCVWP1IFCTMCrf1+ ag1YCbOAuMStJ/OZIM4RkFiy5zwzhC0q8fLxP1YIW1Hi6vTlUPU6Egt2f2KDsLUlli18DVbP KyAocXLmE5YJjMKzkIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9rECAzqg1t+q+5gvHNO5BCj NAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MBelxis+SD4WFsf6LnuV1/MhS PQltETdulgfa5uHVUl5sVlUfros+953PppPxt3K2da/kj/DTfsns3hc/Wuiu8A7NiL36cI+O //c1ZzIqfjNInfrRG/n8ZuBn2f+/H51pnZizfMZCtcB07piJPbce2Z4NKV12y/3EnMocs9M6 L5eHbJ63/Gu6EktxRqKhFnNRcSIAWOcyYDgCAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 - Charles' comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:10:07 -0000 Hi Charles, Thanks for your comments! Reply inline. >I read the draft and I think it is a good step forward. I like the overall= approach and think it can work. I do have questions about some of the spec= ifics, and also some suggested changes and additions. > >1) In section 1, the 4th paragraph ends as follows: > > The port number > value associated with the first "m=3D" line associated with the > "BUNDLE" group represents the port value number offered to be used in > the single 5-tuple. > >I think this is no longer necessary per the rules in section 6.1, and it s= hould be removed. The text talks about the Offer where different port numbers are used, ie wh= en it is still not known whether the Answerer supports bundle. But, maybe t= hat needs to be more clear. -------------------------- > 2) Section 2 says the following about RTCP: > > Bundled media: Two or more RTP streams using a single 5-tuple. The > RTCP streams associated with the RTP streams also use a single > 5-tuple, which might be the same, but can also be different, as the > one used by the RTP streams. > >This is contradicted by section 6.1, which says the SDP offer MUST > o 5. Insert an SDP 'rtpc-mux' attribute. > > So one of these needs to be changed, and replace 'rtpc-mux' with 'rtcp-mu= x' :) Correct. I got the same comment off-line from Harald, but forgot to fix it. Do people have any preference? Shall du usage of rtcp-mux be a SHOULD, a MU= ST, or a RECOMMEND? :) -------------------------- >3) OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate > that "m=3D" lines must be grouped in the same way in the SDP Answer as > they are grouped in the SDP Offer? > > I'd say yes, because otherwise you are not sure if something is wrong (e.= g. an intermediary has changed the ports, or something=20 > does not really understand bundle). I think if the ports in the SDP answe= r are not grouped the same as in the offer, it should be=20 > interpreted as a failure to bundle, and another offer should be sent to u= se different ports. I'm still thinking about it, but at least at this point I would agree with = you :) -------------------------- >4) I do not understand the intent of the following text in section 6.2: > > However, if the "m=3D" lines associated with the "BUNDLE" > group contain different port number values (i.e. the SDP Offer is > generated until it is known whether the SDP Answerer supports the > "BUNDLE" grouping extension) the SDP Offerer MUST NOT set the port > number value of the first "m=3D" line associated with the "BUNDLE" > group to zero. > > Perhaps there is a typo, but in any case, I do not think the first "m=3D"= lines needs to be treated specially any more. This is similar to comment (= 1). Keep in mind that, in this case, only the port of the first "m=3D" line rep= resents the bundle port (as different port values are given for the other m= =3D lines). -------------------------- >5) OPEN ISSUE #2: If the session has been established without BUNDLE, do > we allow BUNDLE to be enabled later during the session? > > Yes, but need to use different ports until it is known that both offerer = and answerer support bundle. Sure, that rule would still apply. -------------------------- >6) OPEN ISSUE #3: If the session has been established with BUNDLE, do we > allow BUNDLE to be disabled later during the session, meaning that > > Yes, for failure recovery.=20 I was more thinking of the case where endpoints already have successfully n= egotiated the usage of bundle, and then at some point during the session ch= ose (for whatever reason) to disable the multiplexing. Basically it would mean sending a new offer, without BUNDLE, and with diffe= rent port number values - ie a "legacy" offer :) -------------------------- >7) Section 6.3 ends as follows: > > Until the SDP Answerer receives the new SDP Offer, which contains an > identical port number value for each "m=3D" line associated with a > "BUNDLE" group, it MUST use the port, and related information (ICE > candidates, SDES keys etc) associated with the first "m=3D" line in the > "BUNDLE" group. > > I think the SDP Answerer needs to wait for the next offer and not assume = the first "m=3D" line contains the port to be used for the bundle. Is there a specific reason why you think that we can't mandate the Offerer = to insert the bundle port in the first "m=3D" line? -------------------------- >8) Section 10 > >The SDP Answer shows the same port being used in the "m=3D" lines. I was t= hinking this first answer would use different ports, and only if=20 >there is another offer/answer exchange would both the offer and the answer= switch to using the same port. My personal opinion is that the answerer already knows that the offerer wan= ts to use bundle, and is expected to send a new offer. Also, by using the s= ame ports already in the first answer, we would prevent a case where the an= swerer does NOT support bundle, but blindly copies the grouping attributes = from the offer to the answer. But, opinions are welcome :) Regards, Christer From christer.holmberg@ericsson.com Thu Feb 21 04:26:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D7C21F8CB2; Thu, 21 Feb 2013 04:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZYrKj2z-hQf; Thu, 21 Feb 2013 04:25:59 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C408E21F8C9E; Thu, 21 Feb 2013 04:25:58 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-cb-5126125564aa Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.29.32353.55216215; Thu, 21 Feb 2013 13:25:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:25:57 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHOD35vMbWFu2fEI0efKvWAcqBYapiDLdGQ Date: Thu, 21 Feb 2013 12:25:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvjW6okFqgQctqU4upyx+zWPQ2hFus /dfO7sDs0fpsL6vHkiU/mQKYorhsUlJzMstSi/TtErgyGg9+YinYYVrxb0o7cwPjfq0uRk4O CQETiVe/W9khbDGJC/fWs4HYQgKHGCXOrTWFsBczSjzpEeti5OBgE7CQ6P6n3cXIxSEi0M8o 0f1tMSNIjbBAmsTMSU1gvSIC6RKvLj6Aso0krkx9wQpiswioSqxZ9B2snlfAW2LXurlMIIOE BN4zSqz6NJ8JJMEpECuxcNM1sIMYgQ76fmoNWJxZQFzi1hOIGgkBAYkle84zQ9iiEi8f/2OF sBUlrk5fDlWvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzs uYmZOenl5psYgTFxcMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRIGzr8XWdfdYuhVnbmqZ5CIYt5b3VPe9sqO7fyJqzQupnwiw/rk5Rn15wzzRY1Nro zO857k7mLUUyZfcXse2+8nBfxSvpz93OV3Suv3Gc4i60P431oPsp5R8T3FcGFa+7o5eQkO81 SST79Zajn2efd176QT9tm/K2eW5vb2oo3zv+zv72evEnSizFGYmGWsxFxYkAljYaC1cCAAA= Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:26:00 -0000 Hi, >> First, as you will now have a single non-zero m- line, you still assume >> that entities (including intermediaries) will take information (media >> types, payload type mappings etc etc etc - even protocol, if we decide >> to also allow the data channel in the bundle) from all m- lines. Or, do >> you intend to put all that information into a single m- line? If so, in >> my opinion MMT is a much better approach. > > The intent is to reuse all of the existing information in the subsequent = m lines except the connection, candidate and non-zero port information. Th= at excludes the crypto info as well. And how do you expect intermediaries to understand that, when the ports are= zero? And, even if we don't consider intermediaries, I think it's BAD DESIGN to a= ssume that we use a stream, and associated data, from m- lines with port ze= ro. Port zero means that the stream associated with the m- line is DISABLED= . >> Second, what if a user wants the disable, or reject, a specific stream, >> using port zero? How is it done in case the stream is already >> represented by a zero m- line? How is it done in case the stream is >> represented by the non-zero m- line which contains the port number >> value used for the whole bundle? > > A zero port value would retain its original semantic of disabling/rejecti= ng an individual m line. In my proposal all subsequent m lines in the SDP = answer that are accepted=20 >would have valid and unique non-zero port values that are different from t= he port value in the first m line of the bundle group. >I admit that I did not think through how to disable the first m line in th= e group, but let me propose the following: > >Let's specify that we get the connection and port information for the bund= le from the first valid (non-zero port) m line=20 >in the bundle group of the SDP answer (not offer). If the answerer wants = to disable the first valid m line(s) of the bundle=20 >group in the first SDP offer, both ends use the connection and port inform= ation from the next valid m line in the SDP=20 >answer (and its corresponding m line in the SDP offer). The offerer had v= alid information for each m line in the SDP=20 >offer so it doesn't matter which set we use after the first offer/answer t= ransaction. But we don't want to=20 >change the 5-tuple or crypto info for the bundle with any subsequent offer= /answer. > >If the offerer wants to disable the first valid m line(s) of a bundle grou= p in a subsequent offer, it places the=20 >connection and port information for the bundle group in the next valid m l= ine of the bundle group in the SDP=20 >offer (it would actually move this information from the previous first val= id m line to the new one to avoid=20 >restarting crypto or changing ports). >In response to the new offer disabling the initial valid m line(s), the an= swerer similarly places the connection and=20 >port information for the bundle group in the corresponding m line of the S= DP answer. =20 I think that's very hacky, moving information from one m- line to another..= . >The answerer is not allowed to disable the first valid m line of a bundle = group in the SDP answer it sends in response=20 >to a subsequent offer. If the answerer needs to disable the first valid m = line(s), it must instead accept the m line(s) in=20 >response to the latest pending offer (if there is one) and immediately sen= d a new SDP offer disabling the line by following=20 >the SDP offerer rule above. I don't think we should have a solution where the answerer is not allowed t= o reject an m- line. >The only other rule to add is that the SDP offerer will never re-enable (s= et port to a non-zero value) a disabled m line=20 >before the first valid m line in a bundle group but will instead create a = new m line and add it to the group. This makes=20 >it unlikely that the answerer will reject the first valid m line of the bu= ndle group in a subsequent SDP offer since it had=20 >previously accepted it and did not initiate the new transaction due to any= changes in the configuration of local resources. What if you have a session where a stream is enabled/disabled many times. I= f, every time you re-enable, is going to add a new m- line, you may end up = with a very large SDP... >This isn't particularly elegant, but it applies the definition consistentl= y and I think it works in all cases. I think it's very hacky, and I don't see how you think that intermediaries = (which your draft focues on) would be able to handle this... Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ejzak, Richard P (Richard) > Sent: 19. helmikuuta 2013 0:09 > To: mmusic@ietf.org; rtcweb@ietf.org > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic- > bundle-alternatives-00.txt > > Please note that I have also submitted a draft on how to fix BUNDLE. > This doc is based on the modified BUNDLE proposal with different port > information for each m line and compares several different additional > modifications to BUNDLE. The doc ends up recommending the use of the > unspecified address for subsequent m lines in a bundle group in the SDP > answer (not offer). Please see the doc for details. > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, February 18, 2013 3:57 PM > To: Ejzak, Richard P (Richard) > Subject: New Version Notification for draft-ejzak-mmusic-bundle- > alternatives-00.txt > > > A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt > has been successfully submitted by Richard Ejzak and posted to the IETF > repository. > > Filename: draft-ejzak-mmusic-bundle-alternatives > Revision: 00 > Title: Alternatives to BUNDLE > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-ejzak- > mmusic-bundle-alternatives-00.txt > Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic- > bundle-alternatives > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-bundle- > alternatives-00 > > > Abstract: > This paper discusses some potential modifications to the BUNDLE > proposal for multiplexing of multiple media types within a single > 5-tuple to address limitations of the current proposal and > alternatives already considered by MMUSIC. > > > > > The IETF Secretariat > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Thu Feb 21 05:04:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51C21F8D0D for ; Thu, 21 Feb 2013 05:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.244 X-Spam-Level: X-Spam-Status: No, score=-9.244 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6q+WNDgDles for ; Thu, 21 Feb 2013 05:04:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D612021F8CB2 for ; Thu, 21 Feb 2013 05:04:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1231; q=dns/txt; s=iport; t=1361451896; x=1362661496; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hJIUoy1xTfc0rjT9gG1DI7MdAOidbWn3NRxkO8RxxL4=; b=F0DhzqiH+vr4x/aYrIFNGMUuMZJpti5F+u6iHLxaBuG5jFQLJ+I//jE1 /+68XOhwwLHgv/ArducX8oamvoPSUtKdnnU6eATtJrpoGF5RyT0D62usy vsMCZOlrYuA0nOUNE1HGGWKgBap44ReLGTsDrQg9RP9sGi1ImXbfbgf52 U=; X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; d="scan'208";a="179649100" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2013 13:04:55 +0000 Received: from rtp-fandreas-8718.cisco.com (rtp-fandreas-8718.cisco.com [10.117.7.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1LD4sP8026265; Thu, 21 Feb 2013 13:04:54 GMT Message-ID: <51261B76.30902@cisco.com> Date: Thu, 21 Feb 2013 08:04:54 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic References: <5119A3DB.6000703@cisco.com> In-Reply-To: <5119A3DB.6000703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Ari Keranen Subject: [MMUSIC] Reminder [Re: MMUSIC agenda requests for IETF 86] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 13:04:56 -0000 Dead-line for agenda requests will be this Sunday, February 24. If you have not submitted an agenda request yet but have a draft you would like to discuss, please submit your request to the chairs with an indication of - The draft you would like to discuss - The major open issues you want to discuss Again, priority will be given to active drafts that require discussion of open issues in the WG. General status updates of drafts can be handled by the chairs. Thanks -- Ari & Flemming On 2/11/13 9:07 PM, Flemming Andreasen wrote: > MMUSIC is currently scheduled to meet for a total of 4 hours at IETF > 86 in Orlando, Florida. > > If you want to request a time slot to discuss a draft, please send an > e-mail to the chairs. > > As usual, we want to ensure we take advantage of our meeting time in a > productive manner that leads to forward progress. This means that we > want presenters to come prepared to discuss open issues that have > already been raised on the mailing list and ideally received some > feedback already. Priority will be given drafts that gather attention > and discussion in the mailing list prior to the meeting. > > Thanks > > -- Ari and Flemming > . > From richard.ejzak@alcatel-lucent.com Thu Feb 21 06:06:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DAD21F8AB6; Thu, 21 Feb 2013 06:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.055 X-Spam-Level: X-Spam-Status: No, score=-9.055 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9if3yheRM5mO; Thu, 21 Feb 2013 06:06:26 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3017321F8ABC; Thu, 21 Feb 2013 06:06:26 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1LE4fvW003127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Feb 2013 15:06:23 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Feb 2013 15:05:15 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 21 Feb 2013 09:05:13 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHOD2W+toYseWtIxEKEwtE+xBCEiZiCxbWggAHMggD//8Z4EA== Date: Thu, 21 Feb 2013 14:05:12 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:06:27 -0000 Hi Christer, My proposal never has a zero port on a valid m line, in either offer or ans= wer. I only use unspecified address (with valid port number) for subsequen= t m lines in answers. I'm not sure how you got this from the description. = Let's discuss this on the call today. I hope you are available. Richard > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, February 21, 2013 6:26 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org; rtcweb@ietf.org > Subject: RE: [MMUSIC] FW: New Version Notification for draft-ejzak- > mmusic-bundle-alternatives-00.txt >=20 >=20 > Hi, >=20 > >> First, as you will now have a single non-zero m- line, you still > >> assume that entities (including intermediaries) will take > information > >> (media types, payload type mappings etc etc etc - even protocol, if > >> we decide to also allow the data channel in the bundle) from all m- > >> lines. Or, do you intend to put all that information into a single > m- > >> line? If so, in my opinion MMT is a much better approach. > > > > The intent is to reuse all of the existing information in the > subsequent m lines except the connection, candidate and non-zero port > information. That excludes the crypto info as well. >=20 > And how do you expect intermediaries to understand that, when the ports > are zero? >=20 > And, even if we don't consider intermediaries, I think it's BAD DESIGN > to assume that we use a stream, and associated data, from m- lines with > port zero. Port zero means that the stream associated with the m- line > is DISABLED. >=20 > >> Second, what if a user wants the disable, or reject, a specific > >> stream, using port zero? How is it done in case the stream is > already > >> represented by a zero m- line? How is it done in case the stream is > >> represented by the non-zero m- line which contains the port number > >> value used for the whole bundle? > > > > A zero port value would retain its original semantic of > >disabling/rejecting an individual m line. In my proposal all > subsequent m lines in the SDP answer that are accepted would have valid > and unique non-zero port values that are different from the port value > in the first m line of the bundle group. >=20 > >I admit that I did not think through how to disable the first m line > in the group, but let me propose the following: > > > >Let's specify that we get the connection and port information for the > >bundle from the first valid (non-zero port) m line in the bundle group > >of the SDP answer (not offer). If the answerer wants to disable the > >first valid m line(s) of the bundle group in the first SDP offer, both > >ends use the connection and port information from the next valid m > line > >in the SDP answer (and its corresponding m line in the SDP offer). > The offerer had valid information for each m line in the SDP offer so > it doesn't matter which set we use after the first offer/answer > transaction. But we don't want to change the 5-tuple or crypto info > for the bundle with any subsequent offer/answer. > > > >If the offerer wants to disable the first valid m line(s) of a bundle > >group in a subsequent offer, it places the connection and port > >information for the bundle group in the next valid m line of the > bundle > >group in the SDP offer (it would actually move this information from > the previous first valid m line to the new one to avoid restarting > crypto or changing ports). > >In response to the new offer disabling the initial valid m line(s), > the > >answerer similarly places the connection and port information for the > bundle group in the corresponding m line of the SDP answer. >=20 > I think that's very hacky, moving information from one m- line to > another... >=20 > >The answerer is not allowed to disable the first valid m line of a > >bundle group in the SDP answer it sends in response to a subsequent > >offer. If the answerer needs to disable the first valid m line(s), it > >must instead accept the m line(s) in response to the latest pending > offer (if there is one) and immediately send a new SDP offer disabling > the line by following the SDP offerer rule above. >=20 > I don't think we should have a solution where the answerer is not > allowed to reject an m- line. >=20 > >The only other rule to add is that the SDP offerer will never re- > enable > >(set port to a non-zero value) a disabled m line before the first > valid > >m line in a bundle group but will instead create a new m line and add > >it to the group. This makes it unlikely that the answerer will reject > the first valid m line of the bundle group in a subsequent SDP offer > since it had previously accepted it and did not initiate the new > transaction due to any changes in the configuration of local resources. >=20 > What if you have a session where a stream is enabled/disabled many > times. If, every time you re-enable, is going to add a new m- line, you > may end up with a very large SDP... >=20 > >This isn't particularly elegant, but it applies the definition > consistently and I think it works in all cases. >=20 > I think it's very hacky, and I don't see how you think that > intermediaries (which your draft focues on) would be able to handle > this... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Ejzak, Richard P (Richard) > > Sent: 19. helmikuuta 2013 0:09 > > To: mmusic@ietf.org; rtcweb@ietf.org > > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak- > mmusic- > > bundle-alternatives-00.txt > > > > Please note that I have also submitted a draft on how to fix BUNDLE. > > This doc is based on the modified BUNDLE proposal with different port > > information for each m line and compares several different additional > > modifications to BUNDLE. The doc ends up recommending the use of the > > unspecified address for subsequent m lines in a bundle group in the > > SDP answer (not offer). Please see the doc for details. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, February 18, 2013 3:57 PM > > To: Ejzak, Richard P (Richard) > > Subject: New Version Notification for draft-ejzak-mmusic-bundle- > > alternatives-00.txt > > > > > > A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt > > has been successfully submitted by Richard Ejzak and posted to the > > IETF repository. > > > > Filename: draft-ejzak-mmusic-bundle-alternatives > > Revision: 00 > > Title: Alternatives to BUNDLE > > Creation date: 2013-02-18 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-ejzak- > > mmusic-bundle-alternatives-00.txt > > Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic- > > bundle-alternatives > > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic- > bundle- > > alternatives-00 > > > > > > Abstract: > > This paper discusses some potential modifications to the BUNDLE > > proposal for multiplexing of multiple media types within a single > > 5-tuple to address limitations of the current proposal and > > alternatives already considered by MMUSIC. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Thu Feb 21 06:13:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701C221F8A6C; Thu, 21 Feb 2013 06:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rc5QCcua3Vi; Thu, 21 Feb 2013 06:13:30 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 304AA21F8461; Thu, 21 Feb 2013 06:13:25 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-49-51262b8373ac Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 46.8E.10459.38B26215; Thu, 21 Feb 2013 15:13:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 15:13:23 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHOD35vMbWFu2fEI0efKvWAcqBYapiDLdGQgAEbXACAABGpQA== Date: Thu, 21 Feb 2013 14:13:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvjW6ztlqgwZx5lhZTlz9msehtCLdY +6+d3YHZo/XZXlaPJUt+MgUwRXHZpKTmZJalFunbJXBlPFuzgrHgkGPFj3V/GRsYPxp3MXJy SAiYSGw4tIEdwhaTuHBvPVsXIxeHkMAhRomO9l4oZzGjxP72C0BVHBxsAhYS3f+0QeIiAv2M Et3fFjOCdAsLpEnMnNTEBmKLCKRLvLr4AMp2kuibcAKshkVAVeLWoiawbbwC3hLbNnWyQixo YZZ4e+EzWBGnQKzEy5sHmUBsRqCTvp9aA2YzC4hL3HoynwniVAGJJXvOM0PYohIvH/9jhbAV Ja5OXw5VryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJ mTnp5YabGIFxcXDLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBsXL28dKqCeyblpq2XzolOKlg4hKXBY8YTdxr/kp/Pqknsko19UCDNaPgLNV5T7hefWZ8 KMk+rbvmWP+lv7lq9lYa+R2rVhd5z2RlFJhXdqz1X87xyLi3zPvqktwjfv5av03KSY9lyxMb KwE5/x/6ZyYfKE6InnyFfa5jvLibSg538ronFisFlViKMxINtZiLihMBIB7cYlkCAAA= Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:13:31 -0000 Hi, >My proposal never has a zero port on a valid m line, in either offer or an= swer. I only use unspecified address (with valid port number) for subseque= nt m lines in answers. I'm not sure how you got this from the description.= Let's discuss=20 >this on the call today. I hope you are available. Sorry, I mixed up terminology. But, still, if you want to disable/reject the m- line which contains the bu= ndle ADDRESS, you will have to move the address to another m- line. And, still, you expect intermediaries to retrieve media types, protocols, p= ayload types etc from the m- lines, which addresses are unspecified - but a= t the same time you say that no resources will be reserved for the m- lines= with unspecified addresses... Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, February 21, 2013 6:26 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org; rtcweb@ietf.org > Subject: RE: [MMUSIC] FW: New Version Notification for draft-ejzak-=20 > mmusic-bundle-alternatives-00.txt >=20 >=20 > Hi, >=20 > >> First, as you will now have a single non-zero m- line, you still=20 > >> assume that entities (including intermediaries) will take > information > >> (media types, payload type mappings etc etc etc - even protocol, if=20 > >> we decide to also allow the data channel in the bundle) from all m-=20 > >> lines. Or, do you intend to put all that information into a single > m- > >> line? If so, in my opinion MMT is a much better approach. > > > > The intent is to reuse all of the existing information in the > subsequent m lines except the connection, candidate and non-zero port=20 > information. That excludes the crypto info as well. >=20 > And how do you expect intermediaries to understand that, when the=20 > ports are zero? >=20 > And, even if we don't consider intermediaries, I think it's BAD DESIGN=20 > to assume that we use a stream, and associated data, from m- lines=20 > with port zero. Port zero means that the stream associated with the m-=20 > line is DISABLED. >=20 > >> Second, what if a user wants the disable, or reject, a specific=20 > >> stream, using port zero? How is it done in case the stream is > already > >> represented by a zero m- line? How is it done in case the stream is=20 > >> represented by the non-zero m- line which contains the port number=20 > >> value used for the whole bundle? > > > > A zero port value would retain its original semantic of=20 > >disabling/rejecting an individual m line. In my proposal all > subsequent m lines in the SDP answer that are accepted would have=20 > valid and unique non-zero port values that are different from the port=20 > value in the first m line of the bundle group. >=20 > >I admit that I did not think through how to disable the first m line > in the group, but let me propose the following: > > > >Let's specify that we get the connection and port information for the=20 > >bundle from the first valid (non-zero port) m line in the bundle=20 > >group of the SDP answer (not offer). If the answerer wants to=20 > >disable the first valid m line(s) of the bundle group in the first=20 > >SDP offer, both ends use the connection and port information from the=20 > >next valid m > line > >in the SDP answer (and its corresponding m line in the SDP offer). > The offerer had valid information for each m line in the SDP offer so=20 > it doesn't matter which set we use after the first offer/answer=20 > transaction. But we don't want to change the 5-tuple or crypto info=20 > for the bundle with any subsequent offer/answer. > > > >If the offerer wants to disable the first valid m line(s) of a bundle=20 > >group in a subsequent offer, it places the connection and port=20 > >information for the bundle group in the next valid m line of the > bundle > >group in the SDP offer (it would actually move this information from > the previous first valid m line to the new one to avoid restarting=20 > crypto or changing ports). > >In response to the new offer disabling the initial valid m line(s), > the > >answerer similarly places the connection and port information for the > bundle group in the corresponding m line of the SDP answer. >=20 > I think that's very hacky, moving information from one m- line to=20 > another... >=20 > >The answerer is not allowed to disable the first valid m line of a=20 > >bundle group in the SDP answer it sends in response to a subsequent=20 > >offer. If the answerer needs to disable the first valid m line(s), it=20 > >must instead accept the m line(s) in response to the latest pending > offer (if there is one) and immediately send a new SDP offer disabling=20 > the line by following the SDP offerer rule above. >=20 > I don't think we should have a solution where the answerer is not=20 > allowed to reject an m- line. >=20 > >The only other rule to add is that the SDP offerer will never re- > enable > >(set port to a non-zero value) a disabled m line before the first > valid > >m line in a bundle group but will instead create a new m line and add=20 > >it to the group. This makes it unlikely that the answerer will=20 > >reject > the first valid m line of the bundle group in a subsequent SDP offer=20 > since it had previously accepted it and did not initiate the new=20 > transaction due to any changes in the configuration of local resources. >=20 > What if you have a session where a stream is enabled/disabled many=20 > times. If, every time you re-enable, is going to add a new m- line,=20 > you may end up with a very large SDP... >=20 > >This isn't particularly elegant, but it applies the definition > consistently and I think it works in all cases. >=20 > I think it's very hacky, and I don't see how you think that=20 > intermediaries (which your draft focues on) would be able to handle=20 > this... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > Behalf Of Ejzak, Richard P (Richard) > > Sent: 19. helmikuuta 2013 0:09 > > To: mmusic@ietf.org; rtcweb@ietf.org > > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak- > mmusic- > > bundle-alternatives-00.txt > > > > Please note that I have also submitted a draft on how to fix BUNDLE. > > This doc is based on the modified BUNDLE proposal with different=20 > > port information for each m line and compares several different=20 > > additional modifications to BUNDLE. The doc ends up recommending=20 > > the use of the unspecified address for subsequent m lines in a=20 > > bundle group in the SDP answer (not offer). Please see the doc for det= ails. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, February 18, 2013 3:57 PM > > To: Ejzak, Richard P (Richard) > > Subject: New Version Notification for draft-ejzak-mmusic-bundle-=20 > > alternatives-00.txt > > > > > > A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt > > has been successfully submitted by Richard Ejzak and posted to the=20 > > IETF repository. > > > > Filename: draft-ejzak-mmusic-bundle-alternatives > > Revision: 00 > > Title: Alternatives to BUNDLE > > Creation date: 2013-02-18 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-ejzak- > > mmusic-bundle-alternatives-00.txt > > Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic- > > bundle-alternatives > > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic- > bundle- > > alternatives-00 > > > > > > Abstract: > > This paper discusses some potential modifications to the BUNDLE > > proposal for multiplexing of multiple media types within a single > > 5-tuple to address limitations of the current proposal and > > alternatives already considered by MMUSIC. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Thu Feb 21 06:52:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68C21F8E05; Thu, 21 Feb 2013 06:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.242 X-Spam-Level: X-Spam-Status: No, score=-9.242 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3BADaVgmc9C; Thu, 21 Feb 2013 06:52:45 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id F200821F8DE4; Thu, 21 Feb 2013 06:52:44 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1LEpo3b021684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Feb 2013 15:52:32 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Feb 2013 15:52:02 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 21 Feb 2013 09:51:59 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt Thread-Index: AQHOD2W+toYseWtIxEKEwtE+xBCEiZiCxbWggAHMggD//8Z4EIAAV40A//+xRqA= Date: Thu, 21 Feb 2013 14:51:58 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:52:46 -0000 Hi Christer, Please see below. Richard > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >My proposal never has a zero port on a valid m line, in either offer > or > >answer. I only use unspecified address (with valid port number) for > subsequent m lines in answers. I'm not sure how you got this from the > description. Let's discuss this on the call today. I hope you are > available. >=20 > Sorry, I mixed up terminology. >=20 > But, still, if you want to disable/reject the m- line which contains > the bundle ADDRESS, you will have to move the address to another m- > line. Yes. As long as there is a simple rule for doing so I don't see a problem. >=20 > And, still, you expect intermediaries to retrieve media types, > protocols, payload types etc from the m- lines, which addresses are > unspecified - but at the same time you say that no resources will be > reserved for the m- lines with unspecified addresses... Intermediaries forwarding BUNDLE information have to understand SOMETHING a= bout BUNDLE or they have no business forwarding it in the first place. It'= s only in this case that the intermediary might need to use m lines with un= specified address to identity additional bandwidth requirements. I meant t= hat -port- resources could be released in this case. I should have been mo= re careful in describing this point. Sending a subsequent offer with the same port in all bundled m lines has it= s own problems in 3pcc scenarios. You should always send an offer that can= pass through intermediaries that do not understand BUNDLE. My proposal ha= s that characteristic but I'm not sure that yours does. >=20 > Regards, >=20 > Christer From harald@alvestrand.no Thu Feb 21 06:59:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84521F85C0 for ; Thu, 21 Feb 2013 06:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.29 X-Spam-Level: X-Spam-Status: No, score=-110.29 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaDS58rkt4hK for ; Thu, 21 Feb 2013 06:59:51 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D32C621F8E07 for ; Thu, 21 Feb 2013 06:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD47939E0D2 for ; Thu, 21 Feb 2013 15:59:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VHnJjYfKiMY for ; Thu, 21 Feb 2013 15:59:47 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1043739E0A7 for ; Thu, 21 Feb 2013 15:59:46 +0100 (CET) Message-ID: <51263661.3060307@alvestrand.no> Date: Thu, 21 Feb 2013 15:59:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:59:58 -0000 On 02/21/2013 03:51 PM, Ejzak, Richard P (Richard) wrote: > Sending a subsequent offer with the same port in all bundled m lines > has its own problems in 3pcc scenarios. You should always send an > offer that can pass through intermediaries that do not understand > BUNDLE. My proposal has that characteristic but I'm not sure that > yours does. Designing around intermediaries that pass along information that they do not understand, and then expect to act independently based on the message that they partially understood, seems to me to be a quite limiting approach. We discussed this at the interim (I think Cullen was pretty vocal that there's a limit to how much brokenness we can design around, and he thought intermediaries passing BUNDLE without understanding BUNDLE were clearly beyond that limit). (Cullen, apologies if I misstate what you said). From suhasietf@gmail.com Wed Feb 20 16:53:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4033D21F8703; Wed, 20 Feb 2013 16:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usXUVyUpH+fm; Wed, 20 Feb 2013 16:53:29 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC9DB21F86E7; Wed, 20 Feb 2013 16:53:28 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so6787965wgd.4 for ; Wed, 20 Feb 2013 16:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TcRFn7X5MSpfa734lqgj/VeAuk3b5e3m17imDedIsiM=; b=Ga9+ebzSghrYcw4YfI+ihcdKMjtlKMxO78MI7rrO/ghmoE/q7XNnd5j70QiEXHrnHK NnQ3LTQqCFoZh8JxODQreDFa44WWuMHG5LbHrn3Ty9kTeCQkyvIcXbaAdz2MIs4raNVb U8a0UsA+PkiGXLIF+tG+B/+ftsWT7EO2m9rsNon/2xcLcxrWxjlWPTeT25SgJp6OxA51 csiZ+AWLjlsNwK9a22wwCfaWcsYiQWOZyoAuf8xhpb7fmU2L1/YbMlJUHUduc3cGKukC LSBBa3w76E/st4HXpQA8WvZLXR6K00sIfYMUEyllc+Q9xPiFHpfh0wAkCifM3kFN9ftb qrgA== MIME-Version: 1.0 X-Received: by 10.194.59.40 with SMTP id w8mr37287835wjq.51.1361408007639; Wed, 20 Feb 2013 16:53:27 -0800 (PST) Received: by 10.194.44.99 with HTTP; Wed, 20 Feb 2013 16:53:27 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 16:53:27 -0800 Message-ID: From: Suhas Nandakumar To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b86d68cb0cd2204d631801d X-Mailman-Approved-At: Thu, 21 Feb 2013 08:07:10 -0800 Cc: rtcweb@ietf.org, mmusic WG Subject: Re: [MMUSIC] [rtcweb] Proposed Agenda For WG Meetings X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:53:30 -0000 --047d7b86d68cb0cd2204d631801d Content-Type: text/plain; charset=ISO-8859-1 +1 Looks Neat !! ./Suhas On Wed, Feb 20, 2013 at 4:27 PM, Eric Rescorla wrote: > In the tradition of the Interim, I tried to sit down and work out an > agenda that reflects that I think the important concerns are, namely: > > - Video codecs (as promised) > - Multiplexing of media flows > - Trickle ICE > - DataChannels > > Two notes about cross-WG interaction: > > - I'm assuming that most of the MMUSIC time will be used for > RTCWEB-type stuff, though I left 30 min for other MMUSIC > business on Tue. > > - I don't know how much time AVTEXT needs given the AVTEXT/ > MMUSIC merger on Fri. We can reduce the draft-jennings-rtcweb-plan > time accordingly based on agenda requests. > > Hope this is useful. I'm of course happy to get on a call to discuss > this if that helps. > > -Ekr > > > RTCWEB I: Tuesday 0900-1130 > 0900 - 0905 Administrivia > 0905 - 1100 Video Codec MTI discussion > - draft-alvestrand-rtcweb-vp8-00 (30 mins) > - > draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-00+draft-marjou-rtcweb-video-codec-00 > (30 mins) > - General discussion 30 min) > - Call the question of which mandatory to implement video codec to > select (5 min) > - Next steps (20 min) > 1100 - 1115 draft-ietf-rtcweb-use-cases-and-requirements (LC comments) > 1115 - 1130 draft-ietf-draft-ietf-rtcweb-overview (LC comments) > > > MMUSIC I: Tuesday 1520-1830 > 1520 - 1525 Administrivia > 1525 - 1605 Trickle ICE (Ivov) > - Under what conditions can you do full trickle (discovery) > - When can checking stop? [UPDATE vs. in-band vs...?] > - SDP/SIP encoding for additional trickle candidates > 1605 - 1650 - Bundle > - draft-ejzak-mmusic-bundle-alternatives (15 min) > - draft-ietf-mmusic-sdp-bundle-negotiation (15 min) > - discussion/consensus calls (15 min) > 1650 - 1700 [Break] > 1700 - 1800 SDP attribute analysis for multiplexing > - draft-nandakumar-mmusic-sdp-mux-attributes > 1800 - 1830 [Other MMUSIC business] > > > RTCWEB II: Thursday 0900-1130 > 0900 - 0905 Administrivia > 0905 - 1025 Data Channel negotiation > - draft-jesup-rtcweb-data-protocol (15 min) > - draft-thomson-rtcweb-data (15 min) > - draft-marcon-rtcweb-data-channel-management (15 min) > - Discussion (30 min) > - Consensus call (5 min) > 1025 - 1100 JSEP Update (Uberti) > - draft-ietf-rtcweb-jsep > 1100 - 1115 RTCP-XR (Westerlund) > 1115 - 1130 RTP Concepts and relation > - daft-burman-rtcweb-mmusic-media-structure > > > MMUSIC II: Friday 0900-1100 > 0900 - 0905 Administrivia > 0905 - 0925 Requirements (draft-jennings-mmusic-media-req) > 0925 - 1015 PC-track to m-line mapping (draft-jennings-rtcweb-plan) > 1015 - 1100 MSID changes to match multiplexing > (draft-jennings-rtcweb-plan) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b86d68cb0cd2204d631801d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Looks Neat !!

./Suhas

O= n Wed, Feb 20, 2013 at 4:27 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
In the tradition of the Interim, I trie= d to sit down and work out an
agenda that reflects that I think t= he important concerns are, namely:

- Video codecs (as promised)
- Multiplexing o= f media flows
- Trickle ICE
- DataChannels

Two no= tes about cross-WG interaction:

- I'm assuming= that most of the MMUSIC time will be used for
=A0 RTCWEB-type st= uff, though I left 30 min for other MMUSIC
=A0 business on Tue.

- I don't know how m= uch time AVTEXT needs given the AVTEXT/
=A0 MMUSIC merger on Fri.= We can reduce the draft-jennings-rtcweb-plan
=A0 time accordingl= y based on agenda requests.

Hope this is useful. I'm of course happy to get on = a call to discuss
this if that helps.

-E= kr


RTCWEB I: Tuesday 0900-1130
0900 - 0905 =A0Administrivia
0905 - 1100 =A0Video Codec MTI = discussion
=A0 - draft-alvestrand-rtcweb-vp8-00 (30 mins)
=A0 - draft-burman-rtcweb-h264-proposal-00+draft-dbenham-webrtcvideomti-= 00+draft-marjou-rtcweb-video-codec-00 (30 mins)
=A0 - General discussion 30 min)
=A0 - Call the question of = which mandatory to implement video codec to select (5 min)
=A0 - = Next steps (20 min)
=A01100 - 1115 =A0draft-ietf-rtcweb-use-cases= -and-requirements (LC comments)
=A01115 - 1130 =A0draft-ietf-draft-ietf-rtcweb-overview (LC comments)<= /div>
=A0 =A0=A0

MMUSIC I: Tuesday 1520-1830
1520 - 1525 =A0Administrivia
1525 - 1605 =A0Trickle ICE = (Ivov)
- Under what conditions can you do full trickle (discovery)
= - When can checking stop? [UPDATE vs. in-band vs...?]
- SDP/SIP e= ncoding for additional trickle candidates
1605 - 1650 =A0- Bundle= =A0
=A0- draft-ejzak-mmusic-bundle-alternatives (15 min)
=A0- dr= aft-ietf-mmusic-sdp-bundle-negotiation (15 min)
=A0- discussion/c= onsensus calls (15 min)
1650 - 1700 =A0[Break]
1700 - 1= 800 =A0SDP attribute analysis for multiplexing
=A0- draft-nandakumar-mmusic-sdp-mux-attributes
1800 - 1830 = =A0[Other MMUSIC business]


RTCWEB I= I: Thursday 0900-1130
0900 - 0905 =A0Administrivia
0905= - 1025 =A0Data Channel negotiation
=A0- draft-jesup-rtcweb-data-protocol (15 min)
=A0- draft-th= omson-rtcweb-data (15 min)
=A0- draft-marcon-rtcweb-data-channel-= management (15 min)
=A0- Discussion (30 min)
=A0- Conse= nsus call (5 min)
1025 - 1100 JSEP Update (Uberti)
=A0- draft-ietf-rtcweb-jsep=
1100 - 1115 =A0RTCP-XR (Westerlund)
1115 - 1130 =A0RTP= Concepts and relation
- daft-burman-rtcweb-mmusic-media-structur= e


MMUSIC II: Friday 0900-1100
09= 00 - 0905 =A0Administrivia
0905 - 0925 =A0Requirements (draft-jen= nings-mmusic-media-req)
0925 - 1015 =A0PC-track to m-line mapping= (draft-jennings-rtcweb-plan)
1015 - 1100 =A0MSID changes to match multiplexing (draft-jennings-rtcw= eb-plan)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b86d68cb0cd2204d631801d-- From richard.ejzak@alcatel-lucent.com Thu Feb 21 09:39:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993D921F87CD for ; Thu, 21 Feb 2013 09:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.367 X-Spam-Level: X-Spam-Status: No, score=-9.367 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h80fe2LaMlJG for ; Thu, 21 Feb 2013 09:39:10 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CE0E221F8E97 for ; Thu, 21 Feb 2013 09:39:09 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1LHd1dw000352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Feb 2013 18:39:06 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Feb 2013 18:39:04 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 21 Feb 2013 12:39:02 -0500 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) Thread-Index: AQHOEEQk5dAw9HDOIE68f+nShlOa4piEkZrA Date: Thu, 21 Feb 2013 17:39:01 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6DB3@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> <51263661.3060307@alvestrand.no> In-Reply-To: <51263661.3060307@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:39:10 -0000 Hi Harald, I did not mean that an intermediary should forward attributes it doesn't un= derstand but that an intermediary should be able to deal with any SDP it re= ceives. If some intermediaries choke on having the same port in multiple m= lines then we should avoid doing that, even during subsequent offers since= there are multiple 3pcc scenarios where subsequent offers can flow through= different intermediaries. We had a lot of discussion of this and other aspects during the call today.= We have more work to do before Orlando. Richard > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Thursday, February 21, 2013 9:00 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Requiring support for nonconformant intermediate > systems (Re: FW: New Version Notification for draft-ejzak-mmusic- > bundle-alternatives-00.txt) >=20 > On 02/21/2013 03:51 PM, Ejzak, Richard P (Richard) wrote: > > Sending a subsequent offer with the same port in all bundled m lines > > has its own problems in 3pcc scenarios. You should always send an > > offer that can pass through intermediaries that do not understand > > BUNDLE. My proposal has that characteristic but I'm not sure that > > yours does. > Designing around intermediaries that pass along information that they > do not understand, and then expect to act independently based on the > message that they partially understood, seems to me to be a quite > limiting approach. >=20 > We discussed this at the interim (I think Cullen was pretty vocal that > there's a limit to how much brokenness we can design around, and he > thought intermediaries passing BUNDLE without understanding BUNDLE were > clearly beyond that limit). >=20 > (Cullen, apologies if I misstate what you said). >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Thu Feb 21 09:39:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C8821F8ECD for ; Thu, 21 Feb 2013 09:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWJJjdq4NRUX for ; Thu, 21 Feb 2013 09:39:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DED3E21F8ECA for ; Thu, 21 Feb 2013 09:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8548; q=dns/txt; s=iport; t=1361468362; x=1362677962; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ls2FFszpVigS26fsvTsASCD7JunGwfBwAiSD2cEj0Rk=; b=WhqZ0oRhW1/espCgz9VfDbFXLJ6Yj/R1GgKmu/v8dN776KDNPrCnclUJ cWE/WTd5f+oLH0bTA79CiqxdzE10+Jl0b0jj0kNXbVMcG6bULYqZSIQDL b1LRW+lVBMU5uh+USXYOM8m19CEcmCQEGFV4we25eezVXIi3q8QymIf9m M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKpaJlGtJXG9/2dsb2JhbABFwH+BBRZzgh8BAQEDAToNNwcEAgEIEQQBAQsUCQcyFAkIAQEEARIIiAQFAbEJjhiOXSYSBoJZYQOXU49BgVKBNYIn X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; d="scan'208";a="179717223" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 21 Feb 2013 17:39:21 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1LHdLi0032255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 17:39:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 11:39:21 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 - Charles' comments Thread-Index: Ac4QAnfKtcZYT/MbQ4exDfkvD+TtAwAQGqxw Date: Thu, 21 Feb 2013 17:39:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047BAD0D@xmb-aln-x08.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B0FDB87@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FDB87@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 - Charles' comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:39:23 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, February 20, 2013 11:10 PM > To: Charles Eckel (eckelcu); mmusic@ietf.org > Subject: RE: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle- > negotiation-03 - Charles' comments >=20 > Hi Charles, >=20 > Thanks for your comments! Reply inline. >=20 > >I read the draft and I think it is a good step forward. I like the overa= ll > approach and think it can work. I do have questions about some of the > specifics, and also some suggested changes and additions. > > > >1) In section 1, the 4th paragraph ends as follows: > > > > The port number > > value associated with the first "m=3D" line associated with the > > "BUNDLE" group represents the port value number offered to be used in > > the single 5-tuple. > > > >I think this is no longer necessary per the rules in section 6.1, and it= should > be removed. >=20 > The text talks about the Offer where different port numbers are used, ie > when it is still not known whether the Answerer supports bundle. But, > maybe that needs to be more clear. I understand that. However, in that case, it seems to me that the port numb= er of the first "m=3D" line no longer has any special significance because = each "m=3D" line has its own port number, and if another offer is sent to m= ake all the ports the same, that port number may be different than any of t= he port numbers in the initial offer. =20 > -------------------------- >=20 > > 2) Section 2 says the following about RTCP: > > > > Bundled media: Two or more RTP streams using a single 5-tuple. The > > RTCP streams associated with the RTP streams also use a single > > 5-tuple, which might be the same, but can also be different, as the > > one used by the RTP streams. > > > >This is contradicted by section 6.1, which says the SDP offer MUST > > o 5. Insert an SDP 'rtpc-mux' attribute. > > > > So one of these needs to be changed, and replace 'rtpc-mux' with 'rtcp- > mux' :) >=20 > Correct. I got the same comment off-line from Harald, but forgot to fix i= t. >=20 > Do people have any preference? Shall du usage of rtcp-mux be a SHOULD, a > MUST, or a RECOMMEND? :) According to draft-ietf-rtcweb-rtp-usage, it is mandatory to support both m= uxed and non-muxed, so SHOULD seems most appropriate to me. What is importa= nt is that rtcp-mux is used or not use consistently across all BUNDLED "m= =3D" lines. > -------------------------- >=20 > >3) OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we > mandate > > that "m=3D" lines must be grouped in the same way in the SDP Answer a= s > > they are grouped in the SDP Offer? > > > > I'd say yes, because otherwise you are not sure if something is wrong (= e.g. > an intermediary has changed the ports, or something > > does not really understand bundle). I think if the ports in the SDP ans= wer > are not grouped the same as in the offer, it should be > > interpreted as a failure to bundle, and another offer should be sent to= use > different ports. >=20 > I'm still thinking about it, but at least at this point I would agree wit= h you :) >=20 > -------------------------- >=20 > >4) I do not understand the intent of the following text in section 6.2: > > > > However, if the "m=3D" lines associated with the "BUNDLE" > > group contain different port number values (i.e. the SDP Offer is > > generated until it is known whether the SDP Answerer supports the > > "BUNDLE" grouping extension) the SDP Offerer MUST NOT set the port > > number value of the first "m=3D" line associated with the "BUNDLE" > > group to zero. > > > > Perhaps there is a typo, but in any case, I do not think the first "m= =3D" lines > needs to be treated specially any more. This is similar to comment (1). >=20 > Keep in mind that, in this case, only the port of the first "m=3D" line > represents the bundle port (as different port values are given for the ot= her > m=3D lines). If the "m=3D" lines have different ports, my thinking is that no special me= aning is tied to any of them. In a subsequent offer/answer exchange where t= he ports of all the bundled "m=3D" lines are set to the same value, that va= lue need not be the same as what was in the previous offer that used separa= te ports for each "m=3D" line. For example, if the initial offer is: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 10000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 10002 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 The subsequent offer may be: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com s=3D c=3DIN IP4 host.atlanta.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 20000 RTP/AVP 0 8 97 a=3Dmid:foo b=3DAS:200 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:97 iLBC/8000 m=3Dvideo 20000 RTP/AVP 31 32 a=3Dmid:bar b=3DAS:1000 a=3Drtpmap:31 H261/90000 a=3Drtpmap:32 MPV/90000 =20 > -------------------------- >=20 > >5) OPEN ISSUE #2: If the session has been established without BUNDLE, = do > > we allow BUNDLE to be enabled later during the session? > > > > Yes, but need to use different ports until it is known that both offere= r and > answerer support bundle. >=20 > Sure, that rule would still apply. >=20 > -------------------------- >=20 > >6) OPEN ISSUE #3: If the session has been established with BUNDLE, do = we > > allow BUNDLE to be disabled later during the session, meaning that > > > > Yes, for failure recovery. >=20 > I was more thinking of the case where endpoints already have successfully > negotiated the usage of bundle, and then at some point during the session > chose (for whatever reason) to disable the multiplexing. >=20 > Basically it would mean sending a new offer, without BUNDLE, and with > different port number values - ie a "legacy" offer :) Yes. =20 > -------------------------- >=20 > >7) Section 6.3 ends as follows: > > > > Until the SDP Answerer receives the new SDP Offer, which contains an > > identical port number value for each "m=3D" line associated with a > > "BUNDLE" group, it MUST use the port, and related information (ICE > > candidates, SDES keys etc) associated with the first "m=3D" line in t= he > > "BUNDLE" group. > > > > I think the SDP Answerer needs to wait for the next offer and not assum= e > the first "m=3D" line contains the port to be used for the bundle. >=20 > Is there a specific reason why you think that we can't mandate the Offere= r > to insert the bundle port in the first "m=3D" line? Because it gets confusing if the first bundled "m=3D" line in the SDP offer= is rejected in the first SDP answer. I just think it is cleaner to wait fo= r the next offer. I suppose it is less efficient, so I agree there are trad= eoffs. =20 > -------------------------- >=20 > >8) Section 10 > > > >The SDP Answer shows the same port being used in the "m=3D" lines. I was > thinking this first answer would use different ports, and only if > >there is another offer/answer exchange would both the offer and the > answer switch to using the same port. >=20 > My personal opinion is that the answerer already knows that the offerer > wants to use bundle, and is expected to send a new offer. Also, by using = the > same ports already in the first answer, we would prevent a case where the > answerer does NOT support bundle, but blindly copies the grouping > attributes from the offer to the answer. If you wait until the second offer/answer exchange to set the ports to be t= he same, you still get this property. Also by waiting until the second offe= r/answer exchange to make the ports the same you increase the odds of the i= nitial offer/answer completing correctly end to end. =20 > But, opinions are welcome :) Yes, as I am not all the convinced as to which way is better yet either. Cheers, Charles > Regards, >=20 > Christer From fluffy@cisco.com Thu Feb 21 11:30:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9437B21F88EF for ; Thu, 21 Feb 2013 11:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.328 X-Spam-Level: X-Spam-Status: No, score=-110.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tQbwQ+V1UHy for ; Thu, 21 Feb 2013 11:30:40 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2821F8821 for ; Thu, 21 Feb 2013 11:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1801; q=dns/txt; s=iport; t=1361475040; x=1362684640; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=aXv58pK5fUmX9JhyqSDDdCX2taL/nErv9Qd+Kbt41Co=; b=CP0E95pO2Q/kQeLTQcpjFi5fCgEA2yzqbHwR+OR3hR41lP9kt+THLeVA eOry91KSDU8QyZZ6oq6568E74foa4y6EX5hVKKv94N3iQ/PA0efREunoS DhgaO2lLmmMOQNKqYTb2OuhvOPCeIdy+uG4DV3yW8pRyXpghFF8lcp7s5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHR0JlGtJV2c/2dsb2JhbABFwQuBBRZzgiEBBIELASpWJwQbiAqeVKBpjl2DF2EDpxSDB4In X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179547487" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2013 19:30:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1LJUeYI011792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Feb 2013 19:30:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:30:40 -0600 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org (E-mail)" Thread-Topic: Cullen Notes from ports call today. Thread-Index: AQHOEGnuy/W4X317fUSy30VykjSE/Q== Date: Thu, 21 Feb 2013 19:30:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97EC5F57E902C1478BCA3B569FC5C260@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Cullen Notes from ports call today. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:30:41 -0000 My random notes more for myself than anyone else =85 Christer explained new draft is combination between old and new. If you don= 't each side support bundle, use diff port number in offer, after that you = use same with=20 Question about 3pcc use cases. Not clear exactly what cases because some of= the B2BUA cases, it's not an issues. Dale point at music on hold MOH cas= e, draft-worrley-service-example. To me this looks like a B2BUA that is off= ering SDP that it does not understand. If an INVITE with replaces was used = instead of re-INVITE in same dialog seems like this would work fine.=20 Some people thought that every offer/answer re was in depended of previous = one. People gave example where is just not this way. For example, ICE can n= ot restarted on updated offer, m line can be offer.=20 Richard pointed out this is lesser of evils, suggestion is initial offer di= ffers ports, answer if it does not want to bundle, use diff ports. If answe= r wants to do multiplexing, then 5 tuple used is first valid non zero m-lin= e is used for the entire bundle. All others are disabled by port=3D0 or con= nection address is unspecified. Still have bundle group to group these all = together. For subsequent offer answers, does the offer have candidates for = all m-lines or just one valid line. Revised idea, the port used by offerer,= is first valid m line in offer, the port used in answer, is first valid po= rt in answer. May not be the same m-line. Middle boxes would need to know a= bout this to have any hope of working. Problem that the answer can't disabl= e some m-line's in subsequent o/a.=20 Open issue is does a subsequent offer in a dialog has different or same por= ts.=20 how to have m-line that are only used if you do bundle? From jmpolk@cisco.com Thu Feb 21 14:49:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B0321E803D for ; Thu, 21 Feb 2013 14:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGtPQZ6679y4 for ; Thu, 21 Feb 2013 14:49:04 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A621E803F for ; Thu, 21 Feb 2013 14:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2426; q=dns/txt; s=iport; t=1361486944; x=1362696544; h=message-id:date:to:from:subject:mime-version; bh=wtjSkCh49+fxAOcADp0PCBiqH3NoTywtovAkwQnixAo=; b=AuaJTDlFnvkito6rehwOlGs+Du0gSZwxL9J100R9jL8hVVr9dhPabmdD XvHMvQUNkjaP9gE53iLRVTIIhlmwdLrMaT08sY2/oo7ImMAJkiG5qlPj1 FkMtLTFWIrWaiZlmsFYx/dSeoOumKuK8RIjjbs5WLIkjRCPWIa+qbI3bV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAGkJlGtJXHA/2dsb2JhbAA7CoN4viAWc4JeAjElJRUfCkQciAkHBZ46oGSNQ4USA4hpjmqPQYMm X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179867457" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2013 22:49:03 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1LMn3Cr004636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 22:49:03 GMT Message-Id: <201302212249.r1LMn3Cr004636@rcdn-core2-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Feb 2013 16:49:03 -0600 To: mmusic From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [MMUSIC] Submitted an update to the Traffic Class Label (TCL) attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:49:05 -0000 MMUSIC I'm letting the WG know that we've updated the trafficclass attribute draft to -03. Abstract: This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-traffic-class-for-sdp-03 Here are the changes listed in Appendix 1 from the above URL A.1 From -02 to -03 These are the following changes made between the WG -02 version and the -03 version: - Rearranged a fair amount of text - Separated and defined the components into separate subsections. - built 5 different tables, one per category, that lists within each category - what applications are appropriate as well as what adjectives are appropriate for each application within that category. Other stuff we did (not mentioned in the appendix), that we also changed: - We also rather significantly modified the IANA considerations section, including where the bar is to register different types of components. I.e., "category" takes a 'PS RFC', the "application" and "adjective" take 'spec required', but we're thinking of making this only need 'expert review'. What does the WG think of this? - We worked with Paul K on the ABNF, which he likes now. - created a "partial" admission qualifier for endpoints that send more traffic than had capacity admission applied to the session. - we want to learn about any traffic flows we aren't considering that we should be. - the rearranging made many little things visible that needed fixing, adding or deleting. - what we have *not* addressed is Dan Wing's desire for a label to address his sensor traffic, or put another way, should we have a periodic/infrequent/sporadic-like non-media 'category'?. This is something that makes sense to the authors, but we want to hear from the WG on this... we're having problems coming up with a proper category name. Comments and questions are appreciated. James/Paul/Subha From fluffy@iii.ca Thu Feb 21 17:21:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3126521F886A; Thu, 21 Feb 2013 17:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfA2u-neffUq; Thu, 21 Feb 2013 17:21:20 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6145921F8713; Thu, 21 Feb 2013 17:21:20 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C5A1922E255; Thu, 21 Feb 2013 20:21:13 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <98946C10-78D3-4AF2-849A-A10F8509EB7C@iii.ca> Date: Thu, 21 Feb 2013 18:21:11 -0700 To: "rtcweb@ietf.org" , "mmusic@ietf.org (E-mail)" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [MMUSIC] Plan draft discussed in boston X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:21:21 -0000 At the Boston interim, I discussed putting together a few drafts.=20 First the requirements around the media stuff at=20 http://tools.ietf.org/html/draft-jennings-mmusic-media-req The analysis of how bundle multiplexing would work with existing SDP = attributes=20 http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes This draft lays out the framework and takes a first pass at all the = classifications but it some of the attributes, particularly harder = things like cap neg, need some work. I suspect trying to get the authors = of the original attribute drafts to review it would work well. Suhas and = I did a lot of reading to get this to this state but it is a huge amount = of work to analysis all of these.=20 Finally a proposed plan for a way forward the media related issues at =20= http://tools.ietf.org/html/draft-jennings-rtcweb-plan I plan to make some changes to plan before the -01 deadline so let me = know if you think there are things that should be different.=20 Cullen From fluffy@cisco.com Thu Feb 21 19:09:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7D21E8044 for ; Thu, 21 Feb 2013 19:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppCnAw+17iL9 for ; Thu, 21 Feb 2013 19:09:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B421E803C for ; Thu, 21 Feb 2013 19:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1361502569; x=1362712169; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yfuSQUd9DsKDZ/v7dYmzzmqY8yRAtyJm4eIJqabMKjk=; b=Kmt1L7Hk/S4ZHCUpDeAgA4lPwU89J/V6hGSGhwyGvATV8EjDV0CgQXIm 2ByjNWaJTGFgqSId3T/JRaEaCr5ng34dLPzQlnkqfaI1T1IUx5suI8x2S KwKmcZE79fHkXOzjcbG1DGsvj9IpVcFmAYtde1RYpAs1A8dOMzD5I31Ty 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPXfJlGtJXG+/2dsb2JhbABFhge7EoEJFnOCHwEBAQMBOj8QAgEIIhQQMiUCBA4FCIgEBgy/LY0ygSkCMQeCX2EDl1OPQYMHgic X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208";a="179911077" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2013 03:09:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1M39Tq2029191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 03:09:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 21:09:29 -0600 From: "Cullen Jennings (fluffy)" To: Harald Alvestrand Thread-Topic: [MMUSIC] Signaling trickle support Thread-Index: AQHOEKoGoTjVL1kZDE2wMFT9eg1eLA== Date: Fri, 22 Feb 2013 03:09:28 +0000 Message-ID: References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <50A20CE5.5000200@alvestrand.no> In-Reply-To: <50A20CE5.5000200@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Signaling trickle support X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:09:45 -0000 On Nov 13, 2012, at 2:03 AM, Harald Alvestrand wrote= : >> Because of the min. 20 ms Ta timer constraints, which apply cross-media = stream ? Can somebody refresh my mind as to why that is (e.g. are residenti= al NATs at this point generally not capable of creating NAT bindings faster= than at 20 ms intervals) ? > I have been told that in BEHAVE testing, NATs were found that would behav= e incoherently at short binding creation intervals, but none were found tha= t couldn't handle one new binding every 20 ms, so this was set at the minim= um interval for potentially binding-creation actions. >=20 > Harald Some of the testing was getting the programs working for the results in htt= p://tools.ietf.org/html/draft-jennings-midcom-stun-results-02 but other stu= ff done at Cornel and I think MIT came up with similar results.=20 From fluffy@cisco.com Thu Feb 21 19:11:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2F21E8044 for ; Thu, 21 Feb 2013 19:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4orWpxLv2yMG for ; Thu, 21 Feb 2013 19:11:11 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AF11C21E803C for ; Thu, 21 Feb 2013 19:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=594; q=dns/txt; s=iport; t=1361502671; x=1362712271; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FIJRrxMxYajUZh/8+8i/nkKUplcyDfFzuQz+3plTe+c=; b=Z6gONzpFKuzty1f0B0IfeWjuLFSTXGM6Hfc3aL2EqTCbzeH3pw6lqI1s hdrIicUbebwKnBVpFsz4gFyLYaLmixi/bRr12dYF4CixAr/vTb+Va3bRG AD4ZBsw9p4r4HQGX5Kfw+Ub+23tDZ6em9u7DUPJo5wrUOh2tSCIuf30aR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAHLhJlGtJV2c/2dsb2JhbABFhge7EoEJFnOCHwEBAQMBOj8FCwIBCCIUEDIlAgQOBQiIBAa/O40ygSkCMQeCX2EDpxSDB4In X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208";a="179880187" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 22 Feb 2013 03:11:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1M3BBYl025600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Feb 2013 03:11:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 21:11:10 -0600 From: "Cullen Jennings (fluffy)" To: "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] Signaling trickle support Thread-Index: AQHOEKpDpXIC0D/b6U6TColU2zjO2Q== Date: Fri, 22 Feb 2013 03:11:10 +0000 Message-ID: References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <50A20CE5.5000200@alvestrand.no> <072901cdc1bd$60d2cd60$22786820$@cisco.com> <50A289F2.1030004@cisco.com> In-Reply-To: <50A289F2.1030004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B75B470BD243840AF0CC72E44865B98@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Signaling trickle support X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:11:12 -0000 On Nov 13, 2012, at 10:57 AM, Flemming Andreasen wrote= : > I've been told (second hand) that Google Maps routinely opens 50 TCP conn= ections at a time, but don't have any details as to the speed with which th= ey are opened. Anybody have any further insights or similar examples (that = seem to work in practice) ? Google maps is a bad example as it regularly has this fail in many location= s - when it fails, there are whole strips of the map that do not load. So i= t is pretty much an example of something that is on the fairly aggressive l= evel.=20 From worley@shell01.TheWorld.com Thu Feb 21 19:19:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B88321E803C for ; Thu, 21 Feb 2013 19:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6LK2kq9LXmE for ; Thu, 21 Feb 2013 19:19:07 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7621E8039 for ; Thu, 21 Feb 2013 19:19:07 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1M3Id6k023264 for ; Thu, 21 Feb 2013 22:18:41 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1M3Idk12341304 for ; Thu, 21 Feb 2013 22:18:39 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1M3IcNB2337892; Thu, 21 Feb 2013 22:18:38 -0500 (EST) Date: Thu, 21 Feb 2013 22:18:38 -0500 (EST) Message-Id: <201302220318.r1M3IcNB2337892@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Requirements for bundling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:19:08 -0000 Here are the requirements (desiderata, really) from the latest version of my draft, draft-worley-sdp-bundle. No doubt they're not complete. 3. Desiderata This section lists desiderata for the bundle mechanism in SDP. (I use the term "desiderata" -- "things that are desired" -- rather than "requirements", because we may discover that we can't optimally satisfy all of these criteria at the same time.) The first section lists desiderata that are arise from considering the ways applications may wish to bundling. The second section lists desiderata that arise from compatibility with existing Internet infrastructure. 3.1. Feature Desiderata DES F1 For each bundle, there is a group of media descriptions which describe the application-level RTP sessions. This specification must allow the same granularity of description as when the media flows were not multiplexed. This description includes identifiers which connect the media flows with the application and with each other. This requirement is taken from draft-jennings-mmusic-media-req-00. DES F2 For each bundle, there is a media description that describes the transport-level RTP session. DES F1 and DES F2 do not specify whether the transport-level media description may or may not also be one of the application-level media descriptions. DES F3 There must be a uniform way to deal with new SDP parameters, so that newly defined SDP parameters do not require a specific updating of the bundling procedures. This desideratum is taken from slides-interim-2013-rtcweb-1-10.pdf. DES F4 Multiple separate bundles within one SDP must be supported. DES F5 Bundles may contain other bundles as constituents. Of course, no bundle may directly or indirectly contain itself. (I don't expect any current implementation to implement bundles within bundles, but we should design the mechanism to allow this, as some day we will likely need it.) DES F6 A bundle may contain zero constituents. A bundle with no constituents serves no purpose for the transport of media, but we are likely to someday need to describe such a bundle. (Compare that an SDP m= line is syntactically constrained to specify at least one payload type. When SDP was used only to specify multicast sessions, this constraint was common sense. But once SDP offer/answer was invented, when a media description was rejected, the natural representation would be an m= line with a zero port and no payload types. But a payload type was syntactically required, so we now have to provide at least one token payload type in rejected m= lines.) DES F7 If an answerer that does understand the bundle mechanism processes an offer that contains a bundle, it must be able to (1) accept the bundle and selectively accept or reject each constituent RTP session within it, (2) reject the bundle as a whole, or (3) reject the bundling and selectively accept or reject each constituent RTP session as separate RTP sessions. Presumably answer (3) resembles that which would be produced by an answerer that does not understand the bundle mechanism. It is a lower priority that the answerer can distinguish between accepting the bundle while rejecting all of its constituents, and rejecting the bundle as a whole. But those two conditions differ conceptually regarding whether any "framing" actions of the bundle are performed. DES F8 There must be a reliable way to demultiplex incoming RTP into the separate application-level RTP sessions. Similarly, there must be a reliable way to demultiplex the associated RTCP information. The RTCP information for each media stream is tagged with the SSRC about which it reports, and the SSRC is used to correlate the RTCP reports with the RTP sessions containing media with the same SSRC. So regarding RTCP, this desideratum appears to be straightforward to satisfy. DES F9 The specification must specify any needed additional procedures for handling SSRC collisions between media sources within different application-level RTP sessions, as those can now collide. In the terminology of RFC 3550, the constituent media descriptions are now part of one RTP session. DES F10 When an offer is constructed, the offerer must not need to pre-allocate TURN relays for constituent media descriptions. When both endpoints support bundling, the mechanism must not require the offerer to allocate TURN relays for constituent media descriptions. This desideratum was suggested by Andrew Hutton. DES F11 It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. Presumably this can be accomplished as it is now, with a single media description carrying multiple video flows that are distinguished only by their SSRCs. This desideratum is taken from slides-interim-2013- rtcweb-1-10.pdf. DES F12 Bundling must not interfere with ICE usage, and in particular, ICE's ability to negotiate both IPv4 and IPv6 addresses simultaneously. This desideratum was suggested by Andrew Hutton. 3.2. Compatibility Desiderata DES C1 In offer/answer usage, an endpoint using the bundle mechanism must interwork correctly with an endpoint that does not understand the bundle mechanism. DES C2 Interworking must continue when SDP endpoints are replaced with other endpoints during a sequence of offer/answer exchanges (such as happens in 3PCC or call transfers "behind an SBC"), including when a supporting endpoint is replaced by a non- supporting endpoint or vice-versa. SDP features (e.g., codec set and ICE) are generally designed so that an offerer offers every facility it is willing to support in the current instance. Thus, if the answerer is a different endpoint than the previous answerer, the new answerer will negotiate a compatible set of facilities without needing knowledge of its predecessor's SDP. The offerer will smoothly transition to the new facilities. This property is required to support 3PCC situations (e.g., RFC 3725 and draft-worley-service-example). This desideratum was suggested by Richard Ejzak. DES C3 Avoid using media types in m= lines other than audio and video unless required for user media, as some SBCs reject SDP that uses other media types. This desideratum was suggested by Hadriel Kaplan. DES C4 Any additional m= lines prescribed by the bundle mechanism should be ordered after the constituent m= lines. Many devices that have only one audio or video channel accept the first m= line with that media type and reject any further ones non-DES C5 SBCs generally pass through attributes that they do not understand. SBCs generally pass through codec specifications that they do not understand, even if they are configured to transcode certain specific codecs. This non-desideratum was suggested by Hadriel Kaplan. DES C6 After offer/answer processing is finished, if the exchanged SDP is examined by a non-supporting SBC, the set of transport associations that it sees being specified for media exchange should be the set that are actually used for media transfer. This is needed because SBCs monitor the packet traffic on the transport associations and if no media is seen on one of the associations for a significant period of time, the SBC will tear down the call. This desideratum was suggested by Hadriel Kaplan. DES C7 In a session description, no endpoint of a transport association may be used multiple times. Such duplication is not defined by [sdp]. Some SBCs do not support such duplication (ultimately, because it was not supported by [RFC 2327]), and they reject SDP specifying duplicated transport association endpoints. This desideratum was suggested by Cullen Jennings. DES C8 Offer/answer processing between supporting processors must be completed in one exchange. When interworking between supporting and non-supporting processors, it is less desirable but admissible that a second offer/answer exchange may be needed to complete configuring the multimedia session. Dale From fluffy@cisco.com Thu Feb 21 19:25:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B417D21E803D for ; Thu, 21 Feb 2013 19:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ+3U-z77TQW for ; Thu, 21 Feb 2013 19:25:42 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BF02221F886A for ; Thu, 21 Feb 2013 19:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2891; q=dns/txt; s=iport; t=1361503542; x=1362713142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/Ckf2+GVgbWfNcYa8fcvXtNST62ptIbWJ3ZvOwNMQZ4=; b=LVGZ5FsyPAL8BJA+KDu41AGwjL0T4h2nILg2JpOYHjFIlRiCOTLiZh4G QbxdEmNVqhLuzBwW/7ZQySWtCRuH1Ggdme0HzLDSLxMaLTk9VFg8lemQS mEaY0x7J/9q9QWJPTmL6IwAgGM2NEM9hfiLSXQiJxDPhm2W5dPWEx17eW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMnjJlGtJV2Z/2dsb2JhbABFwRmBCBZzgh8BAQEDAQEBAWQHCwULAgEIIiQnCyUCBA4FCIgEBgy/M45bAjEHgl9hA4gzjyCPQYMHgic X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208";a="179913708" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2013 03:25:42 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1M3PgdL018223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 03:25:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 21:25:41 -0600 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Updating the pacing of ICE connectivity checks Thread-Index: AQHOEKxK/muj19GG2UO6zABx16NwAw== Date: Fri, 22 Feb 2013 03:25:40 +0000 Message-ID: References: <511CEB64.6070306@ericsson.com> In-Reply-To: <511CEB64.6070306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F17994E8D486249B6E7B932F00CB713@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:25:43 -0000 This is a hard problem to figure out but glad it is being tackled as the cu= rrent draft was fiction created to get it approved more. I'd be tempted to think of their being a few different things to conserve o= r constraints we need to not exceed=20 1) nat timing=20 2) total ports in usage on the NAT 3) bandwidth usage that is not congestion controlled=20 For 1) I'm not seeing any reasons to move off the 20 ms lower bound - but i= f someone has empirical data that would be nice as the empirical data we ar= e basing this on is old.=20 For 2) some Carrier Grade Nats (CGNs) are restricting a given client to som= ething like 1000 ports. There may be other limits too. It might be worth se= tting up ICE so that a given ICE client never used more than 100 ports at a= time. I think this is a new type of constraint that is not a big deal toda= y but may be a bigger deal in the future and we should consider it in an IC= E bis.=20 For 3) Its very hard to come up with something that is fast enough that the= media guys like it and slow enough the transport folks are sure it is safe= . My strawman proposal would be use more more bandwidth than G.711 with 20 = ms packets as we have been doing that all over the place - without congesti= on control - and the internet has not melted down.=20 On Feb 14, 2013, at 6:49 AM, Ari Ker=E4nen wrote= : > Hi all, >=20 > Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for backgr= ound, see [1] and [2]), as discussed at the Atlanta meeting, will be one of= the important changes in the new version of ICE. >=20 > Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be configurab= le, SHOULD have a default of 500 ms, and MUST NOT be configurable to be les= s than 500 ms." >=20 > This results in very slow pace of starting connectivity checks if ICE is = used with non-RTP traffic. With RTP, the Ta is calculated based on the expe= cted bandwidth used by the RTP stream and can be down to 20 ms. Therefore, = many current implementations apparently ignore the "MUST NOT" above and set= Ta to something lower. >=20 > The quite conservative value of 500 ms was originally chosen because of t= he fear of congesting the links with the connectivity check messages. This = is obviously still a valid concern, but would suggesting something lower st= ill make sense? How low would it be reasonably safe to go? What is currentl= y used in practice? Can we come up with a formula similar to RTP (perhaps b= ased on expected bandwidth usage)? >=20 >=20 > Cheers, > Ari >=20 > [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 > [2] http://tools.ietf.org/html/rfc5245#section-16.2 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Feb 22 03:49:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCEC21F8EB3 for ; Fri, 22 Feb 2013 03:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1ssQNT4DIBL for ; Fri, 22 Feb 2013 03:49:09 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE16D21F8EAF for ; Fri, 22 Feb 2013 03:49:02 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-d6-51275b2d4583 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CB.98.10459.D2B57215; Fri, 22 Feb 2013 12:49:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 12:49:01 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "Harald Alvestrand" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) Thread-Index: AQHOEEQhUP7WLYIH+E+EYYvRtN1DsJiEg1+AgAE9WEA= Date: Fri, 22 Feb 2013 11:49:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1049E9@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> <51263661.3060307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F36EA6DB3@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA6DB3@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvja5utHqgwb1txhbH+rrYLKYuf8xi 0dsQ7sDs0fpsL6vHlQlXWD2WLPnJFMAcxWWTkpqTWZZapG+XwJUx8/gn1oIm0Yore2czNzCu E+xi5OSQEDCR2D3tOyuELSZx4d56NhBbSOAQo8Tx9ypdjFxA9mJGiRenlzF2MXJwsAlYSHT/ 0wapERGYxiixeH8pSI2wwHJGiZ2/XrGBOCICKxgllux9xw5RZSXR+fgJC4jNIqAq8XlVNzOI zSvgLXGrq5sRYtskVok7JxxAbE6BWIl3O+aD1TACXfT91BomEJtZQFzi1pP5TBCXCkgs2XOe GcIWlXj5+B/UB4oSV6cvh6rXkViw+xMbhK0tsWzha6i9ghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRvbcxMyc9HLDTYzA+Di45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwGgWUD65rJPZ83BV9RzGKeI756vGaDmVfFfM+Xhv5QNd1Wa3FW63Jp3+ kvJlua2ippq6WamH4zy1CwHnCvMECrVvrLRT+3Kha8G1BZ+3u3ZHxC+7XDHlttL8l1wlc/X+ WmzfVyfRq1fmc/HoyTcPGB82rtxbmdT17sLR9RfFX1l6zWX16Fd4X6/EUpyRaKjFXFScCAAe uzoFXQIAAA== Subject: Re: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:49:10 -0000 Hi, >I did not mean that an intermediary should forward attributes it doesn't u= nderstand but that an intermediary should be able to deal with any=20 >SDP it receives. If some intermediaries choke on having the same port in = multiple m lines then we should avoid doing that, even during=20 >subsequent offers since there are multiple 3pcc scenarios where subsequent= offers can flow through different intermediaries. The BUNDLE solution expects the intermediary to accept the same port number= .=20 Your solution expects the intermediary to understand that, eventhough the a= ddresses for all-but-one m- lines are unspecified, media associated with th= ose m- lines will still be sent - using the port of another m- line. I still strongly think that sending media associated with m- lines, for whi= ch the address is unspecified, is a design error. (It is true that we need to expect that, or somehow ensure that, an interme= diary calculates the correct bandwidth for bundled media, but that applies = to both solutions). Regards, Christer > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Harald Alvestrand > Sent: Thursday, February 21, 2013 9:00 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Requiring support for nonconformant intermediate=20 > systems (Re: FW: New Version Notification for draft-ejzak-mmusic- > bundle-alternatives-00.txt) >=20 > On 02/21/2013 03:51 PM, Ejzak, Richard P (Richard) wrote: > > Sending a subsequent offer with the same port in all bundled m lines=20 > > has its own problems in 3pcc scenarios. You should always send an=20 > > offer that can pass through intermediaries that do not understand=20 > > BUNDLE. My proposal has that characteristic but I'm not sure that=20 > > yours does. > Designing around intermediaries that pass along information that they=20 > do not understand, and then expect to act independently based on the=20 > message that they partially understood, seems to me to be a quite=20 > limiting approach. >=20 > We discussed this at the interim (I think Cullen was pretty vocal that=20 > there's a limit to how much brokenness we can design around, and he=20 > thought intermediaries passing BUNDLE without understanding BUNDLE=20 > were clearly beyond that limit). >=20 > (Cullen, apologies if I misstate what you said). >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Feb 22 03:51:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCFC21F8EA5 for ; Fri, 22 Feb 2013 03:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5BeAKiCkQao for ; Fri, 22 Feb 2013 03:51:14 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5DA21F8E79 for ; Fri, 22 Feb 2013 03:51:14 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-5a-51275bb18ea2 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7D.28.19728.1BB57215; Fri, 22 Feb 2013 12:51:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 12:51:13 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , "mmusic@ietf.org (E-mail)" Thread-Topic: [MMUSIC] Cullen Notes from ports call today. Thread-Index: AQHOEGnuy/W4X317fUSy30VykjSE/ZiFxMfg Date: Fri, 22 Feb 2013 11:51:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B104A06@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje7GaPVAg5u3FSw6JrNZTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyrj46BhrQT9jxZvZDxgbGLO7GDk5JARMJFaf 2skKYYtJXLi3nq2LkYtDSOAQo8T1kzeYIZzFjBJ7HveydDFycLAJWEh0/9MGaRARSJTYcnkW I0hYWMBS4uuLMoiwlcT7Hx/ZQcIiAkYSn86Wg4RZBFQl1jf3MYHYvALeEtPezWAEsYUEfCQW bu8HszkFfCUmb2phBrEZgc75fmoNWD2zgLjErSfzmSDOFJBYsuc8M4QtKvHy8T+o8xUlrk5f DlWvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl RpsYgTFwcMtv1R2Md86JHGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx IY/BzKat93S4lJTtSzc/dJkg63+obNHeI5K7900KCzn/or9Z4cveI5Z/kw9afhdicVec/HM2 m0d34nre7Mt/N7k2GQT1zHvSJrOMZdJV99ibXq80Ej1ruR3+eT+oO6D73Uw9aHNi9ze7j0ES 1Uxz8u/8NKrLYSvV1lyz/eC9iKINUa/2ytxVYinOSDTUYi4qTgQAIYkkl08CAAA= Subject: Re: [MMUSIC] Cullen Notes from ports call today. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:51:15 -0000 >how to have m-line that are only used if you do bundle? There is a solution alternative for that, called MMT :) Regards, Christer From richard.ejzak@alcatel-lucent.com Fri Feb 22 06:41:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1159721F8E74 for ; Fri, 22 Feb 2013 06:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.456 X-Spam-Level: X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kxMAnyxAtTf for ; Fri, 22 Feb 2013 06:41:45 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id B67F421F8E4E for ; Fri, 22 Feb 2013 06:41:36 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1MEea5c007046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Feb 2013 15:41:31 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 22 Feb 2013 15:41:23 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 22 Feb 2013 09:41:05 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) Thread-Index: AQHOEEQk5dAw9HDOIE68f+nShlOa4piEkZrAgAGG5AD//9XbgA== Date: Fri, 22 Feb 2013 14:41:05 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA704E@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> <51263661.3060307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F36EA6DB3@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1049E9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1049E9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:41:46 -0000 Hi Christer, > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Your solution expects the intermediary to understand that, eventhough > the addresses for all-but-one m- lines are unspecified, media > associated with those m- lines will still be sent - using the port of > another m- line. But this requirement is only placed on intermediaries that have already ind= icated support for BUNDLE by forwarding the related attributes. The unspec= ified address only needs to be included in the SDP answer, and not the offe= r, so it is returned within an established dialog, and there is no danger o= f sending it to an unknown intermediary. >=20 > I still strongly think that sending media associated with m- lines, for > which the address is unspecified, is a design error. I'm not sure how the term "design error" applies to a solution that behaves= correctly and consistently under the given assumptions (there are other as= pects to be fixed but bear with me for sake of argument). It is true that = I propose to clarify the meaning of unspecified address in the presence of = BUNDLE, which is a new and as yet non-standardized concept. There are many= examples of such "clarifications" as we expand the capabilities that can b= e represented in SDP. The key is backward compatibility. If the concern i= s about intermediaries that forward BUNDLE attributes without understanding= them, then there is little that can be done anyway. Richard >=20 > (It is true that we need to expect that, or somehow ensure that, an > intermediary calculates the correct bandwidth for bundled media, but > that applies to both solutions). >=20 > Regards, >=20 > Christer From wwwrun@rfc-editor.org Fri Feb 22 12:27:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34721F8C60; Fri, 22 Feb 2013 12:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.048 X-Spam-Level: X-Spam-Status: No, score=-102.048 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih19vzY3UEd9; Fri, 22 Feb 2013 12:27:23 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7A21F8C4C; Fri, 22 Feb 2013 12:27:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 613C6B1E002; Fri, 22 Feb 2013 12:26:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130222202625.613C6B1E002@rfc-editor.org> Date: Fri, 22 Feb 2013 12:26:25 -0800 (PST) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6849 on An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:27:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6849 Title: An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback Author: H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton Status: Standards Track Stream: IETF Date: February 2013 Mailbox: hkaplan@acmepacket.com, kh274@cornell.edu, vnagarjuna@saperix.com, paulej@packetizer.com, nathan@robotics.net Pages: 33 Characters: 66214 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-media-loopback-27.txt URL: http://www.rfc-editor.org/rfc/rfc6849.txt The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/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, real-time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable 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, real-time text, and Video over IP performance metrics. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From worley@shell01.TheWorld.com Fri Feb 22 13:06:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7C21E808C for ; Fri, 22 Feb 2013 13:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTfaxjg4EogP for ; Fri, 22 Feb 2013 13:06:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B066421E8088 for ; Fri, 22 Feb 2013 13:06:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1ML5W3g009805 for ; Fri, 22 Feb 2013 16:05:34 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1ML5WBE2394615 for ; Fri, 22 Feb 2013 16:05:32 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1ML5WY52373869; Fri, 22 Feb 2013 16:05:32 -0500 (EST) Date: Fri, 22 Feb 2013 16:05:32 -0500 (EST) Message-Id: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Another bundling proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:06:03 -0000 I've written an alternative bundling proposal which I think manages the problems of bundling better. A series of tutorial examples are here: http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 so it's easy to see how the proposal works. Distinctive features of this proposal are: - A separate m= line describes the bundled media, allowing unambiguous attribution of attributes to either the bundle or a constituent, and independent rejection of each constituent. - Backward compatibility is achieved straightforwardly. - Multiplexed media flows are attributed to their original constituent media descriptions without requiring each to be declared individually in the SDP. - The multiplexed media flow is artificially given the media type "audio" to prevent rejection by SBCs. - An encapsulating RTP format is used so demultiplexing can be done without coordinating payload types between media descriptions, and to ensure the bundled media description is rejected by non-supporting endpoints. - Zero/non-zero ports and valid/null addresses are controlled to avoid duplicate port usage, and to ensure SBCs see exactly the media flows specified by the SDP. Filename: draft-worley-sdp-bundle Revision: 02 Title: Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP) Creation date: 2013-02-22 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-02.txt Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02 Abstract: This document defines a generic bundle mechanism for the Session Description Protocol (SDP) by which the media described by a number of media descriptions ("m= lines") are multiplexed and transmitted over a single transport association. The transport association is described by an additional media description, allowing SDP attributes to be applied to the aggregate, independently of attributes applied to the constituents. In offer/answer usage, the bundle mechanism is backward compatible with SDP processors that do not understand the mechanism. The mechanism is designed to be compatible with the limitations of the existing Internet infrastructure. From eckelcu@cisco.com Fri Feb 22 13:39:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9621F8F03 for ; Fri, 22 Feb 2013 13:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPj4BYfM8p-e for ; Fri, 22 Feb 2013 13:39:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0887521F8EF9 for ; Fri, 22 Feb 2013 13:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3707; q=dns/txt; s=iport; t=1361569165; x=1362778765; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3XzK05mfa7/xXxgtbssn3fA6/GFOkrG04gQ7OIMnByw=; b=kPnfbfhOAn6gKT8Cgf2kMwhEGuhC2/FYss8tHbC1x2RHnT1klys1r98Y asrlJiT3c5OFB4PWcfE8LebW/mdB0rUTq/4gB2wXyx7H6Jc++jYT296Bk ySL7GYVwjM2N8DUP1yCUtDHFgrlvqoy26vTqrrgmJK+3HQ5dYNMaK0ChC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGLkJ1GtJV2c/2dsb2JhbABEg3i9NoENFnOCHwEBAQMBAQEBNzQQBwQCAQgRBAEBCxQJBycLFAkIAgQBEggBiAMFAQcFvxeOXTgGgllhA5dXj0aDB4FrJBg X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180203504" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Feb 2013 21:39:24 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1MLdOWk024640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 21:39:24 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 15:39:24 -0600 From: "Charles Eckel (eckelcu)" To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Another bundling proposal Thread-Index: AQHOEUBvNj14gmT3j0GqRgoTfKG9TpiGZimQ Date: Fri, 22 Feb 2013 21:39:23 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047BBD8D@xmb-aln-x08.cisco.com> References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> In-Reply-To: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Another bundling proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:39:26 -0000 Hi Dale, Your proposal has some very nice properties; however, my concern with the o= verall approach is that I fear the initial offer will not be handled very w= ell by typical pre-BUMDLE implementations. Due to the port being '9' and th= e connection address being 0.0.0.0, I would expect either: 1) a re-INVITE is needed for things to be renegotiated (best case) 2) the call fails (worst case) Of course other variations between the best and worst case could happen, bu= t the odds of arriving at the worst case seem unacceptably high to me. That= is just my 2 cents without actually testing anything to validate it. I'd l= ike to hear what others think. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Dale R. Worley > Sent: Friday, February 22, 2013 1:06 PM > To: mmusic@ietf.org > Subject: [MMUSIC] Another bundling proposal >=20 > I've written an alternative bundling proposal which I think manages > the problems of bundling better. >=20 > A series of tutorial examples are here: > http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 > so it's easy to see how the proposal works. >=20 > Distinctive features of this proposal are: >=20 > - A separate m=3D line describes the bundled media, allowing unambiguous > attribution of attributes to either the bundle or a constituent, and > independent rejection of each constituent. >=20 > - Backward compatibility is achieved straightforwardly. >=20 > - Multiplexed media flows are attributed to their original constituent > media descriptions without requiring each to be declared > individually in the SDP. >=20 > - The multiplexed media flow is artificially given the media type > "audio" to prevent rejection by SBCs. >=20 > - An encapsulating RTP format is used so demultiplexing can be done > without coordinating payload types between media descriptions, and > to ensure the bundled media description is rejected by > non-supporting endpoints. >=20 > - Zero/non-zero ports and valid/null addresses are controlled to avoid > duplicate port usage, and to ensure SBCs see exactly the media flows > specified by the SDP. >=20 >=20 >=20 > Filename: draft-worley-sdp-bundle > Revision: 02 > Title: Kumquat: A Generic Bundle Mechanism for the Session > Description Protocol (SDP) > Creation date: 2013-02-22 > Group: Individual Submission > Number of pages: 27 > URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bun= dle- > 02.txt > Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle > Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-worley-sdp-bund= le-02 >=20 > Abstract: > This document defines a generic bundle mechanism for the Session > Description Protocol (SDP) by which the media described by a number > of media descriptions ("m=3D lines") are multiplexed and transmitted > over a single transport association. The transport association is > described by an additional media description, allowing SDP attributes > to be applied to the aggregate, independently of attributes applied > to the constituents. In offer/answer usage, the bundle mechanism is > backward compatible with SDP processors that do not understand the > mechanism. The mechanism is designed to be compatible with the > limitations of the existing Internet infrastructure. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Fri Feb 22 18:37:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53F21E8034 for ; Fri, 22 Feb 2013 18:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwmhz9nmP1nT for ; Fri, 22 Feb 2013 18:37:33 -0800 (PST) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by ietfa.amsl.com (Postfix) with ESMTP id 722B021E8030 for ; Fri, 22 Feb 2013 18:37:33 -0800 (PST) Received: from BLU160-W15 ([65.55.111.72]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Feb 2013 18:37:31 -0800 X-EIP: [WQ2AVqHKtYb9RziKT6jhVqZSIPMVDB+F] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0fe1ee6b-a1b5-48f9-a605-b0a902f0cb45_" From: Bernard Aboba To: "Charles Eckel (eckelcu)" , "Dale R. Worley" , "mmusic@ietf.org" Date: Fri, 22 Feb 2013 18:37:31 -0800 Importance: Normal In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047BBD8D@xmb-aln-x08.cisco.com> References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com>, <92B7E61ADAC1BB4F941F943788C08828047BBD8D@xmb-aln-x08.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2013 02:37:31.0571 (UTC) FILETIME=[BAA40830:01CE116E] Subject: Re: [MMUSIC] Another bundling proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 02:37:34 -0000 --_0fe1ee6b-a1b5-48f9-a605-b0a902f0cb45_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While I do agree that legacy implementations will have issues with using th= e same port on multiple m=3D lines=2C the proposal does explicitly address = multiplexing issues via the "kumquat payload format" (an RTP tunnel of sort= s). Describing the implications for RTP in the proposal is better rather t= han implicitly assuming a given de-multiplexing approach or the presence of= RTP extensions (e.g. the capture RTP extensions Roni referred to in a prev= ious post).=20 Since the RTP tunnelling approach does require changes to lots of component= s in the system (e.g. MCUs)=2C it is not necessarily the easiest thing to deploy. However= =2C it does appear to obviate the need to declare individual SSRCs=2C which= a number of the other proposals do not (e.g. if payload types are not requ= ired to unique among all m-lines=2C then if multiple media types are multip= lexed then SSRC is the only remaining de-multiplex point=2C so SSRC declara= tion is required).=20 Also=2C tunnelling proposals can be used to address some of the ICE perform= ance issues as well. There is really no intrinsic reason why those kind of= proposals can't be used to allow multiple endpoints to share a TURN alloca= tion=2C for example=2C removing TURN as a performance bottleneck without re= quiring Trickle ICE.=20 > From: eckelcu@cisco.com > To: worley@ariadne.com=3B mmusic@ietf.org > Date: Fri=2C 22 Feb 2013 21:39:23 +0000 > Subject: Re: [MMUSIC] Another bundling proposal >=20 > Hi Dale=2C >=20 > Your proposal has some very nice properties=3B however=2C my concern with= the overall approach is that I fear the initial offer will not be handled = very well by typical pre-BUMDLE implementations. Due to the port being '9' = and the connection address being 0.0.0.0=2C I would expect either: > 1) a re-INVITE is needed for things to be renegotiated (best case) > 2) the call fails (worst case) > Of course other variations between the best and worst case could happen= =2C but the odds of arriving at the worst case seem unacceptably high to me= . That is just my 2 cents without actually testing anything to validate it.= I'd like to hear what others think. >=20 > Cheers=2C > Charles >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Dale R. Worley > > Sent: Friday=2C February 22=2C 2013 1:06 PM > > To: mmusic@ietf.org > > Subject: [MMUSIC] Another bundling proposal > >=20 > > I've written an alternative bundling proposal which I think manages > > the problems of bundling better. > >=20 > > A series of tutorial examples are here: > > http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 > > so it's easy to see how the proposal works. > >=20 > > Distinctive features of this proposal are: > >=20 > > - A separate m=3D line describes the bundled media=2C allowing unambigu= ous > > attribution of attributes to either the bundle or a constituent=2C an= d > > independent rejection of each constituent. > >=20 > > - Backward compatibility is achieved straightforwardly. > >=20 > > - Multiplexed media flows are attributed to their original constituent > > media descriptions without requiring each to be declared > > individually in the SDP. > >=20 > > - The multiplexed media flow is artificially given the media type > > "audio" to prevent rejection by SBCs. > >=20 > > - An encapsulating RTP format is used so demultiplexing can be done > > without coordinating payload types between media descriptions=2C and > > to ensure the bundled media description is rejected by > > non-supporting endpoints. > >=20 > > - Zero/non-zero ports and valid/null addresses are controlled to avoid > > duplicate port usage=2C and to ensure SBCs see exactly the media flow= s > > specified by the SDP. > >=20 > >=20 > >=20 > > Filename: draft-worley-sdp-bundle > > Revision: 02 > > Title: Kumquat: A Generic Bundle Mechanism for the Session > > Description Protocol (SDP) > > Creation date: 2013-02-22 > > Group: Individual Submission > > Number of pages: 27 > > URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-b= undle- > > 02.txt > > Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundl= e > > Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-worley-sdp-bu= ndle-02 > >=20 > > Abstract: > > This document defines a generic bundle mechanism for the Session > > Description Protocol (SDP) by which the media described by a number > > of media descriptions ("m=3D lines") are multiplexed and transmitted > > over a single transport association. The transport association is > > described by an additional media description=2C allowing SDP attribu= tes > > to be applied to the aggregate=2C independently of attributes applie= d > > to the constituents. In offer/answer usage=2C the bundle mechanism = is > > backward compatible with SDP processors that do not understand the > > mechanism. The mechanism is designed to be compatible with the > > limitations of the existing Internet infrastructure. > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --_0fe1ee6b-a1b5-48f9-a605-b0a902f0cb45_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While I do agree that legacy imp= lementations will have issues with using the same port on multiple m=3D lin= es=2C the proposal does explicitly address multiplexing issues via the "kum= quat payload format" (an RTP tunnel of sorts). =3B Describing the impli= cations for RTP in the proposal is better rather than implicitly assuming a= given de-multiplexing approach or the presence of RTP extensions (e.g. the= capture RTP extensions Roni referred to in a previous post).

Since= the RTP tunnelling approach does require changes to lots of components in = the system
(e.g. MCUs)=2C it is not necessarily the easiest thing to dep= loy. =3B However=2C it does appear to obviate the need to declare indiv= idual SSRCs=2C which a number of the other proposals do not (e.g. if payloa= d types are not required to unique among all m-lines=2C then if multiple me= dia types are multiplexed then SSRC is the only remaining de-multiplex poin= t=2C so SSRC declaration is required).

Also=2C tunnelling proposals= can be used to address some of the ICE performance issues as well. =3B= There is really no intrinsic reason why those kind of proposals can't be u= sed to allow multiple endpoints to share a TURN allocation=2C for example= =2C removing TURN as a performance bottleneck without requiring Trickle ICE= .

>=3B From: eckelcu@c= isco.com
>=3B To: worley@ariadne.com=3B mmusic@ietf.org
>=3B Date= : Fri=2C 22 Feb 2013 21:39:23 +0000
>=3B Subject: Re: [MMUSIC] Another= bundling proposal
>=3B
>=3B Hi Dale=2C
>=3B
>=3B You= r proposal has some very nice properties=3B however=2C my concern with the = overall approach is that I fear the initial offer will not be handled very = well by typical pre-BUMDLE implementations. Due to the port being '9' and t= he connection address being 0.0.0.0=2C I would expect either:
>=3B 1) = a re-INVITE is needed for things to be renegotiated (best case)
>=3B 2= ) the call fails (worst case)
>=3B Of course other variations between = the best and worst case could happen=2C but the odds of arriving at the wor= st case seem unacceptably high to me. That is just my 2 cents without actua= lly testing anything to validate it. I'd like to hear what others think.>=3B
>=3B Cheers=2C
>=3B Charles
>=3B
>=3B
>= =3B >=3B -----Original Message-----
>=3B >=3B From: mmusic-bounces= @ietf.org [mailto:mmusic-bounces@ietf.org] On
>=3B >=3B Behalf Of Da= le R. Worley
>=3B >=3B Sent: Friday=2C February 22=2C 2013 1:06 PM>=3B >=3B To: mmusic@ietf.org
>=3B >=3B Subject: [MMUSIC] Anot= her bundling proposal
>=3B >=3B
>=3B >=3B I've written an al= ternative bundling proposal which I think manages
>=3B >=3B the prob= lems of bundling better.
>=3B >=3B
>=3B >=3B A series of tut= orial examples are here:
>=3B >=3B http://tools.ietf.org/html/draft-= worley-sdp-bundle-02#section-4
>=3B >=3B so it's easy to see how the= proposal works.
>=3B >=3B
>=3B >=3B Distinctive features of= this proposal are:
>=3B >=3B
>=3B >=3B - A separate m=3D li= ne describes the bundled media=2C allowing unambiguous
>=3B >=3B a= ttribution of attributes to either the bundle or a constituent=2C and
&g= t=3B >=3B independent rejection of each constituent.
>=3B >=3B <= br>>=3B >=3B - Backward compatibility is achieved straightforwardly.>=3B >=3B
>=3B >=3B - Multiplexed media flows are attributed t= o their original constituent
>=3B >=3B media descriptions without = requiring each to be declared
>=3B >=3B individually in the SDP.>=3B >=3B
>=3B >=3B - The multiplexed media flow is artificia= lly given the media type
>=3B >=3B "audio" to prevent rejection by= SBCs.
>=3B >=3B
>=3B >=3B - An encapsulating RTP format is = used so demultiplexing can be done
>=3B >=3B without coordinating = payload types between media descriptions=2C and
>=3B >=3B to ensur= e the bundled media description is rejected by
>=3B >=3B non-suppo= rting endpoints.
>=3B >=3B
>=3B >=3B - Zero/non-zero ports a= nd valid/null addresses are controlled to avoid
>=3B >=3B duplicat= e port usage=2C and to ensure SBCs see exactly the media flows
>=3B &g= t=3B specified by the SDP.
>=3B >=3B
>=3B >=3B
>=3B = >=3B
>=3B >=3B Filename: draft-worley-sdp-bundle
>=3B >= =3B Revision: 02
>=3B >=3B Title: Kumquat: A Generic Bundle Mecha= nism for the Session
>=3B >=3B Description Protocol (SDP)
>=3B = >=3B Creation date: 2013-02-22
>=3B >=3B Group: Individual Subm= ission
>=3B >=3B Number of pages: 27
>=3B >=3B URL: = http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-
>=3B &= gt=3B 02.txt
>=3B >=3B Status: http://datatracker.ietf.org/= doc/draft-worley-sdp-bundle
>=3B >=3B Htmlized: http://tools.= ietf.org/html/draft-worley-sdp-bundle-02
>=3B >=3B Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-worley-sdp-bundle-02
>=3B >= =3B
>=3B >=3B Abstract:
>=3B >=3B This document defines a= generic bundle mechanism for the Session
>=3B >=3B Description P= rotocol (SDP) by which the media described by a number
>=3B >=3B = of media descriptions ("m=3D lines") are multiplexed and transmitted
>= =3B >=3B over a single transport association. The transport associati= on is
>=3B >=3B described by an additional media description=2C a= llowing SDP attributes
>=3B >=3B to be applied to the aggregate= =2C independently of attributes applied
>=3B >=3B to the constitu= ents. In offer/answer usage=2C the bundle mechanism is
>=3B >=3B = backward compatible with SDP processors that do not understand the
>= =3B >=3B mechanism. The mechanism is designed to be compatible with t= he
>=3B >=3B limitations of the existing Internet infrastructure.=
>=3B >=3B _______________________________________________
>=3B= >=3B mmusic mailing list
>=3B >=3B mmusic@ietf.org
>=3B >= =3B https://www.ietf.org/mailman/listinfo/mmusic
>=3B ________________= _______________________________
>=3B mmusic mailing list
>=3B mmu= sic@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/mmusic
= --_0fe1ee6b-a1b5-48f9-a605-b0a902f0cb45_-- From pkyzivat@alum.mit.edu Sat Feb 23 18:50:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29821F8FAE for ; Sat, 23 Feb 2013 18:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XijfqZ07LeSp for ; Sat, 23 Feb 2013 18:50:08 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4973B21F8F61 for ; Sat, 23 Feb 2013 18:50:08 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 42lf1l0040cQ2SLAB2q8vD; Sun, 24 Feb 2013 02:50:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([125.122.241.79]) by omta10.emeryville.ca.mail.comcast.net with comcast id 42nw1l00e1jVNfx8W2o08v; Sun, 24 Feb 2013 02:48:06 +0000 Message-ID: <51297F5C.8060207@alum.mit.edu> Date: Sat, 23 Feb 2013 21:47:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> In-Reply-To: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361674208; bh=JGEnxZ9aDGUi7cn7yWyAO9eVYTEDYyA2PTw826JfFdY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G0Z1hI8LUNrcnN619zF6/xzKSZhBddo7dBEIEKwrc56fm9gmwz7lyWvMGgWJnESYv 1H9fD9xQSOSmav5dj0yAYCNu8E1xcY88FjlmSWjqRJjZMEgrjia2iz8mTgKNA9soYP ZEryQxNo56ohrT6UxsNq08BN72AN1hU4fb+fjh0sdofcWjq5KeI2NlEgEb+pN8bmy4 R6FjmhQZGZ+AGr9/dyIV5R47mED4k7XG7vE+shtVjDNLb1hptrNK7ThtS63Xkrdiyp kvenm3x7GVYOwMpdOOngQ/m59pq5L1TGUdqxKlL00CmWu8xIzJtWIcqv3wosNCULvN sex9pJEMTCcng== Subject: Re: [MMUSIC] Another bundling proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 02:50:09 -0000 This is an interesting approach, though Bernard's comments need to be considered. One observation is that this introduces a new level of multiplexing based on a special codec. While it can work, there is already a proposal on the table for multiplexing multiple RTP sessions on a single 5-tuple: draft-westerlund-avtcore-transport-multiplexing-04. ISTM that this new bundling proposal could be adapted to use that multiplexing technique. Bernard already raised issues about port 9 and address 0.0.0.0. I'll add that when this is done for multiple m-lines we stand some chance of getting errors due to reusing the same transport address. AFAIK there is no particular reason to use port 9 in this case, so perhaps it would be safer to use a different non-zero port in each such line. I had originally found little reason to pursue draft-westerlund-avtcore-transport-multiplexing-04, but now I start to think that this provides an answer to the problem of demuxing without having to specify SSRCs or restrict payload types. I think it could be used, rather than an RTP header extension, to specify capture-encodings for clue. (But it can't specify mapping to multiple capture-encodings.) Thanks, Paul On 2/22/13 4:05 PM, Dale R. Worley wrote: > I've written an alternative bundling proposal which I think manages > the problems of bundling better. > > A series of tutorial examples are here: > http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 > so it's easy to see how the proposal works. > > Distinctive features of this proposal are: > > - A separate m= line describes the bundled media, allowing unambiguous > attribution of attributes to either the bundle or a constituent, and > independent rejection of each constituent. > > - Backward compatibility is achieved straightforwardly. > > - Multiplexed media flows are attributed to their original constituent > media descriptions without requiring each to be declared > individually in the SDP. > > - The multiplexed media flow is artificially given the media type > "audio" to prevent rejection by SBCs. > > - An encapsulating RTP format is used so demultiplexing can be done > without coordinating payload types between media descriptions, and > to ensure the bundled media description is rejected by > non-supporting endpoints. > > - Zero/non-zero ports and valid/null addresses are controlled to avoid > duplicate port usage, and to ensure SBCs see exactly the media flows > specified by the SDP. > > > > Filename: draft-worley-sdp-bundle > Revision: 02 > Title: Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP) > Creation date: 2013-02-22 > Group: Individual Submission > Number of pages: 27 > URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-02.txt > Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle > Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02 > > Abstract: > This document defines a generic bundle mechanism for the Session > Description Protocol (SDP) by which the media described by a number > of media descriptions ("m= lines") are multiplexed and transmitted > over a single transport association. The transport association is > described by an additional media description, allowing SDP attributes > to be applied to the aggregate, independently of attributes applied > to the constituents. In offer/answer usage, the bundle mechanism is > backward compatible with SDP processors that do not understand the > mechanism. The mechanism is designed to be compatible with the > limitations of the existing Internet infrastructure. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Sat Feb 23 23:14:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FE721F8FE9 for ; Sat, 23 Feb 2013 23:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlqkdqgtD3Pt for ; Sat, 23 Feb 2013 23:14:20 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8549B21F8FE8 for ; Sat, 23 Feb 2013 23:14:18 -0800 (PST) Received: from BLU160-W49 ([65.55.116.73]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 23 Feb 2013 23:14:18 -0800 X-EIP: [6S9ouhMBHx2upirXlE77oKA/xpC7XXJQ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ced18e30-2242-41f0-93e7-d9284ff74c17_" From: Bernard Aboba To: Paul Kyzivat , "mmusic@ietf.org" Date: Sat, 23 Feb 2013 23:14:17 -0800 Importance: Normal In-Reply-To: <51297F5C.8060207@alum.mit.edu> References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com>, <51297F5C.8060207@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2013 07:14:18.0519 (UTC) FILETIME=[8F90F270:01CE125E] Subject: Re: [MMUSIC] Another bundling proposal (and why you can't neglect RTP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 07:14:21 -0000 --_ced18e30-2242-41f0-93e7-d9284ff74c17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:=20 > I had originally found little reason to pursue=20 > draft-westerlund-avtcore-transport-multiplexing-04=2C but now I start to= =20 > think that this provides an answer to the problem of demuxing without=20 > having to specify SSRCs or restrict payload types. I think it could be=20 > used=2C rather than an RTP header extension=2C to specify capture-encodin= gs=20 > for clue. (But it can't specify mapping to multiple capture-encodings.) [BA] Yes=2C I've also begun to wonder if we haven't been giving that (and p= ossibly) other transport multiplexing approaches insufficient consideration. A/V=20 multiplexing isn't just an SDP issue=2C it is also an RTP issue. Say we do= n't specify SSRCs and instead require that the payload type is unique among=20 all multiplexed m=3D lines so we can use PT to de-multiplex incoming RTP.=20 Without specifying SSRCs=2C how do we map the RTCP reports=2C which only include SSRCs and not payload types to the appropriate media=20 stream tracks? It seems to me that Cullen's "Plan A" has a fundamental flaw. =20 = --_ced18e30-2242-41f0-93e7-d9284ff74c17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul said:

>=3B I had originally found little reason = to pursue
>=3B draft-westerlund-avtcore-transport-multiplexing-04=2C = but now I start to
>=3B think that this provides an answer to the pro= blem of demuxing without
>=3B having to specify SSRCs or restrict pay= load types. I think it could be
>=3B used=2C rather than an RTP heade= r extension=2C to specify capture-encodings
>=3B for clue. (But it ca= n't specify mapping to multiple capture-encodings.)

[BA] Yes=2C I've= also begun to wonder if we haven't been giving that (and possibly)
othe= r transport multiplexing approaches insufficient consideration. =3B A/V=
multiplexing isn't just an SDP issue=2C it is also an RTP issue. = =3B Say we don't
specify SSRCs and instead require that the payload type= is unique among
all multiplexed m=3D lines so we can use PT to de-mult= iplex incoming RTP.
Without specifying SSRCs=2C how do we map the RTCP = reports=2C which
only include SSRCs and not payload types to the appropr= iate media
stream tracks? =3B =3B It seems to me that Cullen's = "Plan A" has a fundamental
flaw. =3B

= --_ced18e30-2242-41f0-93e7-d9284ff74c17_-- From abegen@cisco.com Sun Feb 24 13:55:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9D21F90FB for ; Sun, 24 Feb 2013 13:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxhPm3hfuBgq for ; Sun, 24 Feb 2013 13:54:57 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 606CB21F90F9 for ; Sun, 24 Feb 2013 13:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1825; q=dns/txt; s=iport; t=1361742895; x=1362952495; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TFmuNc6VlT+Wq7EhB/bYBfMiYqIBQMzIO9uAJikwC+A=; b=g+dkHxbbB8CMRgT5FzXPtKjXtWwnOLlj7ZSKIlQvQiBPhoIQ9PzUajfw MickMmLG1ey3OnXwLf2mo+xIPd/iNvgZneCToKQH35dX0aWUrQR7f7tkN LDDXowbq8AuggwGwBqs6m4NHduU19K0ItBSRZ8Mxt20G7Yl3y1P460y95 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN6KKlGtJXG9/2dsb2JhbABFgma+aoERFnOCIQEEJxM/EgEqFEInBA4NAYgKAQu8Z45dMQKCZGEDpyKDB4In X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; d="scan'208";a="180632572" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 24 Feb 2013 21:54:55 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1OLssvZ020225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Feb 2013 21:54:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 15:54:54 -0600 From: "Ali C. Begen (abegen)" To: "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 Thread-Index: AQHOEtmU4++bSb9NUky+3cwP5OU1Ow== Date: Sun, 24 Feb 2013 21:54:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.246.155] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 21:55:01 -0000 I am the assigned SDP directorate reviewer for this draft. For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: -------- - The RTCP XR extension syntax looks fine - There is one (small) technical issue - There are quite a few editorial issues Technical Issues: ----------------- 1) I am puzzled why you named the new block as "non-psi-ts-decodability". It does not follow what you have in the title. I also did not get the "non" part. Editorial Issues: ----------------- 1) I don't have the ISO document handy but I think the container is called MPEG2 Transport Stream not MPEG Transport Stream. Please double check. 2) The abstract mentions the use of broadcast of transport streams in IPTV systems. IPTV uses only unicast and multicast. Cable and satellite systems use the broadcast of transport streams. 3) Document's short name is "RTCP XR Non PSI Decodability". Why? 4) The title has "metric" but the abstract has "metrics." Please be consistent. 5) Section 1.1. "application-dependant" -> "application-dependent" 6) Use either "decodability" or "de-codability". 7) Section 1.4. AFAIK, there is no such thing called "MPEG4 TS content." The content could be encoded with MPEG4 but the transport stream is still MPEG2 Transport Stream. So, you could say "MPEG4 over MPEG2-TS over RTP." 8) The text seems to be using both "MPEG TS PSI Independent decodability statistics metrics" and "MPEG-TS PSI Independent Decodability Metrics". I think you need the former. 9) There are several typos (mostly due to copy/paste errors). Please fix them. Acknowledgements section also has misspellings and typos. From fluffy@cisco.com Sun Feb 24 16:21:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA9E21F9158 for ; Sun, 24 Feb 2013 16:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aH1qs7tu50U for ; Sun, 24 Feb 2013 16:21:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B587421F9153 for ; Sun, 24 Feb 2013 16:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1719; q=dns/txt; s=iport; t=1361751716; x=1362961316; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=49npUld/IuXEotdSHiHXsrf4ohC0s73X9GuA/GhYxy0=; b=MAD5QE+GwBxGbh7t2lQG1QGm1o3Qb0WuDLUOFGWXj6m3rRRAEVLFW4x8 +kqLuc0UY3ssbLnUjzAGdcIbqD58bccUrcPCSyQomXkhop449ZgUOEbMD +U3ZGEHyUSm0nvbcyGiyEXLzhY0p8J26FUqEAWh10QXt+kI99uuaL2GCD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAK2tKlGtJV2a/2dsb2JhbABFg3i9WIERFnOCHwEBAQMBeQULAgEZAwECCyQyHQgCBA4FCAGIBAYHBbx5jl0mCw2CWWEDl1qPSIMHgic X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; d="scan'208";a="180647134" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 25 Feb 2013 00:21:54 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1P0LsJn010882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 00:21:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 18:21:54 -0600 From: "Cullen Jennings (fluffy)" To: mmusic WG Thread-Topic: draft-nandakumar-mmusic-sdp-mux-attributes-01 Thread-Index: AQHOEu4cya7isLHcfEaLhEBoe/nFaw== Date: Mon, 25 Feb 2013 00:21:53 +0000 Message-ID: References: <20130225002024.16446.6193.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5B19844B2F0A4A4494EADA5B9B776880@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Suhas Nandakumar \(snandaku\)" Subject: [MMUSIC] draft-nandakumar-mmusic-sdp-mux-attributes-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 00:21:57 -0000 FYI =85 Very minimal changes from the -00=20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nandakumar-mmusic-sdp-mux-att= ributes-01.txt > Date: February 24, 2013 5:20:24 PM MST > To: fluffy@iii.ca > Cc: snandaku@cisco.com >=20 >=20 > A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-01.txt > has been successfully submitted by Cullen Jennings and posted to the > IETF repository. >=20 > Filename: draft-nandakumar-mmusic-sdp-mux-attributes > Revision: 01 > Title: A Framework for SDP Attributes when Multiplexing > Creation date: 2013-02-24 > Group: Individual Submission > Number of pages: 52 > URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmu= sic-sdp-mux-attributes-01.txt > Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-= sdp-mux-attributes > Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-m= ux-attributes-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-nandakumar-mmus= ic-sdp-mux-attributes-01 >=20 > Abstract: > Communication sessions in RTCWeb are described and negotiated using > Session Description Protocol(SDP)[RFC4566] mechanisms. SDP uses > attributes to describes specific aspects of such a session. These > attributes have different impacts when using varions of multiplexing > RTP on a single transport layer flow. The scope of this > specification is to provide a framework for analyzing the multiplex > characteristics for SDP attributes and provide multiplexing > characteristics of existing attributes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From worley@shell01.TheWorld.com Sun Feb 24 17:39:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6B21F90D6 for ; Sun, 24 Feb 2013 17:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqGRESX8O57B for ; Sun, 24 Feb 2013 17:39:17 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B24D021F90C4 for ; Sun, 24 Feb 2013 17:39:17 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1P1d2AO007242; Sun, 24 Feb 2013 20:39:04 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1P1d1KU2545998; Sun, 24 Feb 2013 20:39:01 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1P1d1ms2542268; Sun, 24 Feb 2013 20:39:01 -0500 (EST) Date: Sun, 24 Feb 2013 20:39:01 -0500 (EST) Message-Id: <201302250139.r1P1d1ms2542268@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Harald Alvestrand In-reply-to: <51263661.3060307@alvestrand.no> (harald@alvestrand.no) References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> <51263661.3060307@alvestrand.no> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:39:18 -0000 > From: Harald Alvestrand > > Designing around intermediaries that pass along information that they do > not understand, and then expect to act independently based on the > message that they partially understood, seems to me to be a quite > limiting approach. If we're going to succeed, we've got to be aware of the environment in which the solution operates. In principle, intermediate systems should operate transparently, but they don't. > We discussed this at the interim (I think Cullen was pretty vocal that > there's a limit to how much brokenness we can design around, and he > thought intermediaries passing BUNDLE without understanding BUNDLE were > clearly beyond that limit). Maybe Cullen was vocal about that, but he also points out that C***o NATs *have* to pay attention to the port numbers in media descriptions, so they enforce the uniqueness of port assignments. Because of problems like this, four of the "compatibility desiderata" I included in my proposal document the behavior of middleboxes we have to tolerate. (http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-3.2) Dale From worley@shell01.TheWorld.com Sun Feb 24 17:40:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85121F90D6 for ; Sun, 24 Feb 2013 17:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7LhnswC479y for ; Sun, 24 Feb 2013 17:40:01 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90E21F90C4 for ; Sun, 24 Feb 2013 17:40:01 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1P1dmAk008784 for ; Sun, 24 Feb 2013 20:39:50 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1P1dm2q2543936 for ; Sun, 24 Feb 2013 20:39:48 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1P1dlah2542586; Sun, 24 Feb 2013 20:39:47 -0500 (EST) Date: Sun, 24 Feb 2013 20:39:47 -0500 (EST) Message-Id: <201302250139.r1P1dlah2542586@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Design feature chart for bundling proposals X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 01:40:02 -0000 I've submitted a revision of my draft, draft-worley-sdp-bundle-03. The proposed bundling mechanism is unchanged (although it will need to be improved, based on the feedback I've received). The useful part of the new version is a draft of a design feature comparison chart for the current bundling proposals. (6 that I've found so far!) The chart can be found at http://tools.ietf.org/html/draft-worley-sdp-bundle-03#section-7 (I'd welcome any corrections or additions to the chart.) The entire draft is at http://tools.ietf.org/html/draft-worley-sdp-bundle-03 Here is a copy of the chart itself (more detailed notes in the draft itself): 7. Design Features and Comparison Key: x = feature present in proposal - = feature not present in proposal . = feature not discussed in proposal N/A = feature is not relevant because of another feature choice worley-sdp-bundle-03 (KUMQUAT) | ietf-mmusic-sdp-bundle-negotiation-03 (BUNDLE) | | holmberg-mmusic-sdp-mmt-negotiation-00 (MMT) | | | alvestrand-one-rtp-02 (TOGETHER) | | | | ejzak-mmusic-bundle-alternatives-00 | | | | | Roach alternative 1a | | | | | |(roach-mmusic-mlines-00) | | | | | | Roach alternative 1b | | | | | | | Roach alternative 2 | | | | | | | | westerlund-avtcore- | | | | | | | | |transport-multiplexing-04 | | | | | | | | |(SHIM) V V V V V V V V V MD grouping: one - - - - - - x - - per type - - - - - x - - - none x x x x x - - x x Separate bundle MD: no - x - x x x x x x m=anymedia - - x - - - - - - m=audio x - - - - - - - - m=multipart - - - - - - - - - Ports in constituent MDs in offer: N/A - - - - - x x - - same - - - x x - - x x different - x x - x - - - - null x - - - - - - - - Immediate update: none - - x x x x x x x for support - x - - - - - - - for compat. x - - - - - - - - Constituent MD ports after establishment: N/A - - - - - x x - - same - x - x - - - x x different - - - - - - - - - null - - - - - - - - - rejected x - x - x - - - - Bundle MD payload types: N/A - - - - - x x - - one MD - x - x . - - x x all MDs - - x - . - - - - encap. x - - - . - - - - Constituent MD payload types: N/A - - - - - x x - - overlapping x - - - . - - x x distinct - x x x . - - - - Demultiplexing based on: N/A - - - - - x x - - PT - x x x . - - - - encap. x - - - . - - x x Rejection of bundle MD based on: N/A - x - x x x x x x media type - - x - - - - - - codec x - - - - - - - - Dale From rachel.huang@huawei.com Mon Feb 25 00:28:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30221F925C for ; Mon, 25 Feb 2013 00:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsZNmkAhFqtm for ; Mon, 25 Feb 2013 00:28:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 45DAD21F9032 for ; Mon, 25 Feb 2013 00:28:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT54339; Mon, 25 Feb 2013 08:28:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 08:27:38 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 08:28:27 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 25 Feb 2013 16:28:22 +0800 From: "Huangyihong (Rachel)" To: "Ali C. Begen (abegen)" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 Thread-Index: AQHOEtmU4++bSb9NUky+3cwP5OU1O5iKPXwQ Date: Mon, 25 Feb 2013 08:28:22 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4571C024@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:28:30 -0000 Dear Ali, Thank you for the review. Please see inline. Best Regards! Rachel -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Ali C. Begen (abegen) Sent: Monday, February 25, 2013 5:55 AM To: draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org Cc: mmusic@ietf.org; gonzalo.camarillo@ericsson.com Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-dec= odability-07 I am the assigned SDP directorate reviewer for this draft. For background on the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: -------- - The RTCP XR extension syntax looks fine - There is one (small) technical issue - There are quite a few editorial issues Technical Issues: ----------------- 1) I am puzzled why you named the new block as "non-psi-ts-decodability". It does not follow what you have in the title. I also did not get the "non" part. [Rachel]: To get consistent with the title we used, how about we propose to= change the block name in SDP as "ts-psi-indep-decodability"? Editorial Issues: ----------------- 1) I don't have the ISO document handy but I think the container is called MPEG2 Transport Stream not MPEG Transport Stream. Please double check. [Rachel]: Okay. Thanks. 2) The abstract mentions the use of broadcast of transport streams in IPTV systems. IPTV uses only unicast and multicast. Cable and satellite systems use the broadcast of transport streams. [Rachel]: Okay. Will fix this. 3) Document's short name is "RTCP XR Non PSI Decodability". Why? [Rachel]: Will be changed to "RTCP XR PSI Independent Decodability". 4) The title has "metric" but the abstract has "metrics." Please be consistent. [Rachel]:Okay. 5) Section 1.1. "application-dependant" -> "application-dependent" [Rachel]:Okay. 6) Use either "decodability" or "de-codability". [Rachel]:Okay. 7) Section 1.4. AFAIK, there is no such thing called "MPEG4 TS content." The content could be encoded with MPEG4 but the transport stream is still MPEG2 Transport Stream. So, you could say "MPEG4 over MPEG2-TS over RTP." [Rachel]:Right. 8) The text seems to be using both "MPEG TS PSI Independent decodability statistics metrics" and "MPEG-TS PSI Independent Decodability Metrics". I think you need the former. [Rachel]:Okay. 9) There are several typos (mostly due to copy/paste errors). Please fix them. Acknowledgements section also has misspellings and typos. [Rachel]: Will do. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon Feb 25 01:10:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78EC21F923A for ; Mon, 25 Feb 2013 01:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3I0D+1wBzlm for ; Mon, 25 Feb 2013 01:10:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78B21F9239 for ; Mon, 25 Feb 2013 01:09:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-a2-512b2a66cfe1 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.2B.10459.66A2B215; Mon, 25 Feb 2013 10:09:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:09:58 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "Harald Alvestrand" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) Thread-Index: AQHOEEQhUP7WLYIH+E+EYYvRtN1DsJiEg1+AgAE9WECAACNGgIAEandA Date: Mon, 25 Feb 2013 09:09:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B105B35@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FF4F0@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA6CDB@US70UWXCHMBA04.zam.alcatel-lucent.com> <51263661.3060307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F36EA6DB3@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1049E9@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA704E@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA704E@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW6alnagwZn32hbH+rrYLKYuf8xi 0dsQ7sDs0fpsL6vHlQlXWD2WLPnJFMAcxWWTkpqTWZZapG+XwJUxrfkaS8Fu3oqGF/eZGxhf cnUxcnJICJhIbOv4ygZhi0lcuLceyObiEBI4xCjxcn0PE4SzmFFi3+5DQA4HB5uAhUT3P22Q BhGBaYwSi/eXgtQICyxnlNj56xVYt4jACkaJJXvfsUNUuUlsn7uGEcRmEVCVmHZwEQvIIF4B b4lN0yshFixnk9i59j8rSJxTIFai7Yg9SDkj0EXfT61hArGZBcQlbj2ZzwRxqYDEkj3nmSFs UYmXj/+xQtiKElenL4eq15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUnYVk7CwkLbOQtMxC 0rKAkWUVI3tuYmZOernhJkZgfBzc8lt3B+OpcyKHGKU5WJTEecNcLwQICaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYNTZ7/Aqa5lz0fGaNS4p84yZCoJKF5dcrhGsSj9cMFN1787KdRH7/ut+ +Ly+aYWLool4+zHnrdkcfUUBhkkCzZfL+ydvyl23g1PmplV68YGq8KKu1Vf+zrTLFP7UKvP+ 05dT998J7z14+Y/QmQtxE/5sPrH4IP+0Q28PHA43rshgO37D+6Z2pYESS3FGoqEWc1FxIgCl ol1rXQIAAA== Subject: Re: [MMUSIC] Requiring support for nonconformant intermediate systems (Re: FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:10:00 -0000 Hi Richard, >> Your solution expects the intermediary to understand that, eventhough=20 >> the addresses for all-but-one m- lines are unspecified, media=20 >> associated with those m- lines will still be sent - using the port of=20 >> another m- line. > > But this requirement is only placed on intermediaries that have already i= ndicated support for BUNDLE by forwarding=20 > the related attributes. The unspecified address only needs to be include= d in the SDP answer, and not the offer, so it=20 > is returned within an established dialog, and there is no danger of sendi= ng it to an unknown intermediary. >=20 >> I still strongly think that sending media associated with m- lines,=20 >> for which the address is unspecified, is a design error. > > I'm not sure how the term "design error" applies to a solution that behav= es correctly and consistently under the given=20 > assumptions (there are other aspects to be fixed but bear with me for sak= e of argument). It is true that I propose to=20 > clarify the meaning of unspecified address in the presence of BUNDLE, whi= ch is a new and as yet non-standardized=20 > concept. There are many examples of such "clarifications" as we expand t= he capabilities that can be represented=20 > in SDP. The key is backward compatibility. If the concern is about inte= rmediaries that forward BUNDLE attributes=20 > without understanding them, then there is little that can be done anyway. There are intermediaries that do not modify SDP - they simply look at the a= ddress information in order to open gates etc. But, my comment is not related to intermediaries: I think it's an general S= DP design error. Regards, Christer From abegen@cisco.com Mon Feb 25 01:49:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987B421F8EFF; Mon, 25 Feb 2013 01:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjMTFY2PhJNp; Mon, 25 Feb 2013 01:49:01 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7F21F8EC2; Mon, 25 Feb 2013 01:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1361785741; x=1362995341; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/jkjZT5Jl+rsSJQzr7xuc6u0SeUqYLtUGmQIPERs8R0=; b=CigSdcDrB9Sd4TgrNne3MQDkRfNGjFT8hbRKjJEVyXENx8wtODgUapOw SYmnuKnKIx1P0PcrKRbY7B6VyrE6Gxn0QVn6M3c1C3P/RKGcQsEXkOVFH n4p3ikUXG1218zCgoLkI4eCnrX0s/xDWPkFrCVeqPE7I9Dd5mHtEYlFrF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEoyK1GtJV2c/2dsb2JhbABFgma+bYEEFnOCHwEBAQR5DAYBCBEDAQILVh0IAgQBDQUIiAsBvVeOXSYLBwaCWWEDpyKBUoE1gic X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="scan'208";a="180741544" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 25 Feb 2013 09:49:00 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1P9n0od022611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 09:49:00 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 03:49:00 -0600 From: "Ali C. Begen (abegen)" To: "Huangyihong (Rachel)" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 Thread-Index: AQHOEtmU4++bSb9NUky+3cwP5OU1O5iKPXwQgACdmIA= Date: Mon, 25 Feb 2013 09:48:59 +0000 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4571C024@nkgeml501-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.246.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <03C80CE1C8B1C242AA717E317EFE11C9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "xrblock@ietf.org" , "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:49:02 -0000 -----Original Message----- From: "Huangyihong (Rachel)" Date: Monday, February 25, 2013 3:28 AM To: "Ali C. Begen" , "draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org" Cc: "mmusic@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: RE: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 >Technical Issues: >----------------- >1) I am puzzled why you named the new block as "non-psi-ts-decodability". >It does not follow what you have in the title. I also did not get the >"non" part. > >[Rachel]: To get consistent with the title we used, how about we propose >to change the block name in SDP as "ts-psi-indep-decodability"? I see that you already submitted a revision. Your current title says: RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Program Specific Information (PSI) Independent Transport Stream (TS) Decodability Statistics Metric reporting This still does not make sense to me. "Transport Stream" should be before "Program Specific Information". My other comment on the title was it should be "=8A Metrics Reporting" not "Metric reporting". -acbegen From bill.wu@huawei.com Mon Feb 25 02:41:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7434021F927D; Mon, 25 Feb 2013 02:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.033 X-Spam-Level: X-Spam-Status: No, score=-5.033 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zG6E4DufUop; Mon, 25 Feb 2013 02:41:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC7C21F9240; Mon, 25 Feb 2013 02:41:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT68663; Mon, 25 Feb 2013 10:41:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 10:41:24 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 10:41:24 +0000 Received: from w53375 (10.138.41.149) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 18:41:10 +0800 Message-ID: <3F9803778CF045B8BF27AD752032EB92@china.huawei.com> From: Qin Wu To: "Ali C. Begen (abegen)" , "Huangyihong (Rachel)" , References: Date: Mon, 25 Feb 2013 18:41:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: mmusic@ietf.org, xrblock@ietf.org Subject: Re: [MMUSIC] [xrblock] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-decodability-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:41:37 -0000 Rml4ZWQuDQpUaGUgZGlmZiBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRlY29kYWJpbGl0eS0wOQ0KDQpSZWdhcmRzIQ0KLVFp bg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGkgQy4gQmVnZW4gKGFi ZWdlbikiIDxhYmVnZW5AY2lzY28uY29tPg0KVG86ICJIdWFuZ3lpaG9uZyAoUmFjaGVsKSIgPHJh Y2hlbC5odWFuZ0BodWF3ZWkuY29tPjsgPGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRlY29k YWJpbGl0eUB0b29scy5pZXRmLm9yZz4NCkNjOiA8eHJibG9ja0BpZXRmLm9yZz47IDxtbXVzaWNA aWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDU6NDggUE0NClN1Ympl Y3Q6IFJlOiBbeHJibG9ja10gW01NVVNJQ10gU0RQIERpcmVjdG9yYXRlOiBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGVjb2RhYmlsaXR5LTA3DQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206ICJIdWFuZ3lpaG9uZyAgIChSYWNoZWwpIiA8cmFjaGVsLmh1 YW5nQGh1YXdlaS5jb20+DQpEYXRlOiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDM6MjggQU0N ClRvOiAiQWxpIEMuIEJlZ2VuIiA8YWJlZ2VuQGNpc2NvLmNvbT4sDQoiZHJhZnQtaWV0Zi14cmJs b2NrLXJ0Y3AteHItZGVjb2RhYmlsaXR5QHRvb2xzLmlldGYub3JnIg0KPGRyYWZ0LWlldGYteHJi bG9jay1ydGNwLXhyLWRlY29kYWJpbGl0eUB0b29scy5pZXRmLm9yZz4NCkNjOiAibW11c2ljQGll dGYub3JnIiA8bW11c2ljQGlldGYub3JnPiwgImdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNv bSINCjxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSRTogW01NVVNJ Q10gU0RQIERpcmVjdG9yYXRlOiBSZXZpZXcgb2YNCmRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhy LWRlY29kYWJpbGl0eS0wNw0KDQo+VGVjaG5pY2FsIElzc3VlczoNCj4tLS0tLS0tLS0tLS0tLS0t LQ0KPjEpIEkgYW0gcHV6emxlZCB3aHkgeW91IG5hbWVkIHRoZSBuZXcgYmxvY2sgYXMgIm5vbi1w c2ktdHMtZGVjb2RhYmlsaXR5Ii4NCj5JdCBkb2VzIG5vdCBmb2xsb3cgd2hhdCB5b3UgaGF2ZSBp biB0aGUgdGl0bGUuIEkgYWxzbyBkaWQgbm90IGdldCB0aGUNCj4ibm9uIiBwYXJ0Lg0KPg0KPltS YWNoZWxdOiBUbyBnZXQgY29uc2lzdGVudCB3aXRoIHRoZSB0aXRsZSB3ZSB1c2VkLCBob3cgYWJv dXQgd2UgcHJvcG9zZQ0KPnRvIGNoYW5nZSB0aGUgYmxvY2sgbmFtZSBpbiBTRFAgYXMgInRzLXBz aS1pbmRlcC1kZWNvZGFiaWxpdHkiPw0KDQpJIHNlZSB0aGF0IHlvdSBhbHJlYWR5IHN1Ym1pdHRl ZCBhIHJldmlzaW9uLiBZb3VyIGN1cnJlbnQgdGl0bGUgc2F5czoNCg0KUlRQIENvbnRyb2wgUHJv dG9jb2wgKFJUQ1ApIEV4dGVuZGVkIFJlcG9ydCAoWFIpIEJsb2NrIGZvciBNUEVHMiBQcm9ncmFt DQogICAgICBTcGVjaWZpYyBJbmZvcm1hdGlvbiAoUFNJKSBJbmRlcGVuZGVudCBUcmFuc3BvcnQg U3RyZWFtIChUUykNCiAgICAgICAgICAgICAgICBEZWNvZGFiaWxpdHkgU3RhdGlzdGljcyBNZXRy aWMgcmVwb3J0aW5nDQoNCg0KVGhpcyBzdGlsbCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1lLiAi VHJhbnNwb3J0IFN0cmVhbSIgc2hvdWxkIGJlIGJlZm9yZQ0KIlByb2dyYW0gU3BlY2lmaWMgSW5m b3JtYXRpb24iLiBNeSBvdGhlciBjb21tZW50IG9uIHRoZSB0aXRsZSB3YXMgaXQNCnNob3VsZCBi ZSAiiiBNZXRyaWNzIFJlcG9ydGluZyIgbm90ICJNZXRyaWMgcmVwb3J0aW5nIi4NCg0KLWFjYmVn ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnhy YmxvY2sgbWFpbGluZyBsaXN0DQp4cmJsb2NrQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3hyYmxvY2s= From christer.holmberg@ericsson.com Mon Feb 25 05:09:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB53D21F9301 for ; Mon, 25 Feb 2013 05:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fpf7qHNyZxw for ; Mon, 25 Feb 2013 05:09:26 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3A21F92EE for ; Mon, 25 Feb 2013 05:09:25 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-80-512b62844cfd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.03.19728.4826B215; Mon, 25 Feb 2013 14:09:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 14:09:23 +0100 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Another bundling proposal - Christer's comments Thread-Index: Ac4TVbJsbUziS577R021PX4477xAdw== Date: Mon, 25 Feb 2013 13:09:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW5Lknagwft/AhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyjh56i97wTGZitbJ3ewNjNPEuxg5OSQETCS2 7FnODGGLSVy4t56ti5GLQ0jgEKPEzrkPGSGcxYwSL2+9ZO1i5OBgE7CQ6P6nDdIgIuAnsX7V B3YQW1jAVWLZlsdMEHE3ieU991ggbD2J3f+2gsVZBFQlZjzYwQ4yhlfAW+LC9jSQMCPQ3u+n 1oCVMAuIS9x6Mp8J4h4BiSV7zkPdJirx8vE/VghbUeLq9OVQ9ToSC3Z/YoOwtSWWLXwNVs8r IChxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQIDOuDW36r7mC8c07kEKM0 B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxR01e/3vTq0Vb9k2o7NjvY/HjB vUxd/suyyuaTTndNgwQfhBcur9v3mc3vQUCQ8SKrrUwf7W/IvuThC8y3K4tKiflZqxWbGXW1 d+r1hjmTDmVZRqxT3JufmuCQeDL5NdvB+YIXIx74cSxtzK060nFT5d6mBSEXWE/ZZ2k2XDD4 slDFsNtu2W8lluKMREMt5qLiRACpQAK8OQIAAA== Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 13:09:27 -0000 Hi, I had previously provided comments to Dale off-line. Some has been addresse= d in the -03 version of the draft. But, I still have some questions. First, unless I've missed something, the mechanism is still for RTP ONLY. I= t is not possible to e.g. put the DataChannel in the bundle. I think we asa= p need to decide whether that is a requirement or not. Second, you use the non-bundle m- lines for codec negotiation etc. But, pre= viously, when MMT was discussed, I believe that people indicated that they = do not want to "refer" to other m- lines from the MMT m- line. Instead, th= e information should be explicitly provided in the MMT m- line (which is th= e reason why the SDP size gets pretty big with MMT, as most information is = duplicated). Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dale R. Worley Sent: 22. helmikuuta 2013 23:06 To: mmusic@ietf.org Subject: [MMUSIC] Another bundling proposal I've written an alternative bundling proposal which I think manages the pro= blems of bundling better. A series of tutorial examples are here: http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4 so it's easy to see how the proposal works. Distinctive features of this proposal are: - A separate m=3D line describes the bundled media, allowing unambiguous attribution of attributes to either the bundle or a constituent, and independent rejection of each constituent. - Backward compatibility is achieved straightforwardly. - Multiplexed media flows are attributed to their original constituent media descriptions without requiring each to be declared individually in the SDP. - The multiplexed media flow is artificially given the media type "audio" to prevent rejection by SBCs. - An encapsulating RTP format is used so demultiplexing can be done without coordinating payload types between media descriptions, and to ensure the bundled media description is rejected by non-supporting endpoints. - Zero/non-zero ports and valid/null addresses are controlled to avoid duplicate port usage, and to ensure SBCs see exactly the media flows specified by the SDP. Filename: draft-worley-sdp-bundle Revision: 02 Title: Kumquat: A Generic Bundle Mechanism for the Session Description Pr= otocol (SDP) Creation date: 2013-02-22 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-worley-sdp-bundl= e-02.txt Status: http://datatracker.ietf.org/doc/draft-worley-sdp-bundle Htmlized: http://tools.ietf.org/html/draft-worley-sdp-bundle-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-worley-sdp-bundle= -02 Abstract: This document defines a generic bundle mechanism for the Session Description Protocol (SDP) by which the media described by a number of media descriptions ("m=3D lines") are multiplexed and transmitted over a single transport association. The transport association is described by an additional media description, allowing SDP attributes to be applied to the aggregate, independently of attributes applied to the constituents. In offer/answer usage, the bundle mechanism is backward compatible with SDP processors that do not understand the mechanism. The mechanism is designed to be compatible with the limitations of the existing Internet infrastructure. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Mon Feb 25 07:52:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB921F94EE for ; Mon, 25 Feb 2013 07:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.401 X-Spam-Level: X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuM2TvHGiHGt for ; Mon, 25 Feb 2013 07:52:24 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B23FB21F94EA for ; Mon, 25 Feb 2013 07:52:23 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1PFpaUP009628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Feb 2013 16:52:21 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 25 Feb 2013 16:52:17 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 25 Feb 2013 10:52:01 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: How does an answerer reject the first m line in a BUNDLE? Thread-Index: Ac4TcAvCwK41/QLkSeO9CjV5VrhQXA== Date: Mon, 25 Feb 2013 15:52:00 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA7424@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F36EA7424US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [MMUSIC] How does an answerer reject the first m line in a BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:52:25 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F36EA7424US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, In rereading your latest BUNDLE draft I was confused about what the answere= r does when it needs to reject the first m line in a bundle group. The fol= lowing text in your draft implies to me that the answerer is not allowed to= reject the first m line: "Until the SDP Answerer receives the new SDP Offer, which contains an identical port number value for each "m=3D" line associated with a "BUNDLE" group, it MUST use the port, and related information (ICE candidates, SDES keys etc) associated with the first "m=3D" line in the "BUNDLE" group." What does this text mean if the answerer rejects the first line? Doesn't t= his mean that the answerer must wait for the "new" SDP offer with identical= ports for each group member before it knows the 5-tuple to use for the bun= dle, thus delaying call setup? What does it mean to use SDES keys for a re= jected m line (since these keys should only apply to this m line). It may not be common to reject the first line but I think we have to allow = for it. BR, Richard --_000_03FBA798AC24E3498B74F47FD082A92F36EA7424US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

In rereading your latest BUNDLE draft I was confused= about what the answerer does when it needs to reject the first m line in a= bundle group.  The following text in your draft implies to me that th= e answerer is not allowed to reject the first m line:

 

“Until the SDP Answerer receives the new SDP Offer, which contains= an

   identical port number value for each "m=3D" line = associated with a

   "BUNDLE" group, it MUST use the port, and related= information (ICE

   candidates, SDES keys etc) associated with the first "= m=3D" line in the

   "BUNDLE" group.”

 

What does this text mean if the answerer rejects the= first line?  Doesn’t this mean that the answerer must wait for = the “new” SDP offer with identical ports for each group member = before it knows the 5-tuple to use for the bundle, thus delaying call setup?  What does it mean to use SDES keys for a rejected m line= (since these keys should only apply to this m line).

 

It may not be common to reject the first line but I = think we have to allow for it.

 

BR, Richard

--_000_03FBA798AC24E3498B74F47FD082A92F36EA7424US70UWXCHMBA04z_-- From ari.keranen@ericsson.com Mon Feb 25 10:28:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CE721E8055 for ; Mon, 25 Feb 2013 10:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEMt+clDCkuQ for ; Mon, 25 Feb 2013 10:28:13 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3C21F94C1 for ; Mon, 25 Feb 2013 10:28:11 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-65-512bad37974d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EA.D7.32353.73DAB215; Mon, 25 Feb 2013 19:28:08 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Feb 2013 19:28:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 706CB2AD1; Mon, 25 Feb 2013 20:28:06 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1CC2F54534; Mon, 25 Feb 2013 20:28:04 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A1A6854533; Mon, 25 Feb 2013 20:28:03 +0200 (EET) Message-ID: <512BAD35.70001@ericsson.com> Date: Mon, 25 Feb 2013 20:28:05 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic References: <20130225182332.31449.22945.idtracker@ietfa.amsl.com> In-Reply-To: <20130225182332.31449.22945.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130225182332.31449.22945.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvja7FWu1Ag6V/2C2any9jt5i6/DGL A5PHkiU/mTxa189kDGCK4rJJSc3JLEst0rdL4Mq4+fMHU8EXvoqe3RfYGhin8XQxcnJICJhI zHx+iBnCFpO4cG89G4gtJHCSUeLvcvMuRi4gewOjxJkfP1ggnF2MEl8unmKHcNYyShz42MwK 0bKcUWLhNy0Qm1dAU2LW7H/sIDaLgKrEmnnbWEBsNgFbidWvboLZogLJEv8eHWGEqBeUODnz CVhcREBGYu+mzWAnCQsEShw4dBrqJEeJVc/uAtVzcHAKOEks2+YFcbWvxIFne8FOYBawkFj8 5iA7hC0vsf3tHKjP1CSuntvEDDFGVeLqv1eMExhFZyHZPAtJ+ywk7QsYmVcxsucmZuakl5tv YgQG/cEtvw12MG66L3aIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxkox E+bDr2WP/tjdqs9/Q/V2w4mlR2ddbucVcDrHsM3X3+REYMy/5ZFbztbef35qz+r4Oq3qE+fZ bGU69y5LY//yWvpE+KsFaRVv3Rs6vOqfpq+tuMuXEnPstGbNNNmCiGv5uoVLF60Ozf5fcP3H /shyyRq2qJhi8wcRrq7s1Tt3T98attTbS4mlOCPRUIu5qDgRAE0UenNIAgAA Subject: [MMUSIC] Fwd: New Version Notification for draft-keranen-mmusic-rfc5245bis-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:28:14 -0000 Hi all, Here's the -01 version of the ICE-bis draft. This version has the SDP and SIP specific parts split to a separate document, as discussed at the Atlanta meeting. Work still remains to be done (E.g., should we use some other term instead of offer/answer? Should also all RTP specific text be (re)moved?), but in general, for the authors, this seems like the right approach. Give it a quick read (or at least check out the diff against -00), and let us know if the approach seems sensible to you too. Cheers, Ari (as individual) -------- Original Message -------- A new version of I-D, draft-keranen-mmusic-rfc5245bis-01.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-mmusic-rfc5245bis Revision: 01 Title: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Creation date: 2013-02-25 Group: Individual Submission Number of pages: 89 URL: http://www.ietf.org/internet-drafts/draft-keranen-mmusic-rfc5245bis-01.txt Status: http://datatracker.ietf.org/doc/draft-keranen-mmusic-rfc5245bis Htmlized: http://tools.ietf.org/html/draft-keranen-mmusic-rfc5245bis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-keranen-mmusic-rfc5245bis-01 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. From ari.keranen@ericsson.com Mon Feb 25 11:31:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A766C21F92AF for ; Mon, 25 Feb 2013 11:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5wYkOVNeZVb for ; Mon, 25 Feb 2013 11:31:22 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 41BB121F92B7 for ; Mon, 25 Feb 2013 11:31:20 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-a0-512bbc045172 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5D.4C.32353.40CBB215; Mon, 25 Feb 2013 20:31:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Feb 2013 20:31:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1AE012AD1 for ; Mon, 25 Feb 2013 21:31:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AB20054534 for ; Mon, 25 Feb 2013 21:31:13 +0200 (EET) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6438E54533 for ; Mon, 25 Feb 2013 21:31:13 +0200 (EET) Message-ID: <512BBC06.1080607@ericsson.com> Date: Mon, 25 Feb 2013 21:31:18 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic References: <20130225191050.10024.65674.idtracker@ietfa.amsl.com> In-Reply-To: <20130225191050.10024.65674.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130225191050.10024.65674.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvjS7LHu1Ag6sbNCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBUrljIXrOOqWHD8NHsD412OLkZODgkBE4mpMw4zQthiEhfu rWfrYuTiEBI4ySixbG0/K4SzgVGiZcFfdpAqIYELjBLNx2wh7MOMEgfOQXXsZZQ4sm4dK0iC V0Bb4uSfE2BjWQRUJfbP38IEYrMJ2EqsfnWTBcQWFUiWeNaymwmiXlDi5MwnYHERARmJvZs2 M4PYwgIREh2T50EtdpS4Ng/kCA4OTgEniSVr4kFMCQFfiStnxUAqmAUsJBa/OcgOYctLbH87 hxniMTWJq+c2MUNMUZW4+u8V4wRG0VlIFs9C0j4LSfsCRuZVjOy5iZk56eXmmxiB4X1wy2+D HYyb7osdYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFrgp+LeW0ZT7X+ xs3eCWrhKY6340xXL35fMHv+JMFergvhuUr8G+pqYlK6mGxdpkUX9EccOTdnS6L+hP1z3+3R rb+96EOiSWf/vziD6sdeTN2vnk138TvxzmHi6WWtz5a/vjm/0uFIsGTkmw/f7t0WjTm7pcBk WeLCG0/zZz4XlL7fLV/7R1uJpTgj0VCLuag4EQCmHtHwPQIAAA== Subject: [MMUSIC] Fwd: New Version Notification for draft-petithuguenin-mmusic-ice-sip-sdp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:31:33 -0000 Hi all, And here's the draft on how to use ICE-bis with SIP & SDP. It too is still very much work in progress (it's currently mostly cut-n-paste from ICE) but from this you should get the idea on how the split would roughly look like. Cheers, Ari (as individual) -------- Original Message -------- A new version of I-D, draft-petithuguenin-mmusic-ice-sip-sdp-01.txt has been successfully submitted by Marc Petit-Huguenin and posted to the IETF repository. Filename: draft-petithuguenin-mmusic-ice-sip-sdp Revision: 01 Title: Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Creation date: 2013-02-25 Group: Individual Submission Number of pages: 40 URL: http://www.ietf.org/internet-drafts/draft-petithuguenin-mmusic-ice-sip-sdp-01.txt Status: http://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-sip-sdp Htmlized: http://tools.ietf.org/html/draft-petithuguenin-mmusic-ice-sip-sdp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-petithuguenin-mmusic-ice-sip-sdp-01 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). From internet-drafts@ietf.org Mon Feb 25 12:00:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2521E812C; Mon, 25 Feb 2013 12:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNJF50Qr84Hy; Mon, 25 Feb 2013 12:00:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5325121E8107; Mon, 25 Feb 2013 11:59:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225195951.11107.50941.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:59:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:00:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : SDP: Session Description Protocol Author(s) : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-07.txt Pages : 49 Date : 2013-02-25 Abstract: 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. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Mon Feb 25 12:36:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784D621F9224 for ; Mon, 25 Feb 2013 12:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr0nq2z1PLRb for ; Mon, 25 Feb 2013 12:36:08 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0521E8084 for ; Mon, 25 Feb 2013 12:36:07 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-ed-512bcb36dc50 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 66.27.10459.63BCB215; Mon, 25 Feb 2013 21:36:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 21:36:06 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Thread-Topic: How does an answerer reject the first m line in a BUNDLE? Thread-Index: Ac4TcAvCwK41/QLkSeO9CjV5VrhQXAAJyxuT Date: Mon, 25 Feb 2013 20:36:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1077EC@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA7424@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA7424@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1077ECESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja7Zae1Ag0X/1S2mLn/MYtHbEO7A 5NH6bC+rx5IlP5kCmKK4bFJSczLLUov07RK4Mj4s+M1Y0Kpfcf/HXuYGxoPqXYycHBICJhLv G+6wQdhiEhfurQeyuTiEBA4xSsxp2A/lLGaUON1/BMjh4GATsJDo/qcN0iAikCWx9VQ/C4gt LOAmsfbUEzaIuLvEo6UfmCBsI4kVlz4zg9gsAqoS63/sAKvhFfCWmLjxBZgtJBAjsfHGFkYQ m1MgVuLKok6wmYxAB30/tQZsDrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1YIW1Fi59l2ZpAz mQXyJXY2q0OsEpQ4OfMJywRGkVlIJs1CqJqFpAqixEDi/bn5zBC2tsSyha+hbH2JjV/OMiKL L2BkX8XInpuYmZNebriJERg1B7f81t3BeOqcyCFGaQ4WJXHeMNcLAUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYGRX9hJ3efGkXnWQ2/fCMqkk9zCrSPX7nzJ+5773LypoyS5sp7+pKM5mW yxxef9s8wyZYNKkddt69zH7PsV3qZr7/Hu/xn6vFIrcx5NB8ab3NVdu0zJ+ITvwfqPjz8Oy4 uDVuG2qeP9vDmRG0trzQQaZV3bBXl0n1+C6r7Rs2Lu/sk1lxfOliJZbijERDLeai4kQA4Q2Z sWgCAAA= Subject: Re: [MMUSIC] How does an answerer reject the first m line in a BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:36:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1077ECESESSMB209ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >In rereading your latest BUNDLE draft I was confused about what the answer= er does when it needs to reject the first m line in a bundle group. The fo= llowing text in your draft implies to me that the answerer is not allowed t= o reject the first m line: > >=93Until the SDP Answerer receives the new SDP Offer, which contains an > identical port number value for each "m=3D" line associated with a > "BUNDLE" group, it MUST use the port, and related information (ICE > candidates, SDES keys etc) associated with the first "m=3D" line in the > "BUNDLE" group.=94 > >What does this text mean if the answerer rejects the first line? Doesn=92= t this mean that the answerer must wait for the =93new=94 SDP offer with id= entical ports for each group member before it knows the >5-tuple to use for the bundle, thus delaying call setup? What does it mea= n to use SDES keys for a rejected m line (since these keys should only appl= y to this m line). If the answerer rejects the first m- line, I guess it has to wait for the s= econd offer. Note that Charles suggested that the answerer shall always wait for the sec= ond offer anyway, so that's something that needs to be discussed. >It may not be common to reject the first line but I think we have to allow= for it. Absolutely. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1077ECESESSMB209ericsso_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

>In rereading your latest BUNDLE draft I was conf= used about what the answerer does when it needs to reject the first m line = in a bundle group.  The following text in your draft implies to me tha= t the answerer is not allowed to reject the first m line:

>

>= =93Until the SDP Answerer receives the new SDP Offer, which contains an

>&n= bsp;  identical port number value for each "m=3D" line assoc= iated with a

>&n= bsp;  "BUNDLE" group, it MUST use the port, and related info= rmation (ICE

>&n= bsp;  candidates, SDES keys etc) associated with the first "m=3D&= quot; line in the

>&n= bsp;  "BUNDLE" group.=94

>

>What does this text mean if the answerer rejects= the first line?  Doesn=92t this mean that the answerer must wait for = the =93new=94 SDP offer with identical ports for each group member before i= t knows the

>5-tuple to use for the bundle, thus delaying cal= l setup?  What does it mean to use SDES keys for a rejected m line (si= nce these keys should only apply to this m line).

 

If the answerer rejects the first m- line, I guess i= t has to wait for the second offer.

 

Note that Charles suggested that the answerer shall = always wait for the second offer anyway, so that's something that needs to = be discussed.

 

>It may not be common to reject the first line bu= t I think we have to allow for it.

 

Absolutely.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1077ECESESSMB209ericsso_-- From internet-drafts@ietf.org Mon Feb 25 13:20:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25121F938C; Mon, 25 Feb 2013 13:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu4j6yWveP64; Mon, 25 Feb 2013 13:20:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7421F84A0; Mon, 25 Feb 2013 13:20:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225212019.2170.14529.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:20:19 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-31.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:20:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-31.txt Pages : 301 Date : 2013-02-25 Abstract: This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-31 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-31 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From worley@shell01.TheWorld.com Mon Feb 25 14:45:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C253821E810D for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx9gkWrifmDR for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 379AA21E8103 for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1PMiOaj008407 for ; Mon, 25 Feb 2013 17:44:26 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1PMiONN2616570 for ; Mon, 25 Feb 2013 17:44:24 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PMiNpf2617300; Mon, 25 Feb 2013 17:44:23 -0500 (EST) Date: Mon, 25 Feb 2013 17:44:23 -0500 (EST) Message-Id: <201302252244.r1PMiNpf2617300@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Summary of demultiplexing techniques X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:45:04 -0000 I've submitted draft-worley-sdp-bundle-04. That doesn't address any critiques either, but it has a section that summarizes demultiplexing techniques. Essentially, RFC5764 section 5.1.2, at greater length and including SCTP. That discussion is at: http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8 Though it may all be old hat to y'all, I had to work through it to get up to speed, so I figured I'd document it in the process. Dale From worley@shell01.TheWorld.com Mon Feb 25 14:45:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F721E8107 for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m8IVH2Jtlai for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0321E8104 for ; Mon, 25 Feb 2013 14:45:04 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1PMihVd019522; Mon, 25 Feb 2013 17:44:45 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1PMigP12621475; Mon, 25 Feb 2013 17:44:42 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PMig5U2602337; Mon, 25 Feb 2013 17:44:42 -0500 (EST) Date: Mon, 25 Feb 2013 17:44:42 -0500 (EST) Message-Id: <201302252244.r1PMig5U2602337@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Ejzak, Richard P (Richard)" In-reply-to: <03FBA798AC24E3498B74F47FD082A92F36EA7424@US70UWXCHMBA04.zam.alcatel-lucent.com> (richard.ejzak@alcatel-lucent.com) References: <03FBA798AC24E3498B74F47FD082A92F36EA7424@US70UWXCHMBA04.zam.alcatel-lucent.com> Cc: mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] How does an answerer reject the first m line in a BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:45:05 -0000 > From: "Ejzak, Richard P (Richard)" > > In rereading your latest BUNDLE draft I was confused about what the > answerer does when it needs to reject the first m line in a bundle > group. The following text in your draft implies to me that the > answerer is not allowed to reject the first m line: My opinion is that handling the "reject the first m= line" problem is sufficiently messy that it is one of the major reasons why we should have a separate bundle media description. A separate bundle media description allows the constituent media descriptions to be accepted or rejected independently without complicated logic to relocate the bundle transport flow information between media descriptions. Dale From worley@shell01.TheWorld.com Mon Feb 25 14:45:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609B521E8104 for ; Mon, 25 Feb 2013 14:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJFODGdCqm-3 for ; Mon, 25 Feb 2013 14:45:05 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89E21E8103 for ; Mon, 25 Feb 2013 14:45:05 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1PMiuiD029771; Mon, 25 Feb 2013 17:44:58 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1PMiuNq2603316; Mon, 25 Feb 2013 17:44:56 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PMiujk2613075; Mon, 25 Feb 2013 17:44:56 -0500 (EST) Date: Mon, 25 Feb 2013 17:44:56 -0500 (EST) Message-Id: <201302252244.r1PMiujk2613075@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:45:06 -0000 > From: Christer Holmberg > > I had previously provided comments to Dale off-line. Some has been > addressed in the -03 version of the draft. But, I still have some > questions. I'm now in the position to deal with technical improvements. > First, unless I've missed something, the mechanism is still for RTP > ONLY. It is not possible to e.g. put the DataChannel in the > bundle. I think we asap need to decide whether that is a requirement > or not. That's true. Although none of the other 5 proposals I've seen discuss SCTP/DataChannel multiplexing either. Fortunately, adding support for SCTP isn't difficult, either with encapsulation or without. > Second, you use the non-bundle m- lines for codec negotiation > etc. But, previously, when MMT was discussed, I believe that people > indicated that they do not want to "refer" to other m- lines from > the MMT m- line. Instead, the information should be explicitly > provided in the MMT m- line (which is the reason why the SDP size > gets pretty big with MMT, as most information is duplicated). I've heard that mentioned before, but I've never seen the argument in favor of it. Can someone tell me what it is, or provide a pointer? Dale From worley@shell01.TheWorld.com Mon Feb 25 14:46:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2921E80F6 for ; Mon, 25 Feb 2013 14:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp+CCfFn6kXR for ; Mon, 25 Feb 2013 14:46:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 215A521E80E9 for ; Mon, 25 Feb 2013 14:46:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1PMjUvr031144; Mon, 25 Feb 2013 17:45:32 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1PMjTwb2623342; Mon, 25 Feb 2013 17:45:29 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PMjTOh2614803; Mon, 25 Feb 2013 17:45:29 -0500 (EST) Date: Mon, 25 Feb 2013 17:45:29 -0500 (EST) Message-Id: <201302252245.r1PMjTOh2614803@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <51297F5C.8060207@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com> <51297F5C.8060207@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Another bundling proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:46:02 -0000 > From: Paul Kyzivat > One observation is that this introduces a new level of multiplexing > based on a special codec. While it can work, there is already a proposal > on the table for multiplexing multiple RTP sessions on a single 5-tuple: > draft-westerlund-avtcore-transport-multiplexing-04. ISTM that this new > bundling proposal could be adapted to use that multiplexing technique. I haven't had the time to compare the SHIM encapsulation with the KUMQUAT encapsulation, other than to see that SHIM encapsulation doesn't produce valid-looking RTP, whereas KUMQUAT does. Also, KUMQUAT maintains word(4-octet)-alignment in the RTP payload. But as the demultiplexing analysis shows, you don't *have* to encapsulate to allow demultiplexing to work, as long as the payload types of the constituent MDs are distinct, as well as the SCTP port numbers in the SCTP constituent MDs. > Bernard already raised issues about port 9 and address 0.0.0.0. I'll add > that when this is done for multiple m-lines we stand some chance of > getting errors due to reusing the same transport address. AFAIK there is > no particular reason to use port 9 in this case, so perhaps it would be > safer to use a different non-zero port in each such line. Using null addresses in offers could be a problem. But there's a fix for that. Dale From worley@shell01.TheWorld.com Mon Feb 25 14:46:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02B821E8120 for ; Mon, 25 Feb 2013 14:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pTEmLu7IZK7 for ; Mon, 25 Feb 2013 14:46:05 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B821E8103 for ; Mon, 25 Feb 2013 14:46:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1PMjI52001506; Mon, 25 Feb 2013 17:45:20 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1PMjHe02620713; Mon, 25 Feb 2013 17:45:17 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PMjG3k2616885; Mon, 25 Feb 2013 17:45:16 -0500 (EST) Date: Mon, 25 Feb 2013 17:45:16 -0500 (EST) Message-Id: <201302252245.r1PMjG3k2616885@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Bernard Aboba In-reply-to: (bernard_aboba@hotmail.com) References: <201302222105.r1ML5WY52373869@shell01.TheWorld.com>, <51297F5C.8060207@alum.mit.edu> Cc: mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] Another bundling proposal (and why you can't neglect RTP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:46:05 -0000 > From: Bernard Aboba > > Yes, I've also begun to wonder if we haven't been giving that (and possibly) > other transport multiplexing approaches insufficient consideration. A/V > multiplexing isn't just an SDP issue, it is also an RTP issue. Say we don't > specify SSRCs and instead require that the payload type is unique among > all multiplexed m= lines so we can use PT to de-multiplex incoming RTP. > Without specifying SSRCs, how do we map the RTCP reports, which > only include SSRCs and not payload types to the appropriate media > stream tracks? It seems to me that Cullen's "Plan A" has a fundamental > flaw. My understanding is that RTCP is expected to be demultiplexed by examining the SSRC in each RTCP sub-packet (called an "RTCP packet" in RFC 3550) and then finding the RTP media stream with the matching SSRC. The RTCP gets sent wherever the matching RTP gets sent. (This is described in the demultiplexing essay I've sent to the list.) Dale From richard.ejzak@alcatel-lucent.com Mon Feb 25 15:36:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29C21E8152 for ; Mon, 25 Feb 2013 15:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.366 X-Spam-Level: X-Spam-Status: No, score=-9.366 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YulZZkGEwv6d for ; Mon, 25 Feb 2013 15:36:08 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18E21E8125 for ; Mon, 25 Feb 2013 15:35:58 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1PNZu7l024046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Feb 2013 00:35:56 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 26 Feb 2013 00:35:56 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 25 Feb 2013 18:35:49 -0500 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt Thread-Index: AQHOE6/5apv3pLaYfUOB37EkyfYHjZiLOY7w Date: Mon, 25 Feb 2013 23:35:49 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA7520@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:36:35 -0000 SGkgQWxsLA0KSSB1cGRhdGVkIG15IEJVTkRMRSBhbHRlcm5hdGl2ZXMgZHJhZnQgdG8gaW5jbHVk ZSB0aGUgZGlzY3Vzc2lvbiBmcm9tIGxhc3Qgd2VlaydzIGNhbGwgd2l0aCBzb21lIGFkZGVkIHR3 ZWFrcyB0byB0cnkgdG8gYWRkcmVzcyBjb21tZW50cy9kaXNjdXNzaW9uIHNvIGZhci4gIFBsZWFz ZSBjb25zaWRlciB0aGlzIHZlcnNpb24uDQoNClJpY2hhcmQNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDU6Mjkg UE0NClRvOiBFanphaywgUmljaGFyZCBQIChSaWNoYXJkKQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1lanphay1tbXVzaWMtYnVuZGxlLWFsdGVybmF0aXZlcy0w MS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRs ZS1hbHRlcm5hdGl2ZXMtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFJpY2hhcmQgRWp6YWsgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LWVqemFrLW1tdXNpYy1idW5kbGUtYWx0ZXJuYXRpdmVzDQpSZXZpc2lvbjoJ IDAxDQpUaXRsZToJCSBBbHRlcm5hdGl2ZXMgdG8gQlVORExFDQpDcmVhdGlvbiBkYXRlOgkgMjAx My0wMi0yNg0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDkNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRsZS1hbHRlcm5hdGl2ZXMtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2lj LWJ1bmRsZS1hbHRlcm5hdGl2ZXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZWp6YWstbW11c2ljLWJ1bmRsZS1hbHRlcm5hdGl2ZXMtMDENCkRpZmY6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZWp6YWst bW11c2ljLWJ1bmRsZS1hbHRlcm5hdGl2ZXMtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIHBhcGVy IGRpc2N1c3NlcyBzb21lIHBvdGVudGlhbCBtb2RpZmljYXRpb25zIHRvIHRoZSBCVU5ETEUNCiAg IHByb3Bvc2FsIGZvciBtdWx0aXBsZXhpbmcgb2YgbXVsdGlwbGUgbWVkaWEgdHlwZXMgd2l0aGlu IGEgc2luZ2xlDQogICA1LXR1cGxlIHRvIGFkZHJlc3MgbGltaXRhdGlvbnMgb2YgdGhlIGN1cnJl bnQgcHJvcG9zYWwgYW5kDQogICBhbHRlcm5hdGl2ZXMgYWxyZWFkeSBjb25zaWRlcmVkIGJ5IE1N VVNJQy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From christer.holmberg@ericsson.com Tue Feb 26 00:04:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BEA21F88A9 for ; Tue, 26 Feb 2013 00:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OViikcj4bpMt for ; Tue, 26 Feb 2013 00:04:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D261B21F88A1 for ; Tue, 26 Feb 2013 00:03:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-89-512c6c6e01f0 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 66.A4.10459.E6C6C215; Tue, 26 Feb 2013 09:03:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 09:03:58 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Another bundling proposal - Christer's comments Thread-Index: Ac4TVbJsbUziS577R021PX4477xAdwAVBnJJABNOU0A= Date: Tue, 26 Feb 2013 08:03:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> <201302252244.r1PMiujk2613075@shell01.TheWorld.com> In-Reply-To: <201302252244.r1PMiujk2613075@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW5+jk6gwerdLBZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgypjVvZy94CxvxeLpj9gbGN9ydTFyckgImEjM evqUDcIWk7hwbz2QzcUhJHCIUeLa8utQzmJGiZkbjjB2MXJwsAlYSHT/0wYxRQQ0JToW5ICY zALqElcXB4GMERZwlVi25TETiC0i4CaxvOceC4RtJbF2ziGwVSwCqhIrJm4Fs3kFvCV2NF1l htjUyCjRdX47E8hMTgEHiW3v+UBqGIFO+35qDdhMZgFxiVtP5jNBnCwgsWTPeWYIW1Ti5eN/ rBC2osTV6cuh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKK kT03MTMnvdxwEyMwOg5u+a27g/HUOZFDjNIcLErivGGuFwKEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MIZtOXtnZ0z9wQUbkqVr+dh3HOBcseb2Sfnrjlc8KhPKz6/Mf/2ArWd2z1zv35e+ 9eiw+ISyLL/bff4rf4rK39yJC6K21TOtLhWK51h2bN6Boo0mN66bfyl1utQ08caV7wtSjz48 Hd+24c+Rsop/t5X8rj19apxwY1exgPvXfcr3Mo2YOKb0f1qlxFKckWioxVxUnAgA3qfZxlwC AAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:04:00 -0000 Hi, >> I had previously provided comments to Dale off-line. Some has been=20 >> addressed in the -03 version of the draft. But, I still have some=20 >> questions. > >I'm now in the position to deal with technical improvements. > >> First, unless I've missed something, the mechanism is still for RTP=20 >> ONLY. It is not possible to e.g. put the DataChannel in the bundle. I=20 >> think we asap need to decide whether that is a requirement or not. > > That's true. Although none of the other 5 proposals I've seen discuss SC= TP/DataChannel multiplexing either. Fortunately, adding support for SCTP i= sn't difficult, either with encapsulation or without. You would encapsulate SCTP inside the new payload type? >> Second, you use the non-bundle m- lines for codec negotiation etc.=20 >> But, previously, when MMT was discussed, I believe that people=20 >> indicated that they do not want to "refer" to other m- lines from the=20 >> MMT m- line. Instead, the information should be explicitly provided=20 >> in the MMT m- line (which is the reason why the SDP size gets pretty=20 >> big with MMT, as most information is duplicated). > > I've heard that mentioned before, but I've never seen the argument in fav= or of it. Can someone tell me what it is, or provide a pointer? It was indicated in a meeting (at the moment I can't remember which meeting= , though), but I never checked whether it was added to the minutes. I guess= it will be on audio recording. But, as far as I remember, there were never much discussion about it. It wa= s an open issue on one of my slides, and people simply indicated support fo= r adding explicit information, rather the referencing. Regards, Christer From ari.keranen@ericsson.com Tue Feb 26 04:46:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55221F858E for ; Tue, 26 Feb 2013 04:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 188jjWcvlwQu for ; Tue, 26 Feb 2013 04:46:52 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 429C521F8552 for ; Tue, 26 Feb 2013 04:46:51 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-32-512caebb8776 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D1.89.19728.BBEAC215; Tue, 26 Feb 2013 13:46:51 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 26 Feb 2013 13:46:50 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DF25A2AD1; Tue, 26 Feb 2013 14:46:50 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A196C544CF; Tue, 26 Feb 2013 14:46:48 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5373253748; Tue, 26 Feb 2013 14:46:48 +0200 (EET) Message-ID: <512CAEBA.1020609@ericsson.com> Date: Tue, 26 Feb 2013 14:46:50 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvje7udTqBBncmClm8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2P+5LeMBbvYKk403WRpYJzD2sXIySEhYCLx fOY/KFtM4sK99WxdjFwcQgInGSUuXJrNDuFsYJSY+vUEK4Szi1Hiwd2/UJm1jBIfNjxmhHCW M0r87DvLBjKMV0Bb4tGJMywgNouAqsTbTaeYQWw2AXuJmxOus4PYogLJEv8eHWGEqBeUODnz CVi9iICMxN5Nm8HqmYHmzL4ziwnEFhZIlTi66RMbRNxW4sKc6ywQtrzE9rdzmCGeUJO4em4T mC0EtPfqv1eMExiFZyFZMQtJ+ywk7QsYmVcxsucmZuaklxttYgQG8sEtv1V3MN45J3KIUZqD RUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxkTNQ07qE+/mtoZ/64zWT53xdlP3 +WlM+VdX7dm57ypbyRlTLlb1MFOO03O3CznerRZc3WB7Kq/+X2qHWFN/rLX169ijC3RP6rT7 ZdfO6DWybWgu3i+56avSLtZnZ024lGex7pnxpergiaCbTavXx0jUxEzpb+NQWh5tr8HDKVbz dHHpW7c6JZbijERDLeai4kQAuKYeQDICAAA= Cc: Flemming Andreasen Subject: [MMUSIC] Milestone and WG item for Incremental provisioning of candidates for ICE (aka Trickle ICE) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:46:53 -0000 MMUSIC, Incremental provisioning of candidates for ICE (also known as Trickle ICE) has been actively discussed on the list and presented at the previous meeting and Boston interim. Based on the discussions, there appears to be need and interest to work on this topic. Currently we have no milestone or WG document for the work so the chairs would like to ask the working group's opinion on this. Would you support having an MMUSIC milestone for this work? At the moment there is one document (http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00) that would be suitable as the WG item for this milestone. If you support having the new milestone, would you support adopting draft-ivov-mmusic-trickle-ice-00 as the WG document for the milestone? BRs, Ari & Flemming (MMUSIC co-chairs) From enrico.marocco@telecomitalia.it Tue Feb 26 06:52:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27221F8AAD for ; Tue, 26 Feb 2013 06:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iCMEq4liCgv for ; Tue, 26 Feb 2013 06:52:48 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 016A321F8A93 for ; Tue, 26 Feb 2013 06:52:48 -0800 (PST) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 26 Feb 2013 15:52:45 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 26 Feb 2013 15:52:45 +0100 Message-ID: <512CCC3C.9060204@telecomitalia.it> Date: Tue, 26 Feb 2013 15:52:44 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: <512CAEBA.1020609@ericsson.com> In-Reply-To: <512CAEBA.1020609@ericsson.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090206000708030707090103" X-TI-Disclaimer: Disclaimer1 Subject: Re: [MMUSIC] Milestone and WG item for Incremental provisioning of candidates for ICE (aka Trickle ICE) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:52:49 -0000 --------------ms090206000708030707090103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do believe this is something that really needs to be documented, as at this point interworking with existing trickling-ICE implementations degenerates very quickly in blind guessing. I also support adopting the one individual draft on the table, on which the authors have already put quite a lot of effort. Enrico On 2/26/13 1:46 PM, Ari Ker=E4nen wrote: > MMUSIC, >=20 > Incremental provisioning of candidates for ICE (also known as Trickle=20 > ICE) has been actively discussed on the list and presented at the=20 > previous meeting and Boston interim. Based on the discussions, there=20 > appears to be need and interest to work on this topic. >=20 > Currently we have no milestone or WG document for the work so the chair= s=20 > would like to ask the working group's opinion on this. >=20 > Would you support having an MMUSIC milestone for this work? >=20 > At the moment there is one document=20 > (http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00) that woul= d=20 > be suitable as the WG item for this milestone. >=20 > If you support having the new milestone, would you support adopting=20 > draft-ivov-mmusic-trickle-ice-00 as the WG document for the milestone? >=20 >=20 > BRs, > Ari & Flemming (MMUSIC co-chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 --------------ms090206000708030707090103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMjYx NDUyNDRaMCMGCSqGSIb3DQEJBDEWBBTIf2MMHWmZb/kGc8R0sib6DblUETBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAEWr52mQTS9VH4GUTq3ksWz43Oh3ITWL6mMFTsj/Q ++hSV1Ue70QQ0PEJq/E2YgrC3I+BPHJ2dOW2bszRqwbE1wUb0hRPlb9EEfxlyl4yJ2Lm1YC0 iJ9QZeCg1m4W16Vb3k1dncWHviye/08yQFbUi6mSBX4XA33VSDLuf0ZYtuvnSPVM21Qrv3to CWN/+usYoMIL1rJ81WPiHEmI3rKKhs3xuZK5zZrIo9Ha9rsAOnAr4vlQnnIG23i6LQV1Dm8I D6S3CeLgMVgCTyHu6oCB7qiMCqrLuB8pv8JYcXCrq/a7JymNRAH+LZF7q5PgTsrXBlCu6Nuz 2F4/v6cZwqG6MwAAAAAAAA== --------------ms090206000708030707090103-- From christer.holmberg@ericsson.com Tue Feb 26 10:39:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FBC21F8889 for ; Tue, 26 Feb 2013 10:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8d14OMyzJqE for ; Tue, 26 Feb 2013 10:39:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5AED821F8869 for ; Tue, 26 Feb 2013 10:39:04 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-d0-512d01478a66 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.18.19728.7410D215; Tue, 26 Feb 2013 19:39:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 19:39:02 +0100 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt Thread-Index: AQHOE6/5apv3pLaYfUOB37EkyfYHjZiLOY7wgADTArA= Date: Tue, 26 Feb 2013 18:39:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B109754@ESESSMB209.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92F36EA7520@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EA7520@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvja47o26gwZ8r8hZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGatPz2UpWCVRcXflF5YGxjbhLkZODgkBE4nj l84yQthiEhfurWcDsYUEDjFKTGkr7GLkArIXM0r8nv6HtYuRg4NNwEKi+582SI2IQJbE1lP9 LCC2sECaRMPzE+wgJSIC6RJ7F/hAlFhJPJ+9E2w8i4CqxLxDS5lBbF4Bb4nvW7+wQqyKkXj2 8TzYWk6BWInP59+A1TMCnfP91BomEJtZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rhK0osfNs OzNEvY7Egt2f2CBsbYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSX G21iBEbBwS2/VXcw3jkncohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG UDXlzq8V++XOSDRpLto2t6MnlXevvGDdKx/xR9LPvDjzN3jsinPvrJv+6cbkK4yb/zJYdxi0 FoitrDD0MDr8+//7S/p5n+15xSxaXrxTZ/vrdkuNWZ+vWru3YnmdZndBec1dSy535l8G1+Zw MeaoX955c/XOvPxYNh22I4sS7GI5fs1+UqDEUpyRaKjFXFScCAA8lesbUAIAAA== Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:39:05 -0000 Hi Richard, A few comments on the -01 version. ---------- Section 1: Q1: You say that, if the first line of the offer is rejected, and one has t= o wait for the second offer, it may cause a setup time delay. There may be = cases where the application doesn't want to session to succeed in the first= place in that case, so we can have text which recommends adding an "essent= ial" (if available) m- line first. Typically I guess it would be an audio m= - line. ---------- Section 2: Q2: You indicate, that if an empty re-INVITE is sent to the WebRTC client, = it will create a BUNDLE offer. We can simply say that, unless there is an B= UNDLE indicator (yes, we may have to define a feature tag, option tag, etc)= , the WebRTC should not create a BUNDLE offer - it should create a legacy o= ffer, with different ports. ---------- Section 3.1: Q3: The text says that, if the answerer does not use BUNDLE, the offerer wi= ll have to send a second offer. But, you don't mention that this would also= add delay to the session establishment, as the answerer can't do anything = with the m- lines with unspecified address. ---------- Section 3.1: Q4: The text says: "The middle box will not allocate resources for these m lines when forwarding the SDP offer, and the SDP answerer will usually respond with the unspecified address for these m lines. Even if the SDP answer includes valid connection information for these m lines, the middle box will still not allocate separate transport flows for them." As I've said before, you still DO expect the intermediary to take those m- = lines into consideration when calculating bandwidth, checking media types, = payload type information, crypto information etc etc etc. ---------- Section 3.1: Q5: The text says: "If the SDP answerer chooses to reject the first m line(s) in the bundle group in the SDP offer (by setting port in the m line to zero), it places the intended port, connection, candidate and DTLS crypto information for the bundle in the first valid m line of the SDP answer and includes the unspecified address for all other m lines in the bundle group. Because of this, it is understood by both endpoints that the 5-tuple connection, port and DTLS crypto information is to be based on the first valid m line in the SDP offer and the first valid m line in the SDP answer." So, assume that in the offer the first m- line contains a valid address, bu= t in the answer the second m- line contains a valid address (because the an= swerer rejected the first m- line). Now, in this case, based on the text in previous section, an intermediary w= ill not reserve resources for any of the m- lines: - It will not reserve resources based on the first m- line, as it is reject= ed - It will not reserve resources based on the second m- line, as the offer c= ontained an unspecified address Or, do you expect media to be sent in one direction using one m- line, and = in another direction using another m- line? ---------- Regards, Christer From worley@shell01.TheWorld.com Tue Feb 26 11:02:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7221F87C5 for ; Tue, 26 Feb 2013 11:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H5EfCgEr-MT for ; Tue, 26 Feb 2013 11:02:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7B10121F87CC for ; Tue, 26 Feb 2013 11:02:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1QJ1XMq025036 for ; Tue, 26 Feb 2013 14:01:35 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1QJ1XRa2673629 for ; Tue, 26 Feb 2013 14:01:33 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1QJ1X9S2673678; Tue, 26 Feb 2013 14:01:33 -0500 (EST) Date: Tue, 26 Feb 2013 14:01:33 -0500 (EST) Message-Id: <201302261901.r1QJ1X9S2673678@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <512CAEBA.1020609@ericsson.com> (ari.keranen@ericsson.com) References: <512CAEBA.1020609@ericsson.com> Subject: Re: [MMUSIC] Milestone and WG item for Incremental provisioning of candidates for ICE (aka Trickle ICE) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:02:04 -0000 > From: Ari KerC$nen > At the moment there is one document > (http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00) that would > be suitable as the WG item for this milestone. > > If you support having the new milestone, would you support adopting > draft-ivov-mmusic-trickle-ice-00 as the WG document for the milestone? I support defining "trickle ICE", and I support adopting draft-ivov-mmusic-trickle-ice as a basis for defining it. Dale From worley@shell01.TheWorld.com Tue Feb 26 12:19:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89F21F8815 for ; Tue, 26 Feb 2013 12:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B88Nt6XtD63P for ; Tue, 26 Feb 2013 12:19:04 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5C21F87FB for ; Tue, 26 Feb 2013 12:19:04 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1QKIqfx032526; Tue, 26 Feb 2013 15:18:54 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1QKIqM72671507; Tue, 26 Feb 2013 15:18:52 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1QKIpUW2695618; Tue, 26 Feb 2013 15:18:51 -0500 (EST) Date: Tue, 26 Feb 2013 15:18:51 -0500 (EST) Message-Id: <201302262018.r1QKIpUW2695618@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> <201302252244.r1PMiujk2613075@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:19:05 -0000 > From: Christer Holmberg > > >> Second, you use the non-bundle m- lines for codec negotiation etc. > >> But, previously, when MMT was discussed, I believe that people > >> indicated that they do not want to "refer" to other m- lines from the > >> MMT m- line. Instead, the information should be explicitly provided > >> in the MMT m- line (which is the reason why the SDP size gets pretty > >> big with MMT, as most information is duplicated). > > > > I've heard that mentioned before, but I've never seen the argument > > in favor of it. Can someone tell me what it is, or provide a > > pointer? > > It was indicated in a meeting (at the moment I can't remember which > meeting, though), but I never checked whether it was added to the > minutes. I guess it will be on audio recording. > > But, as far as I remember, there were never much discussion about > it. It was an open issue on one of my slides, and people simply > indicated support for adding explicit information, rather the > referencing. If this desire exists, I'd like to hear technical reasons why it is desired. Adding payload types to the bundle media description makes it more difficult to ensure that a non-supporting answerer rejects the bundle media description. Dale From worley@shell01.TheWorld.com Tue Feb 26 12:19:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2021F888C for ; Tue, 26 Feb 2013 12:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNvDhVtykNr7 for ; Tue, 26 Feb 2013 12:19:21 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 578DF21F8887 for ; Tue, 26 Feb 2013 12:19:20 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1QKIItf024146 for ; Tue, 26 Feb 2013 15:18:20 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1QKII8I2686484 for ; Tue, 26 Feb 2013 15:18:18 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1QKIFLP2658818; Tue, 26 Feb 2013 15:18:15 -0500 (EST) Date: Tue, 26 Feb 2013 15:18:15 -0500 (EST) Message-Id: <201302262018.r1QKIFLP2658818@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Encapsulation and demultiplexing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:19:25 -0000 It turns out the demultiplexing STUN, RTP/RTCP/SRTP/SRTCP, SCTP, and DTLS (presumably encapsulating SCTP) is straightforward, as long as we ensure that SCTP (outside of DTLS) uses a restricted range of port numbers. There are two versions of encapsulation now on the table: The KUMQUAT encapsulation (draft-worley-sdp-bundle) adds four octets to the beginning of an RTP packet to make it into a new RTP packet. The new packet has a chosen PT to identify the encapsulation, and uses the 2-octet "sequence" field of the first word of the RTP header to carry the indexes of the constituent media description and of the transport flow (in case the MD has multiple transport flows). It's not clear that there is a need to have an encapsulation carefully reproduce the structure of an RTP packet. Indeed, the encapsulation doesn't need to be very careful to make packets that look like RTP packets: The fixed header of an RTP packet is only three 4-octet words, and the second and third words are 32-bit binary numbers, so KUMQUAT would be just as effective if it merely prepended a 4-octet word that resembled the first word of an RTP header. Using this simplified KUMQUAT encapsulation, encapsulation of SCTP is straightforward: Just prepend the KUMQUAT header word. If RTP is being encapsulated with KUMQUAT, there is no reason not to encapsulate SCTP or SCTP-over-DTLS with it also. Encapsulation allows demultiplexing without requiring distinct SCTP port numbers between media descriptions, and the octet savings of not encapsulating SCTP is small (given the relative size of the RTP). The SHIM encapsulation (draft-westerlund-avtcore-transport-multiplexing) uses a two-octet prefix containing a 14-bit "session ID". Each SDP media description has an attribute to specify the session IDs to be used to encapsulate RTP and the RTCP for that media description. The remaining two bits of the two-octet prefix are fixed as "10", presumably so the first octet values have the same range as those of RTP/RTCPv2. Although the draft does not say so, an SCTP packet stream can be a constituent session of a SHIM encapsulation in the same way as an RTP packet stream. One requirement question that should be examined is whether, if encapsulation is done, there is any value in making the encapsulated packet look like a RTP packet, or whether there is any benefit to preserving four-octet alignment of RTP fields. The major advantage of an encapsulated solution over an unencapsulated solution is that an encapsulated solution does not require the constituent media descriptions to have disjoint sets of payload types (or SCTP port numbers). Since previous uses of SDP have no interaction between the payload types of different media descriptions, existing entities may have difficulty coordinating payload types between media descriptions. E.g., if the entity is assembling its media streams from several sources, and thus assembling its SDP from several constituent SDPs, the disjointness restriction may require the entity to recode the payload type numbers of constituent transport flows in order to multiplex them. Dale From richard.ejzak@alcatel-lucent.com Tue Feb 26 12:41:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DD721F8A94 for ; Tue, 26 Feb 2013 12:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.429 X-Spam-Level: X-Spam-Status: No, score=-9.429 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbyC8CB81K9l for ; Tue, 26 Feb 2013 12:41:40 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 473C021F8A8E for ; Tue, 26 Feb 2013 12:41:40 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1QKfa12012266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 21:41:37 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 26 Feb 2013 21:41:36 +0100 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 26 Feb 2013 15:41:35 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt Thread-Index: AQHOFFCQfjVvYXaDN0ij/3TiB1L7cpiMg0Lw Date: Tue, 26 Feb 2013 20:41:34 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA77D1@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EA7520@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B109754@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B109754@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:41:41 -0000 Hi Christer, Thanks for your comments. See below. Richard > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > A few comments on the -01 version. >=20 > ---------- >=20 > Section 1: >=20 > Q1: You say that, if the first line of the offer is rejected, and one > has to wait for the second offer, it may cause a setup time delay. > There may be cases where the application doesn't want to session to > succeed in the first place in that case, so we can have text which > recommends adding an "essential" (if available) m- line first. > Typically I guess it would be an audio m- line. SDP doesn't really have the concept of an "essential" m line, so this recom= mendation reduces but does not eliminate the possibility that this will hap= pen. >=20 > ---------- >=20 > Section 2: >=20 > Q2: You indicate, that if an empty re-INVITE is sent to the WebRTC > client, it will create a BUNDLE offer. We can simply say that, unless > there is an BUNDLE indicator (yes, we may have to define a feature tag, > option tag, etc), the WebRTC should not create a BUNDLE offer - it > should create a legacy offer, with different ports. If we added a feature tag for this it would only cover some use cases while= others would still not be covered. A better solution is one that is less = likely to cause failure in any use case and more likely to work with at mos= t a second offer/answer. That is at least my current assessment of the ris= k. Just to be clear regarding your terminology, you mean by BUNDLE offer one i= n which all ports are the same (corresponding to the 2nd and subsequent off= ers in the latest BUNDLE draft) and a legacy offer is still an SDP offering= BUNDLE but with different ports (corresponding to the first offer in your = draft)? Or do you mean a fully legacy offer without BUNDLE? >=20 > ---------- >=20 > Section 3.1: >=20 > Q3: The text says that, if the answerer does not use BUNDLE, the > offerer will have to send a second offer. But, you don't mention that > this would also add delay to the session establishment, as the answerer > can't do anything with the m- lines with unspecified address. You are correct. I thought this was clear from context but should have men= tioned it. Fortunately with this option a second offer is only needed for = the non-bundle (lower priority) case. Note that as the default in my prefe= rred hybrid proposal (section 3.3) I propose to use the same first offer fo= rmat as the current first BUNDLE offer to avoid this potential extra offer/= answer. >=20 > ---------- >=20 > Section 3.1: >=20 > Q4: The text says: >=20 > "The middle box will not allocate resources for these m lines when > forwarding the SDP offer, and the SDP answerer will usually respond > with the unspecified address for these m lines. Even if the SDP > answer includes valid connection information for these m lines, the > middle box will still not allocate separate transport flows for them." >=20 > As I've said before, you still DO expect the intermediary to take those > m- lines into consideration when calculating bandwidth, checking media > types, payload type information, crypto information etc etc etc. Agreed. I should have emphasized this point in the draft based on your ear= lier comment. My bad. Since this aspect is inherited from the current BUN= DLE draft, along with many other things, I forgot to mention it. >=20 > ---------- >=20 > Section 3.1: >=20 > Q5: The text says: >=20 > "If the SDP answerer chooses to reject the first m line(s) in the > bundle group in the SDP offer (by setting port in the m line to zero), > it places the intended port, connection, candidate and DTLS crypto > information for the bundle in the first valid m line of the SDP answer > and includes the unspecified address for all other m lines in the > bundle group. Because of this, it is understood by both endpoints > that the 5-tuple connection, port and DTLS crypto information is to be > based on the first valid m line in the SDP offer and the first valid m > line in the SDP answer." >=20 > So, assume that in the offer the first m- line contains a valid > address, but in the answer the second m- line contains a valid address > (because the answerer rejected the first m- line). >=20 > Now, in this case, based on the text in previous section, an > intermediary will not reserve resources for any of the m- lines: >=20 > - It will not reserve resources based on the first m- line, as it is > rejected > - It will not reserve resources based on the second m- line, as the > offer contained an unspecified address >=20 > Or, do you expect media to be sent in one direction using one m- line, > and in another direction using another m- line? This (as you pointed out in Q1, rare) case requires a second offer/answer f= or simple intermediaries that do not understand BUNDLE but are needed, e.g.= , to open pinholes. While the idea of using different m line offer/answer = pairs in the 2 directions is intriguing, I think this is a non-starter sinc= e we will have non-symmetric RTP and it would be difficult to switch back t= o a single m line representation. This is not my preferred option for the first offer in a session. My prefe= rred option is based on section 3.2, where the offer is formatted exactly a= s in the current BUNDLE draft but the answer differs. A second offer is st= ill needed if the answerer rejects the first m line in the offer, but this = should not usually happen (see Q1). >=20 > ---------- >=20 > Regards, >=20 > Christer From christer.holmberg@ericsson.com Wed Feb 27 02:01:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F097621F8533 for ; Wed, 27 Feb 2013 02:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahRAsTM705kU for ; Wed, 27 Feb 2013 02:01:38 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8C21F85C4 for ; Wed, 27 Feb 2013 02:01:37 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-27-512dd9805da9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 33.2A.32353.089DD215; Wed, 27 Feb 2013 11:01:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 11:01:36 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Another bundling proposal - Christer's comments Thread-Index: Ac4TVbJsbUziS577R021PX4477xAdwAVBnJJABNOU0AAGeCPCQAcMHdA Date: Wed, 27 Feb 2013 10:01:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10AE32@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B106FE2@ESESSMB209.ericsson.se> <201302252244.r1PMiujk2613075@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B107B87@ESESSMB209.ericsson.se> <201302262018.r1QKIpUW2695618@shell01.TheWorld.com> In-Reply-To: <201302262018.r1QKIpUW2695618@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+JvjW7DTd1Ag2l31C2mLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXF46lrmglaBihenqhoYf/J0MXJySAiYSGxZ 84QJwhaTuHBvPVsXIxeHkMAhRomZGyewQDiLGSW+NTxn72Lk4GATsJDo/qcNYooIaEp0LMgB MZkF1CWuLg4CGSMs4CqxbMtjsJEiAm4Sy3vusUBUu0m0LBcCCbMIqErcW/SEEcTmFfCW6N69 jhXEFhL4ySjRtEEaxOYUcJC4dWkaC4jNCHTZ91NrwEYyC4hL3HoyH+piAYkle84zQ9iiEi8f /2OFsBUlrk5fDlWvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzsuYmZOenl5psYgZFxcMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNa fIiRiYNTqoFxwd0zsnZ2K0OaZ949zTLz+sxbF4+GfXm8LMbuhkHiJPeQC2LhhS9cU+bIOCZP bTtwPrtga6q35p7bcpXR2msW3TJ4MUOn2iqlbt/c8+yHX4ufqtHb5b46YsPpactu1sYdUVx4 ae7mnU8Cr2jPC5LKePxCjUn6r6n0Fy5RlpPbSmTlje/73uGcpsRSnJFoqMVcVJwIAG7+zjla AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Another bundling proposal - Christer's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:01:40 -0000 Hi, >>>> Second, you use the non-bundle m- lines for codec negotiation etc.=20 >>>> But, previously, when MMT was discussed, I believe that people=20 >>>> indicated that they do not want to "refer" to other m- lines from=20 >>>> the MMT m- line. Instead, the information should be explicitly=20 >>>> provided in the MMT m- line (which is the reason why the SDP size=20 >>>> gets pretty big with MMT, as most information is duplicated). >>> >>> I've heard that mentioned before, but I've never seen the argument=20 >>> in favor of it. Can someone tell me what it is, or provide a=20 >>> pointer? >>=20 >>It was indicated in a meeting (at the moment I can't remember which=20 >>meeting, though), but I never checked whether it was added to the=20 >>minutes. I guess it will be on audio recording. >>=20 >>But, as far as I remember, there were never much discussion about it.=20 >>It was an open issue on one of my slides, and people simply indicated=20 >>support for adding explicit information, rather the referencing. >> >If this desire exists, I'd like to hear technical reasons why it is desire= d. =20 As far as I remember, there were no real technical reasons - it was mostly = "cosmetic". But, one issue is if there is an intermediary (e.g. transcoder) that modifi= es the payload type/codec information in the non-BUNDLE m- lines, but leave= s the BUNDLE m- line untouched and passes the "kumquat" payload transparent= ly. The offerer and answerer would not have different payload type/codec in= formation. (Of course, if you assume that such intermediary would always remove the KU= MQUAT grouping attribute value, the case won't occur.) >Adding payload types to the bundle media description makes it more difficu= lt to ensure that a non-supporting answerer rejects the bundle media descri= ption. It depends on how it's done. You could still only indicate "kumquat" on the= m- line, but then provide the encapsulated payload type information using = SDP attributes. Regards, Christer From fluffy@iii.ca Wed Feb 27 07:39:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629721F8757 for ; Wed, 27 Feb 2013 07:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q+JnrjIEI6E for ; Wed, 27 Feb 2013 07:39:05 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id EB5DE21F8765 for ; Wed, 27 Feb 2013 07:39:04 -0800 (PST) Received: from dhcp-171-68-20-36.cisco.com (unknown [171.68.20.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 41BE5509B5; Wed, 27 Feb 2013 10:39:04 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72B12BF5-D02F-4602-80D3-F3FDFB6FC0FB@iii.ca> Date: Wed, 27 Feb 2013 07:39:07 -0800 To: mmusic WG , mmusic-chairs@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [MMUSIC] Request for agenda time for draft-jennings-rtcweb-plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:39:05 -0000 I would like to request agenda time for the following MMUSIC-related = topics from draft-jennings-rtcweb-plan: - The multi-render attribute - Simulcast/layered coding/FEC m-line representations. - MSID structure and use for stream identification I believe I will need 40 minutes for these topics. It would be best if = that were Friday so that it follows the RTCWEB discussion on the big = picture. Cullen= From suhasietf@gmail.com Wed Feb 27 07:43:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52221F84AF for ; Wed, 27 Feb 2013 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8EO3G7xA9Ph for ; Wed, 27 Feb 2013 07:43:14 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E214421F847B for ; Wed, 27 Feb 2013 07:43:13 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so6438820wid.17 for ; Wed, 27 Feb 2013 07:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=HC50d0Rmu8wuhMHJl4UTZ5qzJCTXAQjXFJJWLeoSqkM=; b=f7v3o9wLq1jCAQDM5IvNoPv2AWdo+Bi5HvTH0zm+XK4vnpYGP/h1jDOdUpdd/aVQXI lMKqXsu+8zgQIseT54UlnGbJKQPaJB3iQSDv5jLVKWXKMlruN02leiS6gaz1e8aPv5DG lRCHAU+NZFxrqBjoj2oedndLr74L7ZxqKWyFHHpWgYj3Crvf1FaM0VUvJuK60jk20kEv MVq1ynr/t5TeCOP1jnciO9HBPBDIBypo3mjyz1oCsbwlcLuOHFkXHsBgMWuFEJtaoPcv AuhdJBqbIN5nCZoHYalWF0HJ9DFaB01n47sI0m8VQe//IqnacwAzVT19qs5sRBsZPQJw mbGA== MIME-Version: 1.0 X-Received: by 10.194.157.42 with SMTP id wj10mr4928044wjb.12.1361979793153; Wed, 27 Feb 2013 07:43:13 -0800 (PST) Received: by 10.194.44.99 with HTTP; Wed, 27 Feb 2013 07:43:12 -0800 (PST) Date: Wed, 27 Feb 2013 07:43:12 -0800 Message-ID: From: Suhas Nandakumar To: mmusic@ietf.org, mmusic-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0112c512c323f104d6b6a162 Subject: [MMUSIC] Request for agenda time for draft-nandakumar-mmusic-sdp-mux-attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:43:14 -0000 --089e0112c512c323f104d6b6a162 Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to request agenda time for the following draft: draft-nandakumar-mmusic-sdp-mux-attributes Due to the complexity and depth of analysis, I believe I will need 60 minutes. Suhas --089e0112c512c323f104d6b6a162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

I would like to request agenda time for the following draft:

=A0draft-nandakumar-mmusic-sdp-mux-attributes

Due to the complexity and depth of analysis, I be= lieve I will
need 60 minutes.

Suhas --089e0112c512c323f104d6b6a162-- From suhasietf@gmail.com Wed Feb 27 07:50:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC4821F87C5 for ; Wed, 27 Feb 2013 07:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn+PqRjCHjLu for ; Wed, 27 Feb 2013 07:50:41 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A658C21F87B9 for ; Wed, 27 Feb 2013 07:50:40 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so570611wgb.11 for ; Wed, 27 Feb 2013 07:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=mSKKE7SfvSYFp4Zqzl9DOT1yDj4Oo7wFc6jSIdDAHpw=; b=Zfb8AMISszWFPjd3mJdif1yKOg4cfQQfQgBe3slzVCCUeAYIw0qldwcw1BCzO0bsQ9 R+pgHKACMuHA1DZk+n8kGYTT0fZzKZkagTkrQfHep+tnI5rYevhcdSMd/olZocd4VqaF vaOchLjj+7eQpka/xwZA3mB+Z524EaTiq7YdLNkZj5ySmwE0n0z0sIUPNfzW4D9Sf7GT bWUDGpMGsuZISKc7vkfAAzkSmXTFR6VoZyc+5Yd/P/uUxmV8+MNgMCuLEww39Sbq2FKt uHTefPsAgpkgvimuqCa54FVwX3C2teW60FmUSPB5D+0zEtj4QF8q0Ly3A4JuZNMRYXKt WxlA== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr4841586wjq.51.1361980239888; Wed, 27 Feb 2013 07:50:39 -0800 (PST) Received: by 10.194.44.99 with HTTP; Wed, 27 Feb 2013 07:50:39 -0800 (PST) Date: Wed, 27 Feb 2013 07:50:39 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG , mmusic-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b86cea463ca9404d6b6bc6b Subject: [MMUSIC] Agenda Time request for draft-nandakumar-mmusic-sdp-mux-attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:50:41 -0000 --047d7b86cea463ca9404d6b6bc6b Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to request agenda time for the following draft: draft-nandakumar-mmusic-sdp-mux-attributes Due to the complexity and depth of analysis, I believe I will need 60 minutes. Thanks Suhas PS: Resending due to some network issues. Hope it reaches this time --047d7b86cea463ca9404d6b6bc6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

I would like to request agenda time for the following draft:

=A0draf= t-nandakumar-mmusic-sdp-mux-attributes

Due to the compl= exity and depth of analysis, I believe I will
need 60= minutes.


Thanks
Su= has
PS: Resending due to some network issues. Hope it reaches thi= s time
--047d7b86cea463ca9404d6b6bc6b-- From wwwrun@rfc-editor.org Wed Feb 27 11:35:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AE021F8AFE; Wed, 27 Feb 2013 11:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.031 X-Spam-Level: X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr6bUWIp1jHn; Wed, 27 Feb 2013 11:35:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C968021F8AC8; Wed, 27 Feb 2013 11:35:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 58A0C72E14C; Wed, 27 Feb 2013 11:34:42 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130227193442.58A0C72E14C@rfc-editor.org> Date: Wed, 27 Feb 2013 11:34:42 -0800 (PST) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:35:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6871 Title: Session Description Protocol (SDP) Media Capabilities Negotiation Author: R. Gilman, R. Even, F. Andreasen Status: Standards Track Stream: IETF Date: February 2013 Mailbox: bob_gilman@comcast.net, roni.even@mail01.huawei.com, fandreas@cisco.com Pages: 55 Characters: 124829 Updates: RFC5939 I-D Tag: draft-ietf-mmusic-sdp-media-capabilities-17.txt URL: http://www.rfc-editor.org/rfc/rfc6871.txt Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From fandreas@cisco.com Wed Feb 27 12:22:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A9221F89B2 for ; Wed, 27 Feb 2013 12:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.244 X-Spam-Level: X-Spam-Status: No, score=-9.244 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIkacPPnagKP for ; Wed, 27 Feb 2013 12:22:17 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8493B21F8830 for ; Wed, 27 Feb 2013 12:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=230; q=dns/txt; s=iport; t=1361996537; x=1363206137; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=k2yZf/00s3ESLYW4+4mZTEeoDTjMaotPDgdzt6nQs9Y=; b=T0aT45hAOfvcZL6iT+srlM2Cli3MU+Kxz3tKQiQhp+F3iBcPL05AYez5 nkJwuN2oLkX7Xj9g6/e7pu2fHCs0TkWVZPC4lq2Q53MDWNT1ebmYEiZ6P D+ry+kYgeCE1SZoxNZ52tlHE81nmuZUiGs3MtbQ2Uf2fjV+KRivFdCdD9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwOAHVpLlGrRDoH/2dsb2JhbABFhgi8FgEBAgEBAn4Wc4JeQD0WGAMCAQIBSw0IAQGIDg2gYqFFBJJbA4hqjVeQaoMm X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; d="scan'208";a="73579247" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Feb 2013 20:22:07 +0000 Received: from dhcp-10-128-0-108.cisco.com (dhcp-10-128-0-108.cisco.com [10.128.0.108]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1RKM7wJ026054 for ; Wed, 27 Feb 2013 20:22:07 GMT Message-ID: <512E6AEF.2050200@cisco.com> Date: Wed, 27 Feb 2013 15:22:07 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC Draft Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:22:23 -0000 The MMUSIC draft agenda for IETF 86 has been posted at: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ Please take a look and let us know if you have any questions or comments. Thanks Ari & Flemming From worley@shell01.TheWorld.com Wed Feb 27 13:57:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C0221F87B9 for ; Wed, 27 Feb 2013 13:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGsW8lAC0fKz for ; Wed, 27 Feb 2013 13:57:53 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB6B21F8751 for ; Wed, 27 Feb 2013 13:57:44 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1RLuuIF014601 for ; Wed, 27 Feb 2013 16:56:58 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1RLutvr2744808 for ; Wed, 27 Feb 2013 16:56:56 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1RLut982750103; Wed, 27 Feb 2013 16:56:55 -0500 (EST) Date: Wed, 27 Feb 2013 16:56:55 -0500 (EST) Message-Id: <201302272156.r1RLut982750103@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Better way to not-really-offer constituent media descriptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:57:53 -0000 This is a revision of how how constituent MDs are presented in the offer in draft-worley-sdp-bundle. Instead of offering them with a non-zero port and null address (as if they were on-hold in the old manner), offer them with a real port and address (but only provide ICE candidates that are already known, and don't allocate a TURN relay). (The idea that we can have the answerer suppress the constituent MDs rather than the offerer is taken from draft-ejzak-mmusic-bundle-alternatives-01.) o=- 2890844526 2890844526 IN IP4 host.example.com c=IN IP4 10.0.1.1 a=group:KUMQUAT bundle con1 con2 m=audio 10002 RTP/AVP 0 8 97 c=IN IP4 0.0.0.0 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host m=video 10004 RTP/AVP 31 32 c=IN IP4 0.0.0.0 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host m=audio 10000 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 If the answerer understands bundling, the answer is as before, with a non-zero port but a null address for the constituent MDs. (I assume that intermediate devices realize that a null address means that it will see no media on that transport flow.) o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 10.0.2.1 a=group:KUMQUAT bundle con1 con2 m=audio 9 RTP/AVP 0 8 97 c=IN IP4 0.0.0.0 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 9 RTP/AVP 31 32 c=IN IP4 0.0.0.0 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 20000 RTP/AVP 127 a=mid:bundle a=rtcp-mux a=rtpmap:127 kumquat a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \ raddr 10.0.2.1 rport 20000 If the answerer does not understand bundling, since the offer includes real transport addresses, there is no risk that answerer wil not see the constituent MDs as being offered. The answer now has real transport address information for the constituent MDs, including full ICE candidates. But since the offer didn't include the full ICE candidates, it's possible that media communications won't be established. The offerer will have to update its offer with complete ICE information, which may require allocating more TURN relays. Non-supporting answer: o=- 2890844526 2890844526 IN IP4 answer.example.com c=IN IP4 10.0.2.1 m=audio 20000 RTP/AVP 0 8 97 c=IN IP4 10.0.2.1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \ raddr 10.0.2.1 rport 20000 m=audio 20002 RTP/AVP 31 32 c=IN IP4 10.0.2.1 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.2.1 20002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.35 51092 typ srflx \ raddr 10.0.2.1 rport 20002 m=audio 0 RTP/AVP 127 Updated offer, with further ICE candidates: o=- 2890844526 2890844527 IN IP4 host.example.com c=IN IP4 10.0.1.1 m=audio 10000 RTP/AVP 0 8 97 c=IN IP4 10.0.1.1 a=mid:con1 a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \ raddr 10.0.1.1 rport 10000 m=video 10002 RTP/AVP 31 32 c=IN IP4 10.0.1.1 a=mid:con2 a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx \ raddr 10.0.1.1 rport 10002 m=audio 0 RTP/AVP 127 a=mid:bundle The updated answer is the same as the first answer. There also a fast-start alternative where the offerer provides full ICE candidates for the constituent MDs. This avoids the delay of updating the offer when interoperating with a non-supporting answerer and full ICE candidates are needed, but may require pre-allocating additional TURN relays. Dale From worley@shell01.TheWorld.com Wed Feb 27 13:58:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1857721F8838 for ; Wed, 27 Feb 2013 13:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db1GJ-cdjCyM for ; Wed, 27 Feb 2013 13:58:43 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4D21F87FF for ; Wed, 27 Feb 2013 13:58:43 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1RLw7tg017215 for ; Wed, 27 Feb 2013 16:58:09 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1RLw6GJ2734665 for ; Wed, 27 Feb 2013 16:58:06 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1RLw6t72679355; Wed, 27 Feb 2013 16:58:06 -0500 (EST) Date: Wed, 27 Feb 2013 16:58:06 -0500 (EST) Message-Id: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Where to apply encryption? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:58:44 -0000 Current bundling proposals seem to expect that the packets on the wire will be either SRTP/SRTCP or SCTP-within-DTLS. Of course, this provides encryption of the carried media. But it seems to me that it would be more straightforward to multiplex RTP/RTCP and SCTP packets, and than as a lower layer, have one DTLS association that encrypts all of those packets indifferently. It would also provide privacy regarding the number and types of the bundled media streams. But my knowledge of crypto is thin, and maybe there's a reason that using one DTLS association to encrypt the multiplexed packet stream wouldn't work as well. Dale From martin.thomson@gmail.com Wed Feb 27 14:11:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9E21F87E5 for ; Wed, 27 Feb 2013 14:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.612 X-Spam-Level: X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[AWL=-3.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzvB2rRl0p2p for ; Wed, 27 Feb 2013 14:11:28 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2921F87E0 for ; Wed, 27 Feb 2013 14:11:22 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so935152wgd.16 for ; Wed, 27 Feb 2013 14:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bXGIKVypcwUBxqR4gd9/UJYCeve7geMQQGqYD7rBEXI=; b=H76c5RIeF2bC+ivvhE2S4REL2ugOPc4NcaNokZUHihNZoi/jE5BI9z4X3DTngQquyK /iHhzanhqFdRXqCXx+U1rvHTU8EeE0LFZBKeKdp9x0MJQNABXdIa9IZnBaO/3f5FNbfK 8QTwlZ0+bobBI6oYhE9Lahyes3lOJfmJ+KH8N10O8gwA6CsQV0EMGtnZUnmw08ifoR/v EmD4owVLSlVxV6OEoQ9xeisHbIrPRKTurDrzMgzdBXpBpFl01vBCn6QEfqT3reAyjMez LEim3o4iIzk9L/rW2lbg0Fx9XcWgtl+/NIVX2rD5Pi5+Z3X4d30rjJ082o6QnI2NLlZv gUOQ== MIME-Version: 1.0 X-Received: by 10.194.91.211 with SMTP id cg19mr6970268wjb.43.1362003081962; Wed, 27 Feb 2013 14:11:21 -0800 (PST) Received: by 10.194.5.135 with HTTP; Wed, 27 Feb 2013 14:11:21 -0800 (PST) In-Reply-To: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> References: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> Date: Wed, 27 Feb 2013 14:11:21 -0800 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Where to apply encryption? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:11:29 -0000 There are no security reasons why this wouldn't work. Some applications already do this. The actual problems are manifold: - SRTP was designed to have a low per-packet overhead. The DTLS record layer has a larger per-packet overhead. - SRTP exposes certain attributes in clear text for intermediaries to use. Intentionally. Using DTLS would lose this. - SRTP enjoys wide support. This would harm interoperability with existing communication devices, forcing the use of more complex gateways. --Martin On 27 February 2013 13:58, Dale R. Worley wrote: > Current bundling proposals seem to expect that the packets on the wire > will be either SRTP/SRTCP or SCTP-within-DTLS. Of course, this > provides encryption of the carried media. > > But it seems to me that it would be more straightforward to multiplex > RTP/RTCP and SCTP packets, and than as a lower layer, have one DTLS > association that encrypts all of those packets indifferently. It > would also provide privacy regarding the number and types of the > bundled media streams. > > But my knowledge of crypto is thin, and maybe there's a reason that > using one DTLS association to encrypt the multiplexed packet stream > wouldn't work as well. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From rlb@ipv.sx Wed Feb 27 14:38:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2F21F8858 for ; Wed, 27 Feb 2013 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkoSSUeW+crA for ; Wed, 27 Feb 2013 14:38:07 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1913221F8853 for ; Wed, 27 Feb 2013 14:38:07 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so2416814oag.31 for ; Wed, 27 Feb 2013 14:38:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kSIFI/jK3KuCfKbajVwEwWwBP6IHQfsw3oYT9wFklSs=; b=kdGokwqpOihfBnINfR9L1JXxTlQhEzsq1HRcPQeJBNdrHIwGeqGEx0IZOdx9W3K51O jE1f2bAbz2VkfJL8F4J3MwMltxVj8P39Tg97cVLVj6PCGZdILNHEiayl5K0s/gcGcAWm 4MeAuier5CcEs4u48fmyr7NfK5X2x9IPN9UI/4wQSoz3Hu+3ibHC7I/SErb7EnllbWtr sv3AL3nXeGBEuXTTIkFijmrwLbbJiZE6YMnnNfZ1a0Off/2waVKFaWEbgVNM9DLSgLKg otDO3l5UNSN0aipoWK0PWr0QFMAOe2EGnlz4ESX/Mo8zizTjCJCVED8BX6FpNzTgzcJU xf6A== MIME-Version: 1.0 X-Received: by 10.60.25.138 with SMTP id c10mr4114497oeg.12.1362004686479; Wed, 27 Feb 2013 14:38:06 -0800 (PST) Received: by 10.60.60.98 with HTTP; Wed, 27 Feb 2013 14:38:06 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> Date: Wed, 27 Feb 2013 17:38:06 -0500 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8ff1c2fc85353e04d6bc6d2c X-Gm-Message-State: ALoCoQmOlc2nbumIimCwLVik/RpMB4ptp98mjZUq/OWfP7/bHF3HkMsLMvjcL3imNqX9MO+XIdof Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Where to apply encryption? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:38:08 -0000 --e89a8ff1c2fc85353e04d6bc6d2c Content-Type: text/plain; charset=ISO-8859-1 Yes. Back in the days of the ZRTP / DTLS wars, the possibility of just using DTLS was discussed, but morphed into DTLS-SRTP for the reasons Martin describes. On Wednesday, February 27, 2013, Martin Thomson wrote: > There are no security reasons why this wouldn't work. Some > applications already do this. > > The actual problems are manifold: > > - SRTP was designed to have a low per-packet overhead. The DTLS > record layer has a larger per-packet overhead. > - SRTP exposes certain attributes in clear text for intermediaries to > use. Intentionally. Using DTLS would lose this. > - SRTP enjoys wide support. This would harm interoperability with > existing communication devices, forcing the use of more complex > gateways. > > --Martin > > On 27 February 2013 13:58, Dale R. Worley > > wrote: > > Current bundling proposals seem to expect that the packets on the wire > > will be either SRTP/SRTCP or SCTP-within-DTLS. Of course, this > > provides encryption of the carried media. > > > > But it seems to me that it would be more straightforward to multiplex > > RTP/RTCP and SCTP packets, and than as a lower layer, have one DTLS > > association that encrypts all of those packets indifferently. It > > would also provide privacy regarding the number and types of the > > bundled media streams. > > > > But my knowledge of crypto is thin, and maybe there's a reason that > > using one DTLS association to encrypt the multiplexed packet stream > > wouldn't work as well. > > > > Dale > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --e89a8ff1c2fc85353e04d6bc6d2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. =A0Back in the days of the ZRTP / DTLS wars, the possibil= ity of just using DTLS was discussed, but morphed into DTLS-SRTP for the re= asons Martin describes.=A0

On Wednesday, February 27, 2013, Martin T= homson wrote:
There are no security reasons why this would= n't work. =A0Some
applications already do this.

The actual problems are manifold:

=A0- SRTP was designed to have a low per-packet overhead. =A0The DTLS
record layer has a larger per-packet overhead.
=A0- SRTP exposes certain attributes in clear text for intermediaries to use. =A0Intentionally. =A0Using DTLS would lose this.
=A0- SRTP enjoys wide support. =A0This would harm interoperability with
existing communication devices, forcing the use of more complex
gateways.

--Martin

On 27 February 2013 13:58, Dale R. Worley <worley@aria= dne.com> wrote:
> Current bundling proposals seem to expect that the packets on the wire=
> will be either SRTP/SRTCP or SCTP-within-DTLS. =A0Of course, this
> provides encryption of the carried media.
>
> But it seems to me that it would be more straightforward to multiplex<= br> > RTP/RTCP and SCTP packets, and than as a lower layer, have one DTLS > association that encrypts all of those packets indifferently. =A0It > would also provide privacy regarding the number and types of the
> bundled media streams.
>
> But my knowledge of crypto is thin, and maybe there's a reason tha= t
> using one DTLS association to encrypt the multiplexed packet stream > wouldn't work as well.
>
> Dale
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--e89a8ff1c2fc85353e04d6bc6d2c-- From pkyzivat@alum.mit.edu Wed Feb 27 14:47:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E8521F87D2 for ; Wed, 27 Feb 2013 14:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF2JQAql4qQJ for ; Wed, 27 Feb 2013 14:47:55 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id BC13721F87C5 for ; Wed, 27 Feb 2013 14:47:54 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id 5QsY1l0020xGWP855antvt; Wed, 27 Feb 2013 22:47:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([115.193.211.231]) by omta12.westchester.pa.mail.comcast.net with comcast id 5alj1l00e506YvF3Yalmek; Wed, 27 Feb 2013 22:45:51 +0000 Message-ID: <512E8C99.20701@alum.mit.edu> Date: Thu, 28 Feb 2013 06:45:45 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: mmusic@ietf.org References: <201302272156.r1RLut982750103@shell01.TheWorld.com> In-Reply-To: <201302272156.r1RLut982750103@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362005273; bh=0v0oVFA7ASMIQ3KO8CSK2EpaZx4u2NzQSL9jK5gbQDo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iqHL4XQaMm9xrv6Y86jf3gaGiMPX6X/Gc7jRgg5u6DbiVmnsrGioC8Ymj1nH5xHHn aCqnsL61rSJJPaBWYik2zH7+p3WWVDJcDyOO8ya+SyG9t1IVDVbHHm9rDyhHrQPUd3 v5140r9TyNFakhMavL3D2MXv6SLtW7ScyQ/60BUdIzni7gz/P5hI+9OzV4uxdhXT/h ol96msVHK6BMtm8FFnaZUONv4u1sQdbXHYUh7UkxBZp3C9yiEibEd3baTwP+Zn52LW 1UA1j6XAmB+LzqfM+DPIkR+Nl0UIdGBt8W+rIoZx0/ZUNZHtQOcgK/W4CRyucXwlzt 6Kq4gDi0il61w== Subject: Re: [MMUSIC] Better way to not-really-offer constituent media descriptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:47:55 -0000 On 2/28/13 5:56 AM, Dale R. Worley wrote: > (The idea that we can have the answerer suppress the constituent MDs > rather than the offerer is taken from > draft-ejzak-mmusic-bundle-alternatives-01.) ... > If the answerer understands bundling, the answer is as before, with a > non-zero port but a null address for the constituent MDs. (I assume > that intermediate devices realize that a null address means that it > will see no media on that transport flow.) If an O/A exchange has been concluded and the result is that one end has a valid address, and the other end has null (zero/.invalid) address, can't that be construed as establishing a oneway media stream where RTCP is also oneway? I don't think this has ever been discussed. Thanks, Paul From mary.ietf.barnes@gmail.com Wed Feb 27 16:15:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4166621F87F3 for ; Wed, 27 Feb 2013 16:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtZbskM31ffV for ; Wed, 27 Feb 2013 16:15:57 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26F21F8746 for ; Wed, 27 Feb 2013 15:53:49 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so966823qen.18 for ; Wed, 27 Feb 2013 15:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dIrgeaJeaU6v93FUoBfONdq8ZTOimKmLIX478yv8v68=; b=cdng/vCB0v07XMNjOXjnop9Fctz5Lsox+VhUMDQi6LHjGsgKzZwwI+1Ymer6YNU+wH E/WW0BF0tsQKGwZweiKbL7hTLzng/yh7Cxa+Q++LVpwWlkfb/ASFj6XE80qCFW4e9tSK 8tsJJk5Ljp0ty5AQddgTWOVqSYHrQwVywHNF9Pwsy34POlV4YyZSlRYpuFz1OFhLpo35 gF6a39sh6pAmWgs0kg0fPzpXKp1LVweBcW9Rh/RObXCzPimhSWnuPSJwdZuN5rYgJXkg +lrPgYD0exVZkfKq1pRU/5uRR9iSvpbyEqRSRpZduXbNibivg0M+yPUETD7m49QtQksH OeSA== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr11011325qac.63.1362009227526; Wed, 27 Feb 2013 15:53:47 -0800 (PST) Received: by 10.49.24.130 with HTTP; Wed, 27 Feb 2013 15:53:47 -0800 (PST) In-Reply-To: <512E6AEF.2050200@cisco.com> References: <512E6AEF.2050200@cisco.com> Date: Wed, 27 Feb 2013 17:53:47 -0600 Message-ID: From: Mary Barnes To: Flemming Andreasen Content-Type: text/plain; charset=ISO-8859-1 Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:16:00 -0000 I think it would be much clearer and more accurate if you would separate out the documents under the "RTCWEB related drafts" into those that are more general multi-stream related documents and those that are RTCWEB specific - e.g., draft-jennings-rtcweb-plan-01 is clearly an RTCWEB related draft. Whereas, many of the other drafts are proposing solutions that might well be useful for other applications such as CLUE. I think it's really important that the MMUSIC WG keeps in mind that RTCWEB requirements are not the only ones that need to be considered in the context of the multi-stream work. Thanks, Mary On Wed, Feb 27, 2013 at 2:22 PM, Flemming Andreasen wrote: > The MMUSIC draft agenda for IETF 86 has been posted at: > > https://datatracker.ietf.org/meeting/86/agenda/mmusic/ > > Please take a look and let us know if you have any questions or comments. > > Thanks > > Ari & Flemming > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ted.ietf@gmail.com Wed Feb 27 17:59:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0988721F842F for ; Wed, 27 Feb 2013 17:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkNn3hf3cjvh for ; Wed, 27 Feb 2013 17:59:44 -0800 (PST) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCA21F9500 for ; Wed, 27 Feb 2013 16:34:37 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so1037599iaz.30 for ; Wed, 27 Feb 2013 16:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Qxx4R9QwoETHUFE1v2T9MmxMT9+xEsJZ/u6qbRyVIb8=; b=iQ10cIhLkm789x3TmMU273wPp3W/NIy5yOUx3DOuKQnpA9MFAYm/b6zdLj1laEoxpB zuNJaU9z5jVS6j8E/pTu7mnteX/ZA86sJ+viKWBhyfxxu1ozk6zbP1gURWIf6cTOu16T 9jcX3RPSADdZSUL5wsUJIGtEC5O9TFYC8NnexLqNLma+eDxI4TGck2HjiRzexylPeqhd 08x5ZEz1d/+t27Rih3BjJx2lHNzaBFuM2TrAYJ8DlvPqwvPG8MQvUMVXFPE8AikC/NZd 4NRH7ckU9ebSLf/cd9MRbpXje7RQV348lkzt2UQyqTCdgdjtWcKQUjpV5hRMRPot9k1t hJhQ== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr8566295igc.20.1362011649402; Wed, 27 Feb 2013 16:34:09 -0800 (PST) Received: by 10.43.135.202 with HTTP; Wed, 27 Feb 2013 16:34:09 -0800 (PST) In-Reply-To: References: <512E6AEF.2050200@cisco.com> Date: Wed, 27 Feb 2013 16:34:09 -0800 Message-ID: From: Ted Hardie To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 01:59:45 -0000 On Wed, Feb 27, 2013 at 3:53 PM, Mary Barnes wrote: > I think it would be much clearer and more accurate if you would > separate out the documents under the "RTCWEB related drafts" into > those that are more general multi-stream related documents and those > that are RTCWEB specific - e.g., draft-jennings-rtcweb-plan-01 is > clearly an RTCWEB related draft. Actually, that document says this: "The requirements listed here are a collection of requirements that have come from WebRTC, CLUE, and the general community that uses RTP for interactive communications based on Offer/Answer." So filename may not be the perfect indicator of author intent. Ted > Whereas, many of the other drafts are > proposing solutions that might well be useful for other applications > such as CLUE. I think it's really important that the MMUSIC WG keeps > in mind that RTCWEB requirements are not the only ones that need to be > considered in the context of the multi-stream work. > > Thanks, > Mary > > On Wed, Feb 27, 2013 at 2:22 PM, Flemming Andreasen wrote: >> The MMUSIC draft agenda for IETF 86 has been posted at: >> >> https://datatracker.ietf.org/meeting/86/agenda/mmusic/ >> >> Please take a look and let us know if you have any questions or comments. >> >> Thanks >> >> Ari & Flemming >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@iii.ca Wed Feb 27 19:01:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878921F8A38 for ; Wed, 27 Feb 2013 19:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHosaBNLvj4P for ; Wed, 27 Feb 2013 19:01:49 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id EEB7421F88DD for ; Wed, 27 Feb 2013 19:01:48 -0800 (PST) Received: from dhcp-171-68-20-36.cisco.com (unknown [171.68.20.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 758E8509B5 for ; Wed, 27 Feb 2013 22:01:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Wed, 27 Feb 2013 19:01:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512E6AEF.2050200@cisco.com> To: mmusic WG X-Mailer: Apple Mail (2.1499) Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 03:01:50 -0000 On Feb 27, 2013, at 4:34 PM, Ted Hardie wrote: > Actually, that document says this: >=20 > "The requirements listed here are a collection of requirements that > have come from WebRTC, CLUE, and the general community that uses RTP > for interactive communications based on Offer/Answer." >=20 > So filename may not be the perfect indicator of author intent. plan is pretty much a grab bag list of things so a bunch of it might = relate to all things using RTP/SDP while others are more or less rtcweb = specific and at lest one is probably only specific to CLUE. It's hard to = name.= From mary.ietf.barnes@gmail.com Thu Feb 28 06:21:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4621F8745 for ; Thu, 28 Feb 2013 06:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGjuVaqTErWb for ; Thu, 28 Feb 2013 06:21:33 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id A901121F8621 for ; Thu, 28 Feb 2013 06:21:33 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id 9so1427918qea.35 for ; Thu, 28 Feb 2013 06:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k+7DVgkPoZNORwAA56kT5clnUU0sxKqtoUEtttT0rQM=; b=fPiTI9Rp2e1Ro4F/a+UTcEX5rsO5zNjxbLuBD95zFE7bKO3uGiUHCWtr0V/pDeUNtA PhTyzuwJa9lPyMnkCLXaipLOvspK6EqP3gJvLJmff6M2i63XCl3InIAYzyghAs1k0hem qj/zYWMVDAtAdJjHdj3IqTYRP6HXKVcH/yrf4gOYYVDF6lTO3AZsk4ysEbcJMbq8GO7d bxiJLdYwlQFY/Nfe3Nlm2v1C+7v0LlXDGeJoDuYJeakc19blzYOdFSiuSMHTl6GZsDEG GOakrLdHMltUyxuRevhgSmveOlqsZLGUFuAAIYqC0hHbQkwxbt5sP01aFO12ktr3xegs 0e8w== MIME-Version: 1.0 X-Received: by 10.224.193.200 with SMTP id dv8mr6412191qab.85.1362061286737; Thu, 28 Feb 2013 06:21:26 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 28 Feb 2013 06:21:26 -0800 (PST) In-Reply-To: References: <512E6AEF.2050200@cisco.com> Date: Thu, 28 Feb 2013 08:21:26 -0600 Message-ID: From: Mary Barnes To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 86 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:21:35 -0000 On Wed, Feb 27, 2013 at 6:34 PM, Ted Hardie wrote: > On Wed, Feb 27, 2013 at 3:53 PM, Mary Barnes wrote: >> I think it would be much clearer and more accurate if you would >> separate out the documents under the "RTCWEB related drafts" into >> those that are more general multi-stream related documents and those >> that are RTCWEB specific - e.g., draft-jennings-rtcweb-plan-01 is >> clearly an RTCWEB related draft. > > Actually, that document says this: > > "The requirements listed here are a collection of requirements that > have come from WebRTC, CLUE, and the general community that uses RTP > for interactive communications based on Offer/Answer." > > So filename may not be the perfect indicator of author intent. > > Ted [MB] Yeah - I had just assumed that was rtcweb only stuff. But, that just re-enforces my point that I don't believe this section should be referenced as "RTCWEB related drafts" - either include CLUE in the header or make the topic more general. I actually prefer the former as I think it's really important for more of the CLUE participants to get engaged in these discussions and understand that the decisions in MMUSIC need CLUE input and may impact the overall CLUE solution. [/MB] > >> Whereas, many of the other drafts are >> proposing solutions that might well be useful for other applications >> such as CLUE. I think it's really important that the MMUSIC WG keeps >> in mind that RTCWEB requirements are not the only ones that need to be >> considered in the context of the multi-stream work. >> >> Thanks, >> Mary >> >> On Wed, Feb 27, 2013 at 2:22 PM, Flemming Andreasen wrote: >>> The MMUSIC draft agenda for IETF 86 has been posted at: >>> >>> https://datatracker.ietf.org/meeting/86/agenda/mmusic/ >>> >>> Please take a look and let us know if you have any questions or comments. >>> >>> Thanks >>> >>> Ari & Flemming >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From worley@shell01.TheWorld.com Thu Feb 28 11:48:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B62A21F8802 for ; Thu, 28 Feb 2013 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdFs8o0e34Cw for ; Thu, 28 Feb 2013 11:48:15 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4221F882D for ; Thu, 28 Feb 2013 11:48:09 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1SJlxWr023106; Thu, 28 Feb 2013 14:48:01 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1SJlwOo2780308; Thu, 28 Feb 2013 14:47:58 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1SJlw5G2774808; Thu, 28 Feb 2013 14:47:58 -0500 (EST) Date: Thu, 28 Feb 2013 14:47:58 -0500 (EST) Message-Id: <201302281947.r1SJlw5G2774808@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <512E8C99.20701@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201302272156.r1RLut982750103@shell01.TheWorld.com> <512E8C99.20701@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Better way to not-really-offer constituent media descriptions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 19:48:16 -0000 > From: Paul Kyzivat > > If an O/A exchange has been concluded and the result is that one end has > a valid address, and the other end has null (zero/.invalid) address, > can't that be construed as establishing a oneway media stream where RTCP > is also oneway? Aye, that's true, assuming the old model "null address = on-hold". So you'd need an SDP update to clear that up after connecting with a supporting endpoint. Although the update wouldn't be needed to get media flowing. Dale From dwing@cisco.com Thu Feb 28 14:52:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614ED21F8858 for ; Thu, 28 Feb 2013 14:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.218 X-Spam-Level: X-Spam-Status: No, score=-110.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO7WOoUGlu-Y for ; Thu, 28 Feb 2013 14:51:54 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 751B521F884F for ; Thu, 28 Feb 2013 14:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1362091912; x=1363301512; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=eAt65xz6FdnKaQ8Jh4IT8cEmrxczrubbuxN9Tpg/oFo=; b=fnJ5aCswv4mXqUDOMoFA2ls5OzG5G0kCzAPhGbEL4xzTgFnywWLY5Lju wESlb8KQYsWyaib++/fJmJ9ZKJbaqzIDeTxvN+hbxjcneTeV0Hr4Ad7K3 VAlp0ZVH8sJda6wBiL27CECoK7KYleGbKE6KJ+SMW/hzOyMWwWt4DKYCi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOzdL1GrRDoH/2dsb2JhbABFwjN9FnOCHwEBAQMBAQEBBQIwLQcQBwEDAgkRBAEBKAcZDh8JCAIEARILBYd9BQ3BNASPCRIGgzoDiGqFLYgqkGqDKQ X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; d="scan'208";a="73652360" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 28 Feb 2013 22:51:52 +0000 Received: from DWINGWS01 ([10.156.16.168]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1SMpqCa016575; Thu, 28 Feb 2013 22:51:52 GMT From: "Dan Wing" To: "'Dale R. Worley'" , References: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> In-Reply-To: <201302272158.r1RLw6t72679355@shell01.TheWorld.com> Date: Thu, 28 Feb 2013 14:51:52 -0800 Message-ID: <0ed301ce1606$33062a60$99127f20$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1cqWZvkvgjV7WYvae28mXmIpmPJhBJTxg Content-Language: en-us Subject: Re: [MMUSIC] Where to apply encryption? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:52:01 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Dale R. Worley > Sent: Wednesday, February 27, 2013 1:58 PM > To: mmusic@ietf.org > Subject: [MMUSIC] Where to apply encryption? > > Current bundling proposals seem to expect that the packets on the wire > will be either SRTP/SRTCP or SCTP-within-DTLS. Of course, this provides > encryption of the carried media. > > But it seems to me that it would be more straightforward to multiplex > RTP/RTCP and SCTP packets, and than as a lower layer, have one DTLS > association that encrypts all of those packets indifferently. It would > also provide privacy regarding the number and types of the bundled media > streams. SRTP (RFC3711) was carefully and purposefully designed so the RTP header remains in the clear, and DTLS-SRTP was also purposefully designed so after the DTLS-SRTP handshake establishes the SRTP keys, the SRTP packets flow over the wire exactly like they would for any other keying mechanism (ZRTP, MIKEY-*, Security Descriptions). By sending SRTP packets with their RTP header in the clear, it allows: * the RTP header to be compressed (cRTP [RFC2508], ECRTP [RFC3545]) * analysis devices to see where, on a network path, SRTP packets are lost, delayed, or get mis-ordered. * analysis devices to see SRTCP receiver reports and sender reports, which are typically authenticated but in the clear. > But my knowledge of crypto is thin, and maybe there's a reason that > using one DTLS association to encrypt the multiplexed packet stream > wouldn't work as well. -d > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic