From palmarti@cisco.com Tue Apr 2 02:59:19 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 0B45F21F97E0 for ; Tue, 2 Apr 2013 02:59:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj9Z4RiCn4rf for ; Tue, 2 Apr 2013 02:59:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7054521F97CC for ; Tue, 2 Apr 2013 02:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1364896758; x=1366106358; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MUOACNjNe8rd4qKeGrtWG6VerlOyQyo2v3pU1dXtfkI=; b=akQmheX82RqQM3XZMlwchr6aQrFrk36TgTftUwpS9sNl5yECrfMM2GCA XzxS3p2pfQUPlKjige7t0LJN14S3dsxX9cBl/qVFR2fkbGDPeF052E3Y3 o1BOAtyUKQjYHJBME8Bglaf8xTRw/XEDpJeGH3nLI+FG26UNTwAgBkw3c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAA2rWlGtJV2d/2dsb2JhbABDgzu/Q4ECFnSCIQEEeRIBKlYnBA4NiAwMsRCQD455MYJmYQOIQo9Ij2yDC4Io X-IronPort-AV: E=Sophos;i="4.87,392,1363132800"; d="scan'208";a="193772076" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Apr 2013 09:59:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r329xIhD001173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 09:59:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 04:59:17 -0500 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: ICEbis: INTEGRITY attribute in Binding Responses clarification Thread-Index: AQHOL4i91kOsilde8UigXRvzFJV/5g== Date: Tue, 2 Apr 2013 09:59:17 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11379413@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <265F16576385914CA6D48BB43A0DCA3B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: [MMUSIC] ICEbis: INTEGRITY attribute in Binding Responses clarification 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, 02 Apr 2013 09:59:19 -0000 Hi, I was reading through the ICE RFC and trying to figure out if Binding Respo= nses needed the INTEGRITY attribute. Usually the ICE RFC is very descriptiv= e in what to include in the messages, but I could not find any text clearly= stating that the INTEGRITY attribute must be included in the Binding Respo= nses.=20 When reading the STUN RFC it states in section 7.3.1.1: "If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 10)." Is this SHOULD strong enough for the connectivity checks performed by ICE?= =20 Should it be changed to a MUST? To spell it out for readers like me, I propose the following changes to sec= tion 7.2 the second paragraph of the ICE RFC (http://tools.ietf.org/html/draft-keranen-mmusic-rfc5245bis-01#section-7.2) The agent MUST use a short-term credential (i.e., the MESSAGE-INTEGRITY attribute) to authenticate and perform a message integrity check on the request and=20 any response to that request.=20 Adding the following to section 7.1.3.1 might also help to remind the imple= mentors: The agent MUST use the INTEGRITY-MESSAGE attribute in the Binding Respons= e to authenticate the message.=20 .-. P=E5l-Erik Martinsen From petithug@acm.org Tue Apr 2 08: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 88CD321F8BBC for ; Tue, 2 Apr 2013 08:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 FcuB9cBtvknY for ; Tue, 2 Apr 2013 08:45:06 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84721F8BA6 for ; Tue, 2 Apr 2013 08:45:06 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:3030:2e3e:5f01:6685] (unknown [IPv6:2601:9:4bc0:1f:3030:2e3e:5f01:6685]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 27960202D8 for ; Tue, 2 Apr 2013 17:45:05 +0200 (CEST) Message-ID: <515AFCFE.7030608@acm.org> Date: Tue, 02 Apr 2013 08:45:02 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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, 02 Apr 2013 15:45:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I read draft-ivov-dispatch-trickle-ice-sip and draft-ivov-mmusic-trickle-ice during the preparation of the rfc5245bis draft and I have some suggestions that I will be presenting step by step below: 1. The 180 needs to be reliable In section 6 of trickle-ice-sip, the Answer is carried by a 180 response, which can be lost before the INFO request is received. The 180 will probably be resent later, but that still does not look right to send new candidates without be sure that the first batch of candidates have been received. PRACK seems the right solution to this issue. Also 183 seems a better fit than 180, at least until all the candidates are sent, but that's not really important. That gives us this call flow: STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | |<--------------| | | | Candidate | | | | Discovery | | | |-------------->| INVITE (Offer) | | | |------------------------>| | | | 183 (Answer) |-------------->| | |<------------------------| | | | PRACK | | | |------------------------>| | | | 200 PRACK | | | |<------------------------| | | | | | | | INFO (more candidates) | Candidate | | |<------------------------| | | | Connectivity Checks | | | |<=======================>| Discovery | | | INFO (more candidates) |<--------------| | |<------------------------| | | | 180 | | | |<------------------------| | | | Connectivity Checks | | | |<=======================>| | | | | | | | 200 OK | | | |<------------------------| | | | | | | | 5245 SIP re-INVITE | | | |------------------------>| | | | 200 OK | | | |<------------------------| | | | | | | | | | | |<===== MEDIA FLOWS =====>| | | | | | 2. Use UPDATE instead of INFO UPDATE works as well as INFO, and is more SIPish. Here's the call flow: STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | |<--------------| | | | Candidate | | | | Discovery | | | (1) |-------------->| INVITE (Offer) | | | |------------------------>| | (2) | | 183 (Answer) |-------------->| | |<------------------------| | | | PRACK | | | |------------------------>| | | | 200 PRACK | | | |<------------------------| | | | | | (3) | | UPDATE (more cands) | Candidate | | |<------------------------| | (4) | | 200 UPDATE | | | |------------------------>| Discovery | | | Connectivity Checks | | | |<=======================>| | (5) | | UPDATE (last cands) |<--------------| | |<------------------------| | (6) | | 200 UPDATE | | | |------------------------>| | | | 180 | | | |<------------------------| | | | Connectivity Checks | | | |<=======================>| | | | | | | | 200 INVITE | | | |<------------------------| | | | | | | | 5245 SIP re-INVITE | | | |------------------------>| | | | 200 reINVITE | | | |<------------------------| | | | | | | | | | | |<===== MEDIA FLOWS =====>| | | | | | 3. Use accumulated candidate list As far as I understand the documents, the candidates are sent as soon as they are discovered. I think that it would be better to send an accumulated list of candidates instead of the delta list of candidates. The priority calculation and the elimination of redundant candidates do not need to know the complete list of candidate to work, but sending the accumulated list instead of a delta could permit in the future to remove candidates, if we find a need to do so. This also removed the need for sdpfrag. But the most important reason is for the next step. 4. Replace end-of-candidates attribute by precandidate attributes There is currently an end-of-candidates attribute that is sent to signal the end of the candidate gathering phase. I think it is better to do it the opposite way, i.e. to send candidates as they are discovered under a different attribute name, and then to send all the candidates only when the gathering phase is done. Here's the partial SDPs exchanged in the call flow in 2) but skipping one update (examples are from RFC 5245): (1) Alice sends all the candidates after the end of the gathering phase (half-trickle). She also signals that she supports trickle. a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host (2) Bob knows that Alice supports half trickle, so he sends only the host candidates, which is all he has so far, but using the attribute precandidate instead of candidate. He sends them in a reliable 183: a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host If Bob supported ICE but not trickle, he would have answered with its complete list of candidates. (3) Bob discovers some candidates, but there is more to come, so it sends a accumulated list of precandidates: a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host (4) Alice responds with the same SDP than in (1) (5) Bob receives the last batch of candidates, so now it sends an SDP containing the all the candidates, as if it did not understand trickle.: a=ice-options:trickle a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host (6) Alice sends back the same SDP. Because Bob use candidate attributes instead of precandidate, she knows that she has all the candidates, as if end-of-candidates was received. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb yk3C5OOf2RWXhf6ekDuf =jzXd -----END PGP SIGNATURE----- From harald@alvestrand.no Tue Apr 2 09:53: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 0604E21F8B0A for ; Tue, 2 Apr 2013 09:53:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh+el-+Su03o for ; Tue, 2 Apr 2013 09:53:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9621F8B04 for ; Tue, 2 Apr 2013 09:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85E1739E0F3 for ; Tue, 2 Apr 2013 18:53:46 +0200 (CEST) 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 t8EjboWMQ3Qq for ; Tue, 2 Apr 2013 18:53:45 +0200 (CEST) Received: from [172.30.42.102] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B0CC239E01E for ; Tue, 2 Apr 2013 18:53:45 +0200 (CEST) Message-ID: <515B0D19.1010509@alvestrand.no> Date: Tue, 02 Apr 2013 18:53:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic@ietf.org References: <201303292056.r2TKuDBk1423802@shell01.TheWorld.com> In-Reply-To: <201303292056.r2TKuDBk1423802@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Feedback requested on requirements 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, 02 Apr 2013 16:53:49 -0000 On 03/29/2013 09:56 PM, Dale R. Worley wrote: > The discussion of requirements for bundling has been thin. I'd like > to go through the things that I have seen raised as "desiderata" (what > we desire, though it may not be absolutely required) and get feedback > from people on them. > > Here is the first installment: > > > 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. I challenge this description - the term "application-level RTP session" is not defined. There are RTP sessions (which are defined by being a single SSRC namespace). If you want a new concept, call it something else. For myself, I'm happy with describing single flows (SSRCs), all flows of the same type (payload types), and all flows in an RTP session; I think adding a fourth level of granularity is more trouble than it's worth. > > This requirement is taken from [I-D.jennings-mmusic-media-req]. > > 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. > > > Comments? > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From worley@shell01.TheWorld.com Tue Apr 2 13:20: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 8F50521F8D31 for ; Tue, 2 Apr 2013 13:20:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z6aJ4xDeLDA for ; Tue, 2 Apr 2013 13:20:06 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD421F8DAC for ; Tue, 2 Apr 2013 13:20:05 -0700 (PDT) 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 r32KJ4oa030981 for ; Tue, 2 Apr 2013 16:19:06 -0400 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 r32KJ4Ju1819756 for ; Tue, 2 Apr 2013 15:19:04 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r32KJ4QC1817284; Tue, 2 Apr 2013 16:19:04 -0400 (EDT) Date: Tue, 2 Apr 2013 16:19:04 -0400 (EDT) Message-Id: <201304022019.r32KJ4QC1817284@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 02 Apr 2013 20:20:06 -0000 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. Comments? Dale From thomas.stach@siemens-enterprise.com Wed Apr 3 06:01: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 9F27521F8D2E for ; Wed, 3 Apr 2013 06:01:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15+vBt-2TC59 for ; Wed, 3 Apr 2013 06:01:34 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13E21F8D2B for ; Wed, 3 Apr 2013 06:01:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5B55A1EB8481; Wed, 3 Apr 2013 15:01:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 3 Apr 2013 15:01:32 +0200 From: "Stach, Thomas" To: Marc Petit-Huguenin , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice Thread-Index: AQHOL7kRDf6aeN36rE2qZ64lnSNh25jEbY6g Date: Wed, 3 Apr 2013 13:01:31 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> In-Reply-To: <515AFCFE.7030608@acm.org> Accept-Language: de-AT, en-US Content-Language: de-DE 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] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 13:01:35 -0000 Some thoughts inline Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > I read draft-ivov-dispatch-trickle-ice-sip and > draft-ivov-mmusic-trickle-ice > during the preparation of the rfc5245bis draft and I have > some suggestions > that I will be presenting step by step below: >=20 > 1. The 180 needs to be reliable >=20 > In section 6 of trickle-ice-sip, the Answer is carried by a 180 > response, which can be lost before the INFO request is received. The > 180 will probably be resent later, but that still does not look right > to send=20 > new candidates > without be sure that the first batch of candidates have been > received. PRACK seems the right solution to this issue. =20 There was a large debate in back IETF 64 if ICE should require usage of PRA= CK. The conclusion was to go without PRACK, but instead re-transmit the 183 wit= h the answer until=20 a STUN onnectivity check was received at the answerer (ice-06 --> ice-07) Receipt of that connectivity check is the indicator that the the answer arr= ived at the offerer. Of course with trickle-ICE things are different since you might not yet hav= e the candidate that will finally work. However, I think this issue can be resolved using your proposal from furthe= r down, i.e. always send the accumulated=20 list of candidates instead of just deltas. Consequently, you always have th= e complete list of candidates even if=20 the provisonal response got lost. > Also 183 seems a=20 > better fit than 180, Yes, (vanilla)ICE specifies to alert the callee and sent the 180 only after= connectivity checks were succesful.=20 I don't think this should be changed. > at least until all the candidates are sent, but that's not > really important. > That gives us this call flow: >=20 >=20 > STUN/Turn > STUN/TURN > Servers Alice Bob Servers > | | | | > |<--------------| | | > | Candidate | | | > | Discovery | | | > |-------------->| INVITE (Offer) | | > | |------------------------>| | > | | 183 (Answer) |-------------->| > | |<------------------------| | > | | PRACK | | > | |------------------------>| | > | | 200 PRACK | | > | |<------------------------| | > | | | | > | | INFO (more candidates) | Candidate | > | |<------------------------| | > | | Connectivity Checks | | > | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| Discovery | > | | INFO (more candidates) |<--------------| > | |<------------------------| | > | | 180 | | > | |<------------------------| | > | | Connectivity Checks | | > | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| | > | | | | > | | 200 OK | | > | |<------------------------| | > | | | | > | | 5245 SIP re-INVITE | | > | |------------------------>| | > | | 200 OK | | > | |<------------------------| | > | | | | > | | | | > | |<=3D=3D=3D=3D=3D MEDIA FLOWS =3D=3D=3D=3D=3D>|= | > | | | | >=20 >=20 > 2. Use UPDATE instead of INFO >=20 > UPDATE works as well as INFO, and is more SIPish. >=20 > Here's the call flow: >=20 > STUN/Turn > STUN/TURN > Servers Alice Bob Servers > | | | | > |<--------------| | | > | Candidate | | | > | Discovery | | | > (1) |-------------->| INVITE (Offer) | | > | |------------------------>| | > (2) | | 183 (Answer) |-------------->| > | |<------------------------| | > | | PRACK | | > | |------------------------>| | > | | 200 PRACK | | > | |<------------------------| | > | | | | > (3) | | UPDATE (more cands) | Candidate | > | |<------------------------| | > (4) | | 200 UPDATE | | > | |------------------------>| Discovery | > | | Connectivity Checks | | > | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| | > (5) | | UPDATE (last cands) |<--------------| > | |<------------------------| | > (6) | | 200 UPDATE | | > | |------------------------>| | > | | 180 | | > | |<------------------------| | > | | Connectivity Checks | | > | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| | > | | | | > | | 200 INVITE | | > | |<------------------------| | > | | | | > | | 5245 SIP re-INVITE | | > | |------------------------>| | > | | 200 reINVITE | | > | |<------------------------| | > | | | | > | | | | > | |<=3D=3D=3D=3D=3D MEDIA FLOWS =3D=3D=3D=3D=3D>|= | > | | | | >=20 >=20 > 3. Use accumulated candidate list >=20 > As far as I understand the documents, the candidates are sent > as soon as they > are discovered. I think that it would be better to send an > accumulated list of candidates instead of the delta list of > candidates. =20 I think this is a good idea due to the reasons above.=20 It could make interworking easier for a GW to the SIP world with vanilla IC= E devices. > The priority calculation and the elimination of > redundant candidates do=20 > not need to know > the complete list of candidate to work, but sending the > accumulated list > instead of a delta could permit in the future to remove > candidates, if we find > a need to do so. This also removed the need for sdpfrag. Why is this? Do you propose that the UPDATE always includes the complete SDP offer/answe= r? My assumption is that just the complete list of candidates is updated using= sdpfrag. >=20 > But the most important reason is for the next step. >=20 >=20 > 4. Replace end-of-candidates attribute by precandidate attributes >=20 > There is currently an end-of-candidates attribute that is > sent to signal the > end of the candidate gathering phase. I think it is better > to do it the > opposite way, i.e. to send candidates as they are discovered > under a different > attribute name, and then to send all the candidates only when > the gathering > phase is done. =20 I don't see the benefit of using a different attribute name instead of the = new end-of-candidates attribute. I am not objecting, but could you explain the advantage? > Here's the partial SDPs exchanged in the call > flow in 2) but > skipping one update (examples are from RFC 5245): >=20 > (1) Alice sends all the candidates after the end of the > gathering phase > (half-trickle). She also signals that she supports trickle. >=20 > a=3Dice-options:trickle > a=3Dcandidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host >=20 > (2) Bob knows that Alice supports half trickle, so he sends > only the host > candidates, which is all he has so far, but using the > attribute precandidate > instead of candidate. He sends them in a reliable 183: >=20 > a=3Dice-options:trickle > a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >=20 > If Bob supported ICE but not trickle, he would have answered > with its complete > list of candidates. >=20 > (3) Bob discovers some candidates, but there is more to come, > so it sends a > accumulated list of precandidates: >=20 > a=3Dice-options:trickle > a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=3Dprecandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx > raddr 10.0.1.1 > rport 8998 > a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >=20 > (4) Alice responds with the same SDP than in (1) >=20 > (5) Bob receives the last batch of candidates, so now it sends an SDP > containing the all the candidates, as if it did not > understand trickle.: >=20 > a=3Dice-options:trickle > a=3Dcandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=3Dcandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx > raddr 10.0.1.1 rport > 8998 > a=3Dcandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >=20 > (6) Alice sends back the same SDP. Because Bob use candidate > attributes instead of precandidate, she knows that she has all the > candidates, as if > end-of-candidates was received. >=20 > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO > J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH > MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli > 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh > uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 > snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r > mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm > eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR > FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr > Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ > GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb > yk3C5OOf2RWXhf6ekDuf =3DjzXd > -----END PGP SIGNATURE----- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic= From petithug@acm.org Wed Apr 3 08: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 5854421F8E7B for ; Wed, 3 Apr 2013 08:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yIWYZp7teZHJ for ; Wed, 3 Apr 2013 08:31:32 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E8EDD21F8CEC for ; Wed, 3 Apr 2013 08:31:31 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f] (unknown [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 860CB202D8; Wed, 3 Apr 2013 17:31:30 +0200 (CEST) Message-ID: <515C4B4F.6080203@acm.org> Date: Wed, 03 Apr 2013 08:31:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "Stach, Thomas" References: <515AFCFE.7030608@acm.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 15:31:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Inline. On 04/03/2013 06:01 AM, Stach, Thomas wrote: > Some thoughts inline > > Marc Petit-Huguenin wrote: I read draft-ivov-dispatch-trickle-ice-sip and > draft-ivov-mmusic-trickle-ice during the preparation of the rfc5245bis > draft and I have some suggestions that I will be presenting step by step > below: > > 1. The 180 needs to be reliable > > In section 6 of trickle-ice-sip, the Answer is carried by a 180 response, > which can be lost before the INFO request is received. The 180 will > probably be resent later, but that still does not look right to send new > candidates without be sure that the first batch of candidates have been > received. PRACK seems the right solution to this issue. >> There was a large debate in back IETF 64 if ICE should require usage of >> PRACK. The conclusion was to go without PRACK, but instead re-transmit >> the 183 with the answer until a STUN onnectivity check was received at >> the answerer (ice-06 --> ice-07) Receipt of that connectivity check is >> the indicator that the the answer arrived at the offerer. Of course with >> trickle-ICE things are different since you might not yet have the >> candidate that will finally work. However, I think this issue can be >> resolved using your proposal from further down, i.e. always send the >> accumulated list of candidates instead of just deltas. Consequently, you >> always have the complete list of candidates even if the provisonal >> response got lost. Right, but PRACK is mandatory anyway for UPDATE, so using accumulated candidates seems a good idea when using INFO, so there is no need to PRACK the 18x. Considering this now, INFO may have a slight advantage over UPDATE. > > Also 183 seems a better fit than 180, >> Yes, (vanilla)ICE specifies to alert the callee and sent the 180 only >> after connectivity checks were succesful. I don't think this should be >> changed. > > at least until all the candidates are sent, but that's not really > important. That gives us this call flow: > > > STUN/Turn STUN/TURN Servers Alice Bob > Servers | | | | > |<--------------| | | | Candidate > | | | | Discovery | > | | |-------------->| INVITE (Offer) | > | | |------------------------>| | | > | 183 (Answer) |-------------->| | > |<------------------------| | | | PRACK > | | | |------------------------>| > | | | 200 PRACK | | | > |<------------------------| | | | > | | | | INFO (more candidates) | Candidate > | | |<------------------------| | | > | Connectivity Checks | | | > |<=======================>| Discovery | | | INFO (more > candidates) |<--------------| | |<------------------------| > | | | 180 | | | > |<------------------------| | | | Connectivity > Checks | | | |<=======================>| > | | | | | | > | 200 OK | | | > |<------------------------| | | | > | | | | 5245 SIP re-INVITE | > | | |------------------------>| | | > | 200 OK | | | > |<------------------------| | | | > | | | | | > | | |<===== MEDIA FLOWS =====>| | | > | | | > > > 2. Use UPDATE instead of INFO > > UPDATE works as well as INFO, and is more SIPish. > > Here's the call flow: > > STUN/Turn STUN/TURN Servers Alice Bob > Servers | | | | > |<--------------| | | | Candidate > | | | | Discovery | > | | (1) |-------------->| INVITE (Offer) | > | | |------------------------>| | (2) | > | 183 (Answer) |-------------->| | > |<------------------------| | | | PRACK > | | | |------------------------>| > | | | 200 PRACK | | | > |<------------------------| | | | > | | (3) | | UPDATE (more cands) | > Candidate | | |<------------------------| | > (4) | | 200 UPDATE | | | > |------------------------>| Discovery | | | Connectivity > Checks | | | |<=======================>| > | (5) | | UPDATE (last cands) |<--------------| | > |<------------------------| | (6) | | > 200 UPDATE | | | |------------------------>| > | | | 180 | | | > |<------------------------| | | | Connectivity > Checks | | | |<=======================>| > | | | | | | > | 200 INVITE | | | > |<------------------------| | | | > | | | | 5245 SIP re-INVITE | > | | |------------------------>| | | > | 200 reINVITE | | | > |<------------------------| | | | > | | | | | > | | |<===== MEDIA FLOWS =====>| | | > | | | > > > 3. Use accumulated candidate list > > As far as I understand the documents, the candidates are sent as soon as > they are discovered. I think that it would be better to send an > accumulated list of candidates instead of the delta list of candidates. >> I think this is a good idea due to the reasons above. It could make >> interworking easier for a GW to the SIP world with vanilla ICE devices. > > The priority calculation and the elimination of redundant candidates do not > need to know the complete list of candidate to work, but sending the > accumulated list instead of a delta could permit in the future to remove > candidates, if we find a need to do so. This also removed the need for > sdpfrag. >> Why is this? Do you propose that the UPDATE always includes the complete >> SDP offer/answer? Yes. >> My assumption is that just the complete list of candidates is updated >> using sdpfrag. > > > But the most important reason is for the next step. > > > 4. Replace end-of-candidates attribute by precandidate attributes > > There is currently an end-of-candidates attribute that is sent to signal > the end of the candidate gathering phase. I think it is better to do it > the opposite way, i.e. to send candidates as they are discovered under a > different attribute name, and then to send all the candidates only when the > gathering phase is done. >> I don't see the benefit of using a different attribute name instead of >> the new end-of-candidates attribute. I am not objecting, but could you >> explain the advantage? I must say that I do not have a strong argument in favor of this. It seems easier from a developer point of view: candidate attributes are implemented identically with or without trickle, precandidate attributes are only implemented with trickle. Also when looking at an SDP, you see immediately what is what, i.e. with the existing proposal all SDP looks the same, apart for the end-of-candidates thing. But as I said, not a strong argument. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXEtMAAoJECnERZXWan7EYQcQAJ+bGQadrLnMpRQ3/p47/o5j oxkgH/HYzGYT4I8IcPudQfTdP/vQnBlrGA8fiSA9KAI/N5mtwjURsRWYnxbmPq4o oaBq1xyKW+ALlUgVaylKGldeTguee2pm05VYUnL01cjb/O5cOm9oarETRbpgks72 fT0oS9hIiryBP/NoUcLNZ5QZnvv05huDjTmJw0FiIZFWAmKg9TED8K7bb6dgxs3D PRpg9Cbhe75LrdUCldbxhTTl5Wpm+XnfgZDAl1CAtBnW/xBlOj+qOZ7Kr0UHc1gv vrB3fLHxkTNXi7yfWwtQCDhl/EddRs5zhFac5J61wmQ7EITG5HJ6+eDR9eLRRBIl IHumyztefDvKyQn2KVapNdGV8xCkID1DMsYqtvDjXvbiTmLb0rmi30LzQtqd9v7m kJ8nyAkmT5hnoRmJwlR4KVXtKCAjQ4QPNVq15OBY65gnK/1nj3BZDu4so7wTBygv Aev3GWV+53rJV0qFqPVfvZ60oWah5tcnrCp+rSz3iBxzvfV9wMz4jeskimGpctPf bUxl+GqgHRYZAC4Mz/4xCz4mv9RtmeW05s50y/kUKSr7dd2VwEq/XBq6PCXI108w bJUjBTqu0C0nulJaPgHScyoPlM6T83/YIp6EOPqsWgJAEj1vo+T55ihVnBZcMne6 SlUrT/Wsep9Xu2hnmFdK =lrh6 -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Wed Apr 3 10:12: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 6B27321F8FF0 for ; Wed, 3 Apr 2013 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 FKF5RDxuIwJ8 for ; Wed, 3 Apr 2013 10:12:52 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 817F021F8FD6 for ; Wed, 3 Apr 2013 10:12:51 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id KV2g1l0030SCNGk56VCrlt; Wed, 03 Apr 2013 17:12:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id KVCq1l00C3ZTu2S3VVCqqe; Wed, 03 Apr 2013 17:12:50 +0000 Message-ID: <515C6312.1080409@alum.mit.edu> Date: Thu, 04 Apr 2013 01:12:50 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic@ietf.org References: <515AFCFE.7030608@acm.org> <515C4B4F.6080203@acm.org> In-Reply-To: <515C4B4F.6080203@acm.org> 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=1365009171; bh=D6iXwdu9hVu++qPXGwACPGB2FWtAnJSSH6UV0Cm591s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rJsPLFtD7Qs3JQxEhmoRKuKeWviv+cLUzMc6HpxM/0Pex740stKaCmVvT4lFJ1arK 70dhetqmzKHlIah2RFSM6F9C4EYf+N3XjcVN+Bz55hM+1tyTzCcufVhq6gL742n0Nc 13lZak9H9jPFUcKeY6dRjuaMhhVPTjqF64Bv2TkT3yutSsyOi1NGQWkx+1E55DYNTg m6IkjGSdq1L+sHIZhijPgdk+2bFk2O+03sXqoxjp2UqkmkB7os8B3zL8O7DcvEiuJj UK2C2y3FO3Fod/FrM+weUgVy6x5w43cwLWhNZx3YIFLDBa8BGMoiOr11JmOcRzpPJn DaHSOi5CU67Gg== Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 17:12:52 -0000 On 4/3/13 11:31 PM, Marc Petit-Huguenin wrote: > Right, but PRACK is mandatory anyway for UPDATE, so using accumulated > candidates seems a good idea when using INFO, so there is no need to PRACK the > 18x. > > Considering this now, INFO may have a slight advantage over UPDATE. I'm having difficulty making any sense of the above. Are you trying to say that you can't use UPDATE for an offer in an early dialog without first using completing an earlier o/a with PRACK? And then, the advantage of using INFO over UPDATE is because it can go sooner? Yes, I guess it might be able to go sooner. But I think you must carefully consider the interaction of the trickled O/A revisions (or whatever you call them) with the entire O/A state machine. Specifically, please look at RFC 6337, and ensure that what is being proposed is well defined in all the cases described there. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 3 10:22: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 5A2C021F8D82 for ; Wed, 3 Apr 2013 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 s2VoqKbg1Etq for ; Wed, 3 Apr 2013 10:22:06 -0700 (PDT) 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 9E5A021F8E6C for ; Wed, 3 Apr 2013 10:21:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id KQDr1l0051ZXKqc55VMwvj; Wed, 03 Apr 2013 17:21:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id KVMv1l00R3ZTu2S3hVMvQ2; Wed, 03 Apr 2013 17:21:56 +0000 Message-ID: <515C6531.5060001@alum.mit.edu> Date: Thu, 04 Apr 2013 01:21:53 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic@ietf.org References: <515AFCFE.7030608@acm.org> In-Reply-To: <515AFCFE.7030608@acm.org> 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=1365009716; bh=JlBswu8iKNtZ2ZdVmyKOPjIuBQ2y0wALTBtN9loicYU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NNClXql+No2DKBOc78x7YemJVGXl8uE6jXlHtaYcZ6xQGaXmWJnG2MCKSHQJPJGeG hoW3D4z0Ly6xEk9UdEsXV6zBA3+yxMaCZrsaxwMCWXh808WGdGsf3PEq8FxiqVgUTZ 8yGrKCEjR+2tdLLzJzBfdUt6ffiSEM06UP07huV9mtnzeiNWEt9h+dVXplTwM/kemc 9mkgdaQ/EE5/s9h5hMkiEKzM1Gi+RkZ0z1jJggxJSZka2FnAppg/7xfJ9pNgjFsgcP bal7dmBhOvUPNmcvs/LGtfs9MnqgM8tCxVgcmS2XivmLqmOPV17K4uB983XsgGd3bo 4PEF3/VqmKO0A== Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 17:22:10 -0000 I just replied to a later message before dealing with this one. :-( Using UPDATE (in normal sip o/a discipline) means that the hard learned knowledge of how to make o/a work in complex cases can be reused. Conversely, adding INFO as a way to extend the existing O/A mechanism with some additional variations is likely to introduce great additional complexity. Thanks, Paul On 4/2/13 11:45 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I read draft-ivov-dispatch-trickle-ice-sip and draft-ivov-mmusic-trickle-ice > during the preparation of the rfc5245bis draft and I have some suggestions > that I will be presenting step by step below: > > 1. The 180 needs to be reliable > > In section 6 of trickle-ice-sip, the Answer is carried by a 180 response, > which can be lost before the INFO request is received. The 180 will probably > be resent later, but that still does not look right to send new candidates > without be sure that the first batch of candidates have been received. PRACK > seems the right solution to this issue. Also 183 seems a better fit than 180, > at least until all the candidates are sent, but that's not really important. > That gives us this call flow: > > > STUN/Turn STUN/TURN > Servers Alice Bob Servers > | | | | > |<--------------| | | > | Candidate | | | > | Discovery | | | > |-------------->| INVITE (Offer) | | > | |------------------------>| | > | | 183 (Answer) |-------------->| > | |<------------------------| | > | | PRACK | | > | |------------------------>| | > | | 200 PRACK | | > | |<------------------------| | > | | | | > | | INFO (more candidates) | Candidate | > | |<------------------------| | > | | Connectivity Checks | | > | |<=======================>| Discovery | > | | INFO (more candidates) |<--------------| > | |<------------------------| | > | | 180 | | > | |<------------------------| | > | | Connectivity Checks | | > | |<=======================>| | > | | | | > | | 200 OK | | > | |<------------------------| | > | | | | > | | 5245 SIP re-INVITE | | > | |------------------------>| | > | | 200 OK | | > | |<------------------------| | > | | | | > | | | | > | |<===== MEDIA FLOWS =====>| | > | | | | > > > 2. Use UPDATE instead of INFO > > UPDATE works as well as INFO, and is more SIPish. > > Here's the call flow: > > STUN/Turn STUN/TURN > Servers Alice Bob Servers > | | | | > |<--------------| | | > | Candidate | | | > | Discovery | | | > (1) |-------------->| INVITE (Offer) | | > | |------------------------>| | > (2) | | 183 (Answer) |-------------->| > | |<------------------------| | > | | PRACK | | > | |------------------------>| | > | | 200 PRACK | | > | |<------------------------| | > | | | | > (3) | | UPDATE (more cands) | Candidate | > | |<------------------------| | > (4) | | 200 UPDATE | | > | |------------------------>| Discovery | > | | Connectivity Checks | | > | |<=======================>| | > (5) | | UPDATE (last cands) |<--------------| > | |<------------------------| | > (6) | | 200 UPDATE | | > | |------------------------>| | > | | 180 | | > | |<------------------------| | > | | Connectivity Checks | | > | |<=======================>| | > | | | | > | | 200 INVITE | | > | |<------------------------| | > | | | | > | | 5245 SIP re-INVITE | | > | |------------------------>| | > | | 200 reINVITE | | > | |<------------------------| | > | | | | > | | | | > | |<===== MEDIA FLOWS =====>| | > | | | | > > > 3. Use accumulated candidate list > > As far as I understand the documents, the candidates are sent as soon as they > are discovered. I think that it would be better to send an accumulated list > of candidates instead of the delta list of candidates. The priority > calculation and the elimination of redundant candidates do not need to know > the complete list of candidate to work, but sending the accumulated list > instead of a delta could permit in the future to remove candidates, if we find > a need to do so. This also removed the need for sdpfrag. > > But the most important reason is for the next step. > > > 4. Replace end-of-candidates attribute by precandidate attributes > > There is currently an end-of-candidates attribute that is sent to signal the > end of the candidate gathering phase. I think it is better to do it the > opposite way, i.e. to send candidates as they are discovered under a different > attribute name, and then to send all the candidates only when the gathering > phase is done. Here's the partial SDPs exchanged in the call flow in 2) but > skipping one update (examples are from RFC 5245): > > (1) Alice sends all the candidates after the end of the gathering phase > (half-trickle). She also signals that she supports trickle. > > a=ice-options:trickle > a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host > > (2) Bob knows that Alice supports half trickle, so he sends only the host > candidates, which is all he has so far, but using the attribute precandidate > instead of candidate. He sends them in a reliable 183: > > a=ice-options:trickle > a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > If Bob supported ICE but not trickle, he would have answered with its complete > list of candidates. > > (3) Bob discovers some candidates, but there is more to come, so it sends a > accumulated list of precandidates: > > a=ice-options:trickle > a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 > rport 8998 > a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > (4) Alice responds with the same SDP than in (1) > > (5) Bob receives the last batch of candidates, so now it sends an SDP > containing the all the candidates, as if it did not understand trickle.: > > a=ice-options:trickle > a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport > 8998 > a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > (6) Alice sends back the same SDP. Because Bob use candidate attributes > instead of precandidate, she knows that she has all the candidates, as if > end-of-candidates was received. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO > J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH > MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli > 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh > uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 > snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r > mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm > eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR > FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr > Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ > GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb > yk3C5OOf2RWXhf6ekDuf > =jzXd > -----END PGP SIGNATURE----- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From petithug@acm.org Wed Apr 3 11:12: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 3DDCF21F8C6F for ; Wed, 3 Apr 2013 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 m62dPMDRpU7a for ; Wed, 3 Apr 2013 11:12:35 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8B97F21F8D82 for ; Wed, 3 Apr 2013 11:12:35 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f] (unknown [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 337D4202D8; Wed, 3 Apr 2013 20:12:30 +0200 (CEST) Message-ID: <515C710B.70306@acm.org> Date: Wed, 03 Apr 2013 11:12:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Paul Kyzivat References: <515AFCFE.7030608@acm.org> <515C4B4F.6080203@acm.org> <515C6312.1080409@alum.mit.edu> In-Reply-To: <515C6312.1080409@alum.mit.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 18:12:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2013 10:12 AM, Paul Kyzivat wrote: > On 4/3/13 11:31 PM, Marc Petit-Huguenin wrote: > >> Right, but PRACK is mandatory anyway for UPDATE, so using accumulated >> candidates seems a good idea when using INFO, so there is no need to >> PRACK the 18x. >> >> Considering this now, INFO may have a slight advantage over UPDATE. > > I'm having difficulty making any sense of the above. > > Are you trying to say that you can't use UPDATE for an offer in an early > dialog without first using completing an earlier o/a with PRACK? > > And then, the advantage of using INFO over UPDATE is because it can go > sooner? > > Yes, I guess it might be able to go sooner. But I think you must carefully > consider the interaction of the trickled O/A revisions (or whatever you > call them) with the entire O/A state machine. Specifically, please look at > RFC 6337, and ensure that what is being proposed is well defined in all the > cases described there. > I completely agree with you, we should try first to see if trickle fits in O/A before defining extensions like INFO - that was the sense of my original email. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXHEHAAoJECnERZXWan7ECVIP/iRKeur3TGQ5AVjmr20i7RcP g2ze1bqWvjsJ8mTGSkyRLb95rEbv0oCKG8QtgBXs/pgtbEWsReS12zeE8Kkl7GQd Vl06KRMnEylRvgQ9ZpzC/1IJKT92yBrgMEXqhbstrWl49k+KZSPH8u2ZmSV1ClH8 Q4411ux6bPO3fCpv6/Y5wy669IuuESN/w9h/tLQCdgumz9KCwZrWkJK+InTU2OPM we0B8+jWWaqMyoyvxi0XH005oYIrP1Sh4hvSe/C0f/8Nk+K7E88ljnflWRFgL9xT X7yhsFo8a3mrihp7RHV13H218wzdrPA17zbUmLx2JpPMLMjPMPkUIYr1tZA44Tek WEEafQL5gw9dzYjR8VLqad1gi91E7YHVDyxBmpYWqJxZxBQXdyaytFA7m0E6V0e4 sMeOnl9c/Wu+mRaw/xBjAGAH+7Bt1VmZ+DUy3x6OEnWc2z5LpeBySmXUVY8Ibtt1 kfZlAnUu9HuY9PV1elTalBJZbVn1zi79h1LJLpWeJK1yBbjmgmWZQoXQ4qFg+lX5 FjqMrFrXnh9uKE0KIycDBEQaiHFQB645IWpl3Ee7ymZoCu5ukwlGHik7wy0ujkzP N0vqTGJ2nah5U0WYnn+79fj6UJHY7fDf4FEcRSJsh6OgLWfMHtUPRf/xgKl6S/qE 809d2ghnSRle7boFNWWJ =ube7 -----END PGP SIGNATURE----- From emil@sip-communicator.org Wed Apr 3 16:02:17 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 5A4CB21F8FFC for ; Wed, 3 Apr 2013 16:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_18=0.6] 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 yYcMSScdGsqH for ; Wed, 3 Apr 2013 16:02:16 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E320421F8FF3 for ; Wed, 3 Apr 2013 16:02:15 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so1544851wey.33 for ; Wed, 03 Apr 2013 16:02:15 -0700 (PDT) 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=5clXyt11gv2l6wYC/Ccp0HV7HqgGqGUtwSTNzgK+Tgs=; b=borzILXUVc5VmXIHlxJ5vR7QO2CBbEqEXNHPuSuzSYw52X3kimjMFEFG341/NGxigK 4/3LPmqneV/vqc7NJ6kfgppkC7+vMGmL0IEIVwSJFa5qKnMMznqyjVTnbEDGOD+kZTei 9OsrE8joYzU56GgMVazHJlYDZY7TWACazb++s6l/v7rt85VrigUwOh06425lEIKl9atn esR/BpkJhJKKvItA196zJ87K8CXCNTxlCnTizlOMOILF/MTeiKVXccFWslVr2/2IASaG hVLnDnY/x3eDpqC2xH+mLhh8E8eXEnjGGbDjTtaPFaB6DGYBUOKXUstu6oVoAfsioRwo Bv3A== X-Received: by 10.194.60.195 with SMTP id j3mr5622538wjr.33.1365030134956; Wed, 03 Apr 2013 16:02:14 -0700 (PDT) Received: from vpn-rp-2.u-strasbg.fr (vpn-rp-2.u-strasbg.fr. [130.79.91.49]) by mx.google.com with ESMTPS id fv2sm12282784wib.6.2013.04.03.16.02.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 16:02:13 -0700 (PDT) Message-ID: <515CB4F2.3010404@jitsi.org> Date: Thu, 04 Apr 2013 01:02:10 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <515AFCFE.7030608@acm.org> In-Reply-To: <515AFCFE.7030608@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmz5eWRN8IAm+ktcFJ0xGDhR7x5UntkPF/Id5nAX5wOTUl9SOIP7RyqKu1i0K8KY4cmhCGb Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Wed, 03 Apr 2013 23:02:17 -0000 Hey Marc and thanks for your comments! Replies inline. On 02.04.13, 17:45, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I read draft-ivov-dispatch-trickle-ice-sip and draft-ivov-mmusic-trickle-ice > during the preparation of the rfc5245bis draft and I have some suggestions > that I will be presenting step by step below: > > 1. The 180 needs to be reliable Agreed. We'll make the change in the next revision. > 2. Use UPDATE instead of INFO Why? > UPDATE works as well as INFO, and is more SIPish. Well, I'd argue that there are more implementations out there making some use of INFO than supporting UPDATE so I am not sure I agree with this statement ;) Seriously now. There are several reasons we did not go for UPDATE: 1. Trickle ICE is not a new mechanism. It has been out there with XMPP for almost 8 years and it is now also part of WebRTC. SIP is the late arriver here and SIP implementations of trickle ICE are more likely to have to adapt to existing working systems than the other way around. We therefore believed that it would be a good think to preserve as much as possible the way that trickle ICE has been implemented with these other protocols. 2. We do not need to use offer answer. The exchange of trickled candidates has nothing to do with offer/answer. It is simply communication between ICE agents, pretty much the way connectivity checks are. Trickled candidates are actually quite similar to peer-reflexive candidates in that they are learned outside of the offer-answer exchange. So, in other words, there is no reason whatsoever that would really require use of offer/answer. There are however many reasons not to: 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob answers. Both do full trickle. One O/A exchange has completed so now either of them can re-Offer. Obviously, if both are trickling, there's a pretty good chance for glare to occur. Also, after Bob sends a re-offer with trickled candidates, and then immediately learns of new candidates, it will not be able to immediately send them because it needs to first obtain an answer from Alice. Alice on the other hand may have nothing to say at the moment, but she may be giving it some thought (i.e. waiting for some checks to complete). 4. Constantly updating the state of the offer answer machine. Oh my ... I get goose bumps only thinking about it. Every time new candidates are sent, new offers and answers will be exchanged. Clients would need to make sure that their view of the O/A state is properly updated and not only that but we would also need to make sure that: 5. All media aware intermediaries will also have to track the deluge of offers and answers and update their own states. It should be perfectly fine for such intermediaries to see the first offer and then the updated ICE offer. And that's that. 6. ... And all this diffing. To me difs, are one of the worst parts of the O/A model. Analysing thousands of bytes just to find that the only difference is an added a=sendonly attribute ... how did this ever happen (in comparison XMPP only sends ). Adding the same thing for trickle would make for extremely complicated code. You'd have to be prepared to update ICE state, remap your streams, add new ones, change codecs, and basically redo your entire session while trickling. Toe me it sounds like of of this is not even possible. Why would we lock ourselves into something like this? Pretty much everyone in RAI agrees that SDP and O/A is something we are just stuck with and that it would be great if we weren't. Well in this case we aren't. So why would we do it? Unless we overlooked some substantial issue with INFO and that issue is resolved by use of O/A and UPDATE, then I think it would really be best for everyone not to go there :) Cheers, Emil > > Here's the call flow: > > STUN/Turn STUN/TURN > Servers Alice Bob Servers > | | | | > |<--------------| | | > | Candidate | | | > | Discovery | | | > (1) |-------------->| INVITE (Offer) | | > | |------------------------>| | > (2) | | 183 (Answer) |-------------->| > | |<------------------------| | > | | PRACK | | > | |------------------------>| | > | | 200 PRACK | | > | |<------------------------| | > | | | | > (3) | | UPDATE (more cands) | Candidate | > | |<------------------------| | > (4) | | 200 UPDATE | | > | |------------------------>| Discovery | > | | Connectivity Checks | | > | |<=======================>| | > (5) | | UPDATE (last cands) |<--------------| > | |<------------------------| | > (6) | | 200 UPDATE | | > | |------------------------>| | > | | 180 | | > | |<------------------------| | > | | Connectivity Checks | | > | |<=======================>| | > | | | | > | | 200 INVITE | | > | |<------------------------| | > | | | | > | | 5245 SIP re-INVITE | | > | |------------------------>| | > | | 200 reINVITE | | > | |<------------------------| | > | | | | > | | | | > | |<===== MEDIA FLOWS =====>| | > | | | | > > > 3. Use accumulated candidate list > > As far as I understand the documents, the candidates are sent as soon as they > are discovered. I think that it would be better to send an accumulated list > of candidates instead of the delta list of candidates. The priority > calculation and the elimination of redundant candidates do not need to know > the complete list of candidate to work, but sending the accumulated list > instead of a delta could permit in the future to remove candidates, if we find > a need to do so. This also removed the need for sdpfrag. > > But the most important reason is for the next step. > > > 4. Replace end-of-candidates attribute by precandidate attributes > > There is currently an end-of-candidates attribute that is sent to signal the > end of the candidate gathering phase. I think it is better to do it the > opposite way, i.e. to send candidates as they are discovered under a different > attribute name, and then to send all the candidates only when the gathering > phase is done. Here's the partial SDPs exchanged in the call flow in 2) but > skipping one update (examples are from RFC 5245): > > (1) Alice sends all the candidates after the end of the gathering phase > (half-trickle). She also signals that she supports trickle. > > a=ice-options:trickle > a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host > > (2) Bob knows that Alice supports half trickle, so he sends only the host > candidates, which is all he has so far, but using the attribute precandidate > instead of candidate. He sends them in a reliable 183: > > a=ice-options:trickle > a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > If Bob supported ICE but not trickle, he would have answered with its complete > list of candidates. > > (3) Bob discovers some candidates, but there is more to come, so it sends a > accumulated list of precandidates: > > a=ice-options:trickle > a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 > rport 8998 > a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > (4) Alice responds with the same SDP than in (1) > > (5) Bob receives the last batch of candidates, so now it sends an SDP > containing the all the candidates, as if it did not understand trickle.: > > a=ice-options:trickle > a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport > 8998 > a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > (6) Alice sends back the same SDP. Because Bob use candidate attributes > instead of precandidate, she knows that she has all the candidates, as if > end-of-candidates was received. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO > J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH > MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli > 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh > uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 > snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r > mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm > eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR > FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr > Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ > GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb > yk3C5OOf2RWXhf6ekDuf > =jzXd > -----END PGP SIGNATURE----- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From juberti@google.com Wed Apr 3 17:05: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 6C69C21F91BF for ; Wed, 3 Apr 2013 17:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.176 X-Spam-Level: X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, 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 sddy4TuV35+q for ; Wed, 3 Apr 2013 17:05:56 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA6121F91B8 for ; Wed, 3 Apr 2013 17:05:56 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bv4so1159427qab.2 for ; Wed, 03 Apr 2013 17:05:55 -0700 (PDT) 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=JbQZPfOf23+JAX4M00Jkzb/tWsJPvuUOcAn2sKXt8Zg=; b=PNdvxgjV20QJuNz3is9pWivsIKSmxZXDrhduHY+ay40coGl14t4F06GJ0PMJRe13Le CPcQ5WdIxaUUaoGjee98tJA7FO2xAtzNqwjYNmL35dH8SMaW414cl9avdG7zKB5w86T3 V25RHufoMwOlDcydYnd+NF49nz8Dv4iPJjP7LOEa9P2OEQAQioQUJ3lsVpcV/NAYaZaV sJ5vGapKqulU2J5sUOqwRFhWxo20MaCmrJtoKC/+u8Madd9HPcsHrAxe/7Neb/NJNHEX 3XfgtX4690lskaZCxm/dRPbjbJUzx/c9cET+ffNGGtFV0qptv3KiQG1g2/jqsJ2wgRh5 2HDg== 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=JbQZPfOf23+JAX4M00Jkzb/tWsJPvuUOcAn2sKXt8Zg=; b=hLBF687Ihgc+RVMeLFYaLZ03ChUgAjgRGPZMYL5WZJF119g+AV5LvZb7gLrZH4l8Pb /gxTlW519flwSZ0kMpne7tlbZj4hZ6UMfe7p2OmdCsh3EIq9lnlXsagzO3ahlDARyNIJ /RVHyS2g4gyn7iQ8GyTko6xAJq4PI0JsmgKhqk7+Od6ZjOXSTOu4+IIdvSH+DVCyUuQV ZDP5JeSPoFbSvawFMnZUauGPt6hj4bkLacvsFtHPA5hupzvk7TMrYKAQjk7fGj1ZXeoN X4XCHSvsSf1tCQcc7tapufSe+iclBZY0+VnGoVEo/rB8XdZxHEIOGvExyfFzKQQEiJ5Q GS/w== X-Received: by 10.49.15.198 with SMTP id z6mr3485426qec.6.1365033955603; Wed, 03 Apr 2013 17:05:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.75.70 with HTTP; Wed, 3 Apr 2013 17:05:34 -0700 (PDT) In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com> From: Justin Uberti Date: Wed, 3 Apr 2013 17:05:34 -0700 Message-ID: To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=047d7bd6ae8007d8bd04d97dbcbe X-Gm-Message-State: ALoCoQm9ExO4BWkFXIbcjyQYIhYxydHiViRhMSBpBAJQKWzEn9x1qnhJfq+AdiXr3TCP5e1nJC2zQA+X50wjrcSvr+kBtSdH8POiw1JaA9DXD2RgejjRPrCS6QQDrBWvsV/RsjyhDpn6an21FIy94nmEbg9ey0zQ/dE8Kf1TMhT5WyU8rUgqKfksWYqSfKLZCzZpKRVDTwc9 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 04 Apr 2013 00:05:57 -0000 --047d7bd6ae8007d8bd04d97dbcbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Hi Justin,**** > > I have comments on items 4 and 10 in your original list.**** > > ** ** > > 4: In 6.1, list 1, if the answerer chooses to bundle and selects the > 5-tuple from the first m line for the group, then it must also assume the > use of the c=3D, rtcp-mux and a=3Dfingerprint (all transport related > attributes) from that m line for the group. Then according to the rules, > the 2nd offer must then include the same value for c=3D, rtcp-mux and > a=3Dfingerprint for all m lines in the group. > Agreed. > If you relax conditions 2, 5 and 7 for the 1st offer, it would seem a > little strange and would require extra work to clean up all the m lines i= n > the 2nd offer if the 1st offer had different values for c=3D, rtcp-mux an= d > a=3Dfingerprint in all the m lines of the group. As I see it, it=E2=80= =99s easier to > have this rule from the beginning unless there are some use cases where y= ou > might want different values for c=3D, rtcp-mux and a=3Dfingerprint if bun= dle > cannot be negotiated. Do you (or anyone else) see any reason to have thi= s > capability? It probably isn=E2=80=99t that important a rule (except for > convenience) since any middlebox will get straightened out with the 2ndof= fer and any peer agreeing to bundle knows to ignore the transport related > information from the other lines (except as discussed below). > We already need to deal with this for a=3Dcandidate, a=3Dcrypto and a=3Dice-ufrag/pwd, so I don't see why having to also do this for these othe= r attributes makes things any harder. It's not super important, but it seems odd to prohibit things that would seem to be mostly unrelated to BUNDLE. > **** > > ** ** > > 10: I think we have to have the ability to unbundle within a > PeerConnection. For the error case described (twice) at the mike in > Orlando, if the first answer comes back asking to bundle but signaling > different ports, it is because of an intermediary forwarding bundle > attributes without understanding them while remapping ports. There seeme= d > to be agreement in this case (or at least the opinion was expressed) that > the offerer needs to detect this condition and send a 2nd offer with > different ports and without bundle (else the answerer will continue to > assume bundle while the intermediary will not). Note that this case > appears (to the answerer) as if bundle is successfully negotiated but the= n > it is immediately removed with the 2nd offer. > **** > > ** u** > > I think we also have the 3pcc use case where a mid-call bundled offer goe= s > to a different endpoint that chooses not to bundle. As long as it remove= s > the bundle attributes and returns different ports, why should we disallow > this? It only requires an ICE restart. This will even work with most > (new) intermediaries except those that choke on seeing the same port in > multiple m lines. Which brings me to why I think we also need to be able > to indicate via the API whether a mid-call offer is to be signaled with t= he > same or different ports for a bundle group (as I also requested at the > mike). > I think this is harder than you say. It's more than an ICE restart, it also requires re-keying of SRTP (since we now need unique crypto per m-line) and dealing with the sort-of-BUNDLEd case where we need to be able to receive BUNDLEd and non-BUNDLEd media potentially simultaneously during the transition. I'd really like to avoid having to deal with this. > **** > > ** ** > > Richard**** > > ** ** > > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Friday, March 15, 2013 3:51 PM > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] 10 BUNDLE questions**** > > ** ** > > The list below is a set of questions (some marked as OPEN ISSUE already) > regarding the new BUNDLE proposal. If you agree with my suggested answers= , > I'm willing to contribute text accordingly.**** > > 1. Can you create a BUNDLE with a single m=3D line? (assuming yes)**** > 2. Can you create multiple BUNDLEs? (assuming yes)**** > 3. When creating an initial offer, how should we deal with the case > where a "null" port is to be used with trickle ICE (since 6.1:1 indica= tes > the ports MUST be different) **** > 4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST > use same c=3D, add rtcp-mux, same a=3Dfingerprint)**** > 5. From 6.1, list 2 - is condition 6 right? Why would we use different > SDES keys for a single RTP session?**** > 6. If you start with a m=3D line with one SDES config (e.g. 32-bit MAC= ), > and then BUNDLE with another SDES line with a different (non overlappi= ng) > SDES config (e.g. 80-bit MAC), what happens? (assume fail)**** > 7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in > the offer, what happens? (assume fail)**** > 8. If you add a m=3D line to an existing BUNDLE, can the recipient > reject that BUNDLEing (assume no)**** > 9. If m=3D lines are rejected, should their mids show up in the BUNDLE > answer? (assume yes?)**** > > > 1. If not, how does remote side indicate BUNDLE support if it rejects > the m=3D lines that are BUNDLEd?**** > > > 1. Is there any way, in a single PeerConnection, to unBUNDLE m=3D line= s > that were previously BUNDLEd (assume no)**** > > --047d7bd6ae8007d8bd04d97dbcbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrote:

Hi Justin,<= /span>

I have comments on items = 4 and 10 in your original list.

=C2=A0

4: In 6.1, list 1, if the= answerer chooses to bundle and selects the 5-tuple from the first m line f= or the group, then it must also assume the use of the c=3D, rtcp-mux and a=3Dfingerprint (all transport related attributes) from that = m line for the group.=C2=A0 Then according to the rules, the 2nd= offer must then include the same value for c=3D, rtcp-mux and a=3Dfingerpr= int for all m lines in the group.=C2=A0


Agreed.=C2=A0

If you relax conditions 2, 5 and 7 for the 1st offer, it would seem a little= strange and would require extra work to clean up all the m lines in the 2<= sup>nd offer if the 1st offer had different values for c= =3D, rtcp-mux and a=3Dfingerprint in all the m lines of the group.=C2=A0 As I see it, it=E2=80=99s easier to have t= his rule from the beginning unless there are some use cases where you might= want different values for c=3D, rtcp-mux and a=3Dfingerprint if bundle can= not be negotiated.=C2=A0 Do you (or anyone else) see any reason to have this capability? =C2=A0It probably isn=E2=80=99t that impor= tant a rule (except for convenience) since any middlebox will get straighte= ned out with the 2nd offer and any peer agreeing to bundle knows= to ignore the transport related information from the other lines (except as discussed below).


We already need to deal with thi= s for a=3Dcandidate, a=3Dcrypto and a=3Dice-ufrag/pwd, so I don't see w= hy having to also do this for these other attributes makes things any harde= r. It's not super important, but it seems odd to prohibit things that w= ould seem to be mostly unrelated to BUNDLE.

=C2=A0

10: I think we have to ha= ve the ability to unbundle within a PeerConnection.=C2=A0 For the error cas= e described (twice) at the mike in Orlando, if the first answer comes back asking to bundle but signaling different ports, it is because o= f an intermediary forwarding bundle attributes without understanding them w= hile remapping ports.=C2=A0 There seemed to be agreement in this case (or a= t least the opinion was expressed) that the offerer needs to detect this condition and send a 2nd offer= with different ports and without bundle (else the answerer will continue t= o assume bundle while the intermediary will not). =C2=A0Note that this case= appears (to the answerer) as if bundle is successfully negotiated but then it is immediately removed with the 2nd offer.=C2=A0

=C2=A0u

I think we also have the = 3pcc use case where a mid-call bundled offer goes to a different endpoint t= hat chooses not to bundle.=C2=A0 As long as it removes the bundle attributes and returns different ports, why should we disallow this? =C2= =A0It only requires an ICE restart.=C2=A0 This will even work with most (ne= w) intermediaries except those that choke on seeing the same port in multip= le m lines.=C2=A0 Which brings me to why I think we also need to be able to indicate via the API whether a mid-call offer i= s to be signaled with the same or different ports for a bundle group (as I = also requested at the mike).


I think this is harder than you say. It's more than an= ICE restart, it also requires re-keying of SRTP (since we now need unique = crypto per m-line) and dealing with the sort-of-BUNDLEd case where we need = to be able to receive BUNDLEd and non-BUNDLEd media potentially simultaneou= sly during the transition. I'd really like to avoid having to deal with= this.

=C2=A0

Richard

=C2=A0

From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Friday, March 15, 2013 3:51 PM
To: mmusic@ietf= .org
Subject: [MMUSIC] 10 BUNDLE questions

=C2=A0

The list below is a set of questions (some marked as= OPEN ISSUE already) regarding the new BUNDLE proposal. If you agree with m= y suggested answers, I'm willing to contribute text accordingly.=

  1. Can you create a BUNDLE with a single m=3D line? (assuming yes)
  2. Can you create multiple BUNDLEs? (assuming yes)
  3. When creating an initial offer, how should we deal with the case where a &q= uot;null" port is to be used with trickle ICE (since 6.1:1 indicates t= he ports MUST be different)=C2=A0
  4. >From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same = c=3D, add rtcp-mux, same a=3Dfingerprint)
  5. >From 6.1, list 2 - is condition 6 right? Why would we use different SDES ke= ys for a single RTP session?
  6. If you start with a m=3D line with one SDES config (e.g. 32-bit MAC), and t= hen BUNDLE with another SDES line with a different (non overlapping) SDES c= onfig (e.g. 80-bit MAC), what happens? (assume fail)
  7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the o= ffer, what happens? (assume fail)
  8. If you add a m=3D line to an existing BUNDLE, can the recipient reject that= BUNDLEing (assume no)
  9. If m=3D lines are rejected, should their mids show up in the BUNDLE answer?= (assume yes?)
    1. If not, how does remote side indicate BUNDLE support if it rejects the m=3D= lines that are BUNDLEd?
  1. Is there any way, in a single PeerConnection, to unBUNDLE m=3D lines that w= ere previously BUNDLEd (assume no)

--047d7bd6ae8007d8bd04d97dbcbe-- From worley@shell01.TheWorld.com Wed Apr 3 19: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 515F121F93A9 for ; Wed, 3 Apr 2013 19:06:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZK+dIXHzvjk for ; Wed, 3 Apr 2013 19:06:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id C546821F93BC for ; Wed, 3 Apr 2013 19:06:02 -0700 (PDT) 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 r34258Fr026272 for ; Wed, 3 Apr 2013 22:05:10 -0400 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 r34257cB1896845 for ; Wed, 3 Apr 2013 21:05:07 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r34257ex1899016; Wed, 3 Apr 2013 22:05:07 -0400 (EDT) Date: Wed, 3 Apr 2013 22:05:07 -0400 (EDT) Message-Id: <201304040205.r34257ex1899016@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 04 Apr 2013 02:06:03 -0000 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.) Dale From magnus.westerlund@ericsson.com Wed Apr 3 23: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 E815521F95DF for ; Wed, 3 Apr 2013 23:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 eNItIuameAqP for ; Wed, 3 Apr 2013 23:52:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D2E3321F95DE for ; Wed, 3 Apr 2013 23:52:45 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-f8-515d233cf1bc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 72.EE.19728.C332D515; Thu, 4 Apr 2013 08:52:44 +0200 (CEST) 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, 4 Apr 2013 08:52:44 +0200 Message-ID: <515D2336.8010408@ericsson.com> Date: Thu, 4 Apr 2013 08:52:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Dale R. Worley" References: <51425974.9070608@ericsson.com> <201303151431.r2FEVHJ9498642@shell01.TheWorld.com> <514767D1.3000906@ericsson.com> <201303191937.r2JJbEWO763574@shell01.TheWorld.com> <514C80D8.2030802@ericsson.com> <201303281743.r2SHh5Qd1352244@shell01.TheWorld.com> In-Reply-To: <201303281743.r2SHh5Qd1352244@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra6NcmygwdV3qhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgypjzYwZbQbdgxfyXTxgbGHfzdjFyckgImEjc fLOCDcIWk7hwbz2QzcUhJHCKUWLzt3WsEM4yRolDN/azgFTxCmhL3O3/DGazCKhILFjbywxi swlYSNz80Qg2SVQgWOLnqzNQ9YISJ2c+AbI5OEQENCU6FuSAhJkFhCUunD/OBGILCzhJfFhy A2pxK5PE88VHwGZyCjhINNzZygJxnaTElhft7BDNehJTrrYwQtjyEs1bZ4PVCwHd1tDUwTqB UWgWktWzkLTMQtKygJF5FSN7bmJmTnq50SZGYKge3PJbdQfjnXMihxilOViUxHnDXS8ECAmk J5akZqemFqQWxReV5qQWH2Jk4uCUamB0/9BrkVC2wUWmNOpu8cXF2mdcmB4t+bj1/P1Sv9ag z/lXXK5wVvGxSrEsymfwOWJwwMKVMX367w0qTzj/31rif3u1L9/1FusZlT5+hdlhGad3ax4y SBE7Nr9v3sce3Tl+Io+rtXbkHfBNZn9oc+N86BMv07ouSfZZdr2r1xWeTJ6pIWl59a4SS3FG oqEWc1FxIgADeu1YIwIAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP 2.0 SDP issue: Directionality 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, 04 Apr 2013 06:52:47 -0000 Dale, I think your wording are more neutral to the diverse interpretation of SDP in O/A, thus I will push out a new version with your change. Thanks Magnus On 2013-03-28 18:43, Dale R. Worley wrote: >> Date: Fri, 22 Mar 2013 17:03:36 +0100 >> From: Magnus Westerlund >> >> Thanks for the input. I have tried to address your input in this version: >> >> This appendix describes how an SDP file determines the operation of >> an RTSP session. Thus, it is worth pointing out that the >> interpretation of the SDP is done in the context of the SDP receiver, >> which is the one being configured. This is the same as in SAP >> [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where the SDP >> describes what the agent providing the SDP is ready to receive and >> willing to send. > > Sorry, I've dropped the ball on this. Looking at this text, I'm > thinking that the "reversal" between SAP and offer/answer usage is not > stated as clearly as it could be. How about copying the wording from > the second sentence into the third? > > This appendix describes how an SDP file determines the operation of > an RTSP session. Thus, it is worth pointing out that the > interpretation of the SDP is done in the context of the SDP receiver, > which is the one being configured. This is the same as in SAP > [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each > SDP is interpreted in the context of the agent providing it. > > Dale > _______________________________________________ > 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 internet-drafts@ietf.org Thu Apr 4 00:07: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 A787921F9607; Thu, 4 Apr 2013 00:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 1CmPzcgWZu8C; Thu, 4 Apr 2013 00:07:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0521F95FD; Thu, 4 Apr 2013 00:07:15 -0700 (PDT) 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.43 Message-ID: <20130404070645.30547.34447.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 00:06:45 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-34.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, 04 Apr 2013 07:07:17 -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-34.txt Pages : 302 Date : 2013-04-04 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-34 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-34 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu Apr 4 06:50: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 9591A21F8D52 for ; Thu, 4 Apr 2013 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, RDNS_NONE=0.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 rcVy4q--hiit for ; Thu, 4 Apr 2013 06:50:54 -0700 (PDT) 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 D1C7721F8D10 for ; Thu, 4 Apr 2013 06:50:53 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id KmDw1l00C0SCNGk53pqthE; Thu, 04 Apr 2013 13:50:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id Kpqs1l00o3ZTu2S3VpqsSt; Thu, 04 Apr 2013 13:50:52 +0000 Message-ID: <515D853C.6020107@alum.mit.edu> Date: Thu, 04 Apr 2013 21:50:52 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> In-Reply-To: <515CB4F2.3010404@jitsi.org> 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=1365083453; bh=vTZavs+7JebqHQ17Mf0BNKOjx/RuWzi0au09WD4whYc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kZ5UjHC9h2zqZBk68T0Lu678A+OgPR2McOx/3tHXM7Jz6BoUqDBZDoAM1qznEVtfR IBhpaNUDND+yPtocxWgO1w5GLwH2B/+N1J138v0FyOI7cq2EWtOe75c1sm60Cpa5GJ m2vHXAzthmnW4EUthni6AY6qAH07Q8PXwKu2pIGIKJIC/f+QDmsjFeFFuWzuwlleKV 2ncI6QrDA4IBlJVQK9z8CHZyCFXy3x+xqS3i3vQZdWDsd8w6L7YsVRkgaozT8hna1S kqeg/pDbJVWI4sycgYoWXCrsUjpZhg2rtCvtD3oCPY0VTSQPlZwtTYIxZ6ONxtX5Ix f/HviHU2ybktg== Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Thu, 04 Apr 2013 13:51:00 -0000 Emil, I appreciate some of what you say. But I also think you sweep some things under the rug. See inline. On 4/4/13 7:02 AM, Emil Ivov wrote: > Hey Marc and thanks for your comments! > > Replies inline. > > On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I read draft-ivov-dispatch-trickle-ice-sip and draft-ivov-mmusic-trickle-ice >> during the preparation of the rfc5245bis draft and I have some suggestions >> that I will be presenting step by step below: >> >> 1. The 180 needs to be reliable > > Agreed. We'll make the change in the next revision. > >> 2. Use UPDATE instead of INFO > > Why? > >> UPDATE works as well as INFO, and is more SIPish. > > Well, I'd argue that there are more implementations out there making > some use of INFO than supporting UPDATE so I am not sure I agree with > this statement ;) Do you mean more implementations of *trickle ICE* using INFO than UPDATE? Or do you mean that in general there are more implementations of SIP supporting and using INFO than supporting and using UPDATE? I don't have real data, but I have the impression that for a long time most sip implementations have supported UPDATE. > Seriously now. There are several reasons we did not go for UPDATE: > > 1. Trickle ICE is not a new mechanism. It has been out there with XMPP > for almost 8 years and it is now also part of WebRTC. SIP is the late > arriver here and SIP implementations of trickle ICE are more likely to > have to adapt to existing working systems than the other way around. We > therefore believed that it would be a good think to preserve as much as > possible the way that trickle ICE has been implemented with these other > protocols. ISTM that there is likely to be a lot of sip-sip use, perhaps more than any other kind, perhaps not. If so, that would argue for something that most naturally integrates into existing sip signaling. > 2. We do not need to use offer answer. The exchange of trickled > candidates has nothing to do with offer/answer. It is simply > communication between ICE agents, pretty much the way connectivity > checks are. Trickled candidates are actually quite similar to > peer-reflexive candidates in that they are learned outside of the > offer-answer exchange. So, in other words, there is no reason whatsoever > that would really require use of offer/answer. There are however many > reasons not to: Of course it has something to do with O/A. ICE is also exchanged in O/A. And the candidates you need to exchange are coupled to what was exchanged in O/A. Suppose you do one O/A exchange including ICE candidates, and then one or both sides starts to trickle candidates with INFO. Then one side sends a new offer, that changes the m-lines in some way. Presumably it will also contain some ICE candidates. And then the other side sends another trickle ICE INFO. How do all of these things relate? Is this even legal? Certainly you can set down a set of protocol rules so that it becomes well defined. But you are going to need to take the SIP O/A rules into account while doing that. > 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob answers. > Both do full trickle. One O/A exchange has completed so now either of > them can re-Offer. Obviously, if both are trickling, there's a pretty > good chance for glare to occur. Also, after Bob sends a re-offer with > trickled candidates, and then immediately learns of new candidates, it > will not be able to immediately send them because it needs to first > obtain an answer from Alice. Alice on the other hand may have nothing to > say at the moment, but she may be giving it some thought (i.e. waiting > for some checks to complete). You assume that a subsequent offer is used *only* to update trickle ICE. There are other reasons for a new offer. Or are you assuming some constraints such as that first you do an O/A, and then agree not to do another one until all trickling for the first one has been completed? > 4. Constantly updating the state of the offer answer machine. Oh my ... > I get goose bumps only thinking about it. Every time new candidates are > sent, new offers and answers will be exchanged. Clients would need to > make sure that their view of the O/A state is properly updated and not > only that but we would also need to make sure that: > > 5. All media aware intermediaries will also have to track the deluge of > offers and answers and update their own states. It should be perfectly > fine for such intermediaries to see the first offer and then the updated > ICE offer. And that's that. That doesn't work so well for those intermediaries that gate media, and so won't let anything through (including ICE) until they have seen the address in signaling and opened the gate for it. > 6. ... And all this diffing. To me difs, are one of the worst parts of > the O/A model. Analysing thousands of bytes just to find that the only > difference is an added a=sendonly attribute ... how did this ever happen > (in comparison XMPP only sends ). It is called idempotence. This presumes that you implement this by first finding the difference and then applying it to your current state, rather than just setting out to apply the entire new specification to your current state. There are pros/cons to both ways, and its not surprising that people are most comfortable with the one most familiar to them. > Adding the same thing for > trickle would make for extremely complicated code. You'd have to be > prepared to update ICE state, remap your streams, add new ones, change > codecs, and basically redo your entire session while trickling. Toe me > it sounds like of of this is not even possible. Why would we lock > ourselves into something like this? So what do you propose to happen if it *does* prove necessary to do a new O/A after trickling has begun? Are you going to put the all the trickled candidates into the offer? If not, are you going to require that the candidates be identical to what was in the prior offer? ISTM you must confront this in any case. Thanks, Paul > Pretty much everyone in RAI agrees that SDP and O/A is something we are > just stuck with and that it would be great if we weren't. Well in this > case we aren't. So why would we do it? Unless we overlooked some > substantial issue with INFO and that issue is resolved by use of O/A and > UPDATE, then I think it would really be best for everyone not to go there :) > > Cheers, > Emil > >> >> Here's the call flow: >> >> STUN/Turn STUN/TURN >> Servers Alice Bob Servers >> | | | | >> |<--------------| | | >> | Candidate | | | >> | Discovery | | | >> (1) |-------------->| INVITE (Offer) | | >> | |------------------------>| | >> (2) | | 183 (Answer) |-------------->| >> | |<------------------------| | >> | | PRACK | | >> | |------------------------>| | >> | | 200 PRACK | | >> | |<------------------------| | >> | | | | >> (3) | | UPDATE (more cands) | Candidate | >> | |<------------------------| | >> (4) | | 200 UPDATE | | >> | |------------------------>| Discovery | >> | | Connectivity Checks | | >> | |<=======================>| | >> (5) | | UPDATE (last cands) |<--------------| >> | |<------------------------| | >> (6) | | 200 UPDATE | | >> | |------------------------>| | >> | | 180 | | >> | |<------------------------| | >> | | Connectivity Checks | | >> | |<=======================>| | >> | | | | >> | | 200 INVITE | | >> | |<------------------------| | >> | | | | >> | | 5245 SIP re-INVITE | | >> | |------------------------>| | >> | | 200 reINVITE | | >> | |<------------------------| | >> | | | | >> | | | | >> | |<===== MEDIA FLOWS =====>| | >> | | | | >> >> >> 3. Use accumulated candidate list >> >> As far as I understand the documents, the candidates are sent as soon as they >> are discovered. I think that it would be better to send an accumulated list >> of candidates instead of the delta list of candidates. The priority >> calculation and the elimination of redundant candidates do not need to know >> the complete list of candidate to work, but sending the accumulated list >> instead of a delta could permit in the future to remove candidates, if we find >> a need to do so. This also removed the need for sdpfrag. >> >> But the most important reason is for the next step. >> >> >> 4. Replace end-of-candidates attribute by precandidate attributes >> >> There is currently an end-of-candidates attribute that is sent to signal the >> end of the candidate gathering phase. I think it is better to do it the >> opposite way, i.e. to send candidates as they are discovered under a different >> attribute name, and then to send all the candidates only when the gathering >> phase is done. Here's the partial SDPs exchanged in the call flow in 2) but >> skipping one update (examples are from RFC 5245): >> >> (1) Alice sends all the candidates after the end of the gathering phase >> (half-trickle). She also signals that she supports trickle. >> >> a=ice-options:trickle >> a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host >> >> (2) Bob knows that Alice supports half trickle, so he sends only the host >> candidates, which is all he has so far, but using the attribute precandidate >> instead of candidate. He sends them in a reliable 183: >> >> a=ice-options:trickle >> a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >> >> If Bob supported ICE but not trickle, he would have answered with its complete >> list of candidates. >> >> (3) Bob discovers some candidates, but there is more to come, so it sends a >> accumulated list of precandidates: >> >> a=ice-options:trickle >> a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 >> rport 8998 >> a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >> >> (4) Alice responds with the same SDP than in (1) >> >> (5) Bob receives the last batch of candidates, so now it sends an SDP >> containing the all the candidates, as if it did not understand trickle.: >> >> a=ice-options:trickle >> a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport >> 8998 >> a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >> >> (6) Alice sends back the same SDP. Because Bob use candidate attributes >> instead of precandidate, she knows that she has all the candidates, as if >> end-of-candidates was received. >> >> - -- >> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO >> J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH >> MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli >> 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh >> uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 >> snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r >> mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm >> eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR >> FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr >> Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ >> GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb >> yk3C5OOf2RWXhf6ekDuf >> =jzXd >> -----END PGP SIGNATURE----- >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From ietf-ipr@ietf.org Thu Apr 4 08:18: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 EABD021F8B64; Thu, 4 Apr 2013 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XtritvmUA8oU; Thu, 4 Apr 2013 08:18:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 884D121F84AF; Thu, 4 Apr 2013 08:18:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: schulzrinne@cs.columbia.edu, anrao@cisco.com, robla@robla.net, magnus.westerlund@ericsson.com, martin.stiemerling@neclab.eu X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130404151821.944.96423.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 08:18:21 -0700 Cc: ari.keranen@ericsson.com, mmusic@ietf.org, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ipr-announce@ietf.org Subject: [MMUSIC] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mmusic-rfc2326bis-31 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, 04 Apr 2013 15:18:22 -0000 Dear Dr. Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Ma= rtin Stiemerling: An IPR disclosure that pertains to your Internet-Draft entitled "Real Time Streaming Protocol 2.0 (RTSP)" (draft-ietf-mmusic-rfc2326bis) was submitted= to the IETF Secretariat on 2013-03-20 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2028/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- ietf-mmusic-rfc2326bis-31.""); The IETF Secretariat From petithug@acm.org Thu Apr 4 09:46: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 04F0D21F93DC for ; Thu, 4 Apr 2013 09:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001, 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 nGmo20TS3P+Q for ; Thu, 4 Apr 2013 09:46:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 92C3321F90D9 for ; Thu, 4 Apr 2013 09:46:43 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:3956:8dd9:a1c4:336] (unknown [IPv6:2601:9:4bc0:1f:3956:8dd9:a1c4:336]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B0F8C20453; Thu, 4 Apr 2013 18:46:42 +0200 (CEST) Message-ID: <515DAE70.7070106@acm.org> Date: Thu, 04 Apr 2013 09:46:40 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Emil Ivov References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> In-Reply-To: <515D853C.6020107@alum.mit.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Thu, 04 Apr 2013 16:46:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with everything Paul said, but I just would like to add one point below. On 04/04/2013 06:50 AM, Paul Kyzivat wrote: > Emil, > > I appreciate some of what you say. But I also think you sweep some things > under the rug. See inline. > > On 4/4/13 7:02 AM, Emil Ivov wrote: >> Hey Marc and thanks for your comments! >> >> Replies inline. >> >> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: > I read draft-ivov-dispatch-trickle-ice-sip and > draft-ivov-mmusic-trickle-ice during the preparation of the rfc5245bis > draft and I have some suggestions that I will be presenting step by step > below: > > 1. The 180 needs to be reliable >>> >>> Agreed. We'll make the change in the next revision. >>> > 2. Use UPDATE instead of INFO >>> >>> Why? >>> > UPDATE works as well as INFO, and is more SIPish. >>> >>> Well, I'd argue that there are more implementations out there making >>> some use of INFO than supporting UPDATE so I am not sure I agree with >>> this statement ;) > >> Do you mean more implementations of *trickle ICE* using INFO than UPDATE? >> Or do you mean that in general there are more implementations of SIP >> supporting and using INFO than supporting and using UPDATE? > >> I don't have real data, but I have the impression that for a long time >> most sip implementations have supported UPDATE. > >>> Seriously now. There are several reasons we did not go for UPDATE: >>> >>> 1. Trickle ICE is not a new mechanism. It has been out there with XMPP >>> for almost 8 years and it is now also part of WebRTC. SIP is the late >>> arriver here and SIP implementations of trickle ICE are more likely to >>> have to adapt to existing working systems than the other way around. >>> We therefore believed that it would be a good think to preserve as much >>> as possible the way that trickle ICE has been implemented with these >>> other protocols. It is not the trickle mechanism that my original email tried to fix, but the mapping between this mechanism and SIP which, as you said yourself, is new so there is nothing to preserve here. > >> ISTM that there is likely to be a lot of sip-sip use, perhaps more than >> any other kind, perhaps not. If so, that would argue for something that >> most naturally integrates into existing sip signaling. > >>> 2. We do not need to use offer answer. The exchange of trickled >>> candidates has nothing to do with offer/answer. It is simply >>> communication between ICE agents, pretty much the way connectivity >>> checks are. Trickled candidates are actually quite similar to >>> peer-reflexive candidates in that they are learned outside of the >>> offer-answer exchange. So, in other words, there is no reason >>> whatsoever that would really require use of offer/answer. There are >>> however many reasons not to: > >> Of course it has something to do with O/A. ICE is also exchanged in O/A. >> And the candidates you need to exchange are coupled to what was exchanged >> in O/A. > >> Suppose you do one O/A exchange including ICE candidates, and then one or >> both sides starts to trickle candidates with INFO. Then one side sends a >> new offer, that changes the m-lines in some way. Presumably it will also >> contain some ICE candidates. And then the other side sends another >> trickle ICE INFO. How do all of these things relate? Is this even legal? > >> Certainly you can set down a set of protocol rules so that it becomes >> well defined. But you are going to need to take the SIP O/A rules into >> account while doing that. > >>> 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob >>> answers. Both do full trickle. One O/A exchange has completed so now >>> either of them can re-Offer. Obviously, if both are trickling, there's >>> a pretty good chance for glare to occur. Also, after Bob sends a >>> re-offer with trickled candidates, and then immediately learns of new >>> candidates, it will not be able to immediately send them because it >>> needs to first obtain an answer from Alice. Alice on the other hand may >>> have nothing to say at the moment, but she may be giving it some >>> thought (i.e. waiting for some checks to complete). > >> You assume that a subsequent offer is used *only* to update trickle ICE. >> There are other reasons for a new offer. > >> Or are you assuming some constraints such as that first you do an O/A, >> and then agree not to do another one until all trickling for the first >> one has been completed? > >>> 4. Constantly updating the state of the offer answer machine. Oh my >>> ... I get goose bumps only thinking about it. Every time new candidates >>> are sent, new offers and answers will be exchanged. Clients would need >>> to make sure that their view of the O/A state is properly updated and >>> not only that but we would also need to make sure that: >>> >>> 5. All media aware intermediaries will also have to track the deluge >>> of offers and answers and update their own states. It should be >>> perfectly fine for such intermediaries to see the first offer and then >>> the updated ICE offer. And that's that. > >> That doesn't work so well for those intermediaries that gate media, and >> so won't let anything through (including ICE) until they have seen the >> address in signaling and opened the gate for it. > >>> 6. ... And all this diffing. To me difs, are one of the worst parts of >>> the O/A model. Analysing thousands of bytes just to find that the only >>> difference is an added a=sendonly attribute ... how did this ever >>> happen (in comparison XMPP only sends ). > >> It is called idempotence. > >> This presumes that you implement this by first finding the difference and >> then applying it to your current state, rather than just setting out to >> apply the entire new specification to your current state. > >> There are pros/cons to both ways, and its not surprising that people are >> most comfortable with the one most familiar to them. > >>> Adding the same thing for trickle would make for extremely complicated >>> code. You'd have to be prepared to update ICE state, remap your >>> streams, add new ones, change codecs, and basically redo your entire >>> session while trickling. Toe me it sounds like of of this is not even >>> possible. Why would we lock ourselves into something like this? > >> So what do you propose to happen if it *does* prove necessary to do a new >> O/A after trickling has begun? Are you going to put the all the trickled >> candidates into the offer? If not, are you going to require that the >> candidates be identical to what was in the prior offer? > >> ISTM you must confront this in any case. > >> Thanks, Paul > >>> Pretty much everyone in RAI agrees that SDP and O/A is something we >>> are just stuck with and that it would be great if we weren't. Well in >>> this case we aren't. So why would we do it? Unless we overlooked some >>> substantial issue with INFO and that issue is resolved by use of O/A >>> and UPDATE, then I think it would really be best for everyone not to go >>> there :) >>> >>> Cheers, Emil >>> > > Here's the call flow: > > STUN/Turn STUN/TURN Servers > Alice Bob Servers | | > | | |<--------------| | > | | Candidate | | | | Discovery > | | | (1) |-------------->| > INVITE (Offer) | | | > |------------------------>| | (2) | | > 183 (Answer) |-------------->| | |<------------------------| > | | | PRACK | | | > |------------------------>| | | | > 200 PRACK | | | |<------------------------| > | | | | | (3) | > | UPDATE (more cands) | Candidate | | > |<------------------------| | (4) | | > 200 UPDATE | | | |------------------------>| > Discovery | | | Connectivity Checks | | | > |<=======================>| | (5) | | > UPDATE (last cands) |<--------------| | > |<------------------------| | (6) | | > 200 UPDATE | | | |------------------------>| > | | | 180 | | | > |<------------------------| | | | Connectivity > Checks | | | |<=======================>| > | | | | | | > | 200 INVITE | | | > |<------------------------| | | | > | | | | 5245 SIP re-INVITE | > | | |------------------------>| | | > | 200 reINVITE | | | > |<------------------------| | | | > | | | | | > | | |<===== MEDIA FLOWS =====>| | | > | | | > > > 3. Use accumulated candidate list > > As far as I understand the documents, the candidates are sent as soon as > they are discovered. I think that it would be better to send an > accumulated list of candidates instead of the delta list of candidates. > The priority calculation and the elimination of redundant candidates do not > need to know the complete list of candidate to work, but sending the > accumulated list instead of a delta could permit in the future to remove > candidates, if we find a need to do so. This also removed the need for > sdpfrag. > > But the most important reason is for the next step. > > > 4. Replace end-of-candidates attribute by precandidate attributes > > There is currently an end-of-candidates attribute that is sent to signal > the end of the candidate gathering phase. I think it is better to do it > the opposite way, i.e. to send candidates as they are discovered under a > different attribute name, and then to send all the candidates only when the > gathering phase is done. Here's the partial SDPs exchanged in the call > flow in 2) but skipping one update (examples are from RFC 5245): > > (1) Alice sends all the candidates after the end of the gathering phase > (half-trickle). She also signals that she supports trickle. > > a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ > host > > (2) Bob knows that Alice supports half trickle, so he sends only the host > candidates, which is all he has so far, but using the attribute > precandidate instead of candidate. He sends them in a reliable 183: > > a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ > host a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > If Bob supported ICE but not trickle, he would have answered with its > complete list of candidates. > > (3) Bob discovers some candidates, but there is more to come, so it sends > a accumulated list of precandidates: > > a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ > host a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr > 10.0.1.1 rport 8998 a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ > host > > (4) Alice responds with the same SDP than in (1) > > (5) Bob receives the last batch of candidates, so now it sends an SDP > containing the all the candidates, as if it did not understand trickle.: > > a=ice-options:trickle a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ > host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr > 10.0.1.1 rport 8998 a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host > > (6) Alice sends back the same SDP. Because Bob use candidate attributes > instead of precandidate, she knows that she has all the candidates, as if > end-of-candidates was received. > >>> _______________________________________________ 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 > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXa5lAAoJECnERZXWan7E710QAN3hWWnsPCQw8iCFPHl6HxZ+ Q48BfHNKKzHe3n0ApJxeRTm8w2M11nj4J6vC1OdAHpWDEElzeLJjMGExdnLBwxOy wHS3jDGgKA9DVw2kBox7IIHMpbOoW2UwCx0lwM3YkwL8q4xrb4F3FmTHA5gAGgks P/mXJdRR8DCP1oiWYQELb+QmnuvFgBYbcGBUBy8P+XfL7f04IPTe8Cre6DaXqmVP CfAToyeiQKo/WTa5rk7sKr2veqsSPmQ5ZnyyHxMy+K42mrC2CD43bNR+HjfvUa24 pzZWxGQdNHZymccs0IP/TdP0N2oA4fv+TEVPsGLjHyUdTuObP7PunZvCDWFxls+S 3OOnTBILlor1BCUR50LtWPeqhjylFywQLTDHVdiz62b9URdfeQPT8ANJSVsplCpf //ep2AbRZEbdRtbfUjpSBs5uTX2N7SjJ50PRX0tqDlZ6E33GVFjjh9R/PHFLUrlV BQxN3vuEnXZJzas3j747eaEqDBENYF4RfDjJf237VQ4lFBTQHkkkHA5h5wr+Fl9N JKMNyrlTctvEOfJ9A11SCfikySjUuE+ZxMz6Z58teQqqatGWwJpMOlfZdDDHMAUA YC0PB2dPT6XbsRs9mhkqovMpzLoL9mlVz7LbKI+8Y9mIfVHNquerJR6x7D5JGGBA gmxM38lPaf5NLOzqEeAv =I//c -----END PGP SIGNATURE----- From emil@sip-communicator.org Thu Apr 4 11:02: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 674FF21F962E for ; Thu, 4 Apr 2013 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, 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 Ax45QFkTjtLS for ; Thu, 4 Apr 2013 11:02:23 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5A02121F95EA for ; Thu, 4 Apr 2013 11:02:23 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so3105011wgh.9 for ; Thu, 04 Apr 2013 11:02:22 -0700 (PDT) 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=meuVdzE8VppXJLlP93PXzmOzhsv2VDcLSraWh1aAgsg=; b=n9rJBqwqXQ1BjJapYZz44VerD+Hf0I7Aj7fvPTd21kAjFzpAODNYKNwgeOTFNfD8oY HyHmnxiEyCre7AqTwuGsO6WocjN9jjtcjQl/BfJv3ZD5txRFH+ttJIs/wAQeQkZvyOmt MgrG97mj7S/hgqC/zs76BbO0et/QD/5FmxYUwF+inXlohtPsBmZGjC7AgJOGMw5iHZcy /rWRc9ldojJTdZQuhyweyYRg6m+V8vlxBj789/xXhKf5AQPWci3rvNRZHfnj+AsO20Ak 3eUnlElhuodhM59DUvFozQz+c8KGOkAhZe1Ksll57ryoNneC/O0nriUsXKc/a+9kswn2 YT+w== X-Received: by 10.194.92.65 with SMTP id ck1mr11247162wjb.54.1365098542364; Thu, 04 Apr 2013 11:02:22 -0700 (PDT) Received: from camionet.local (ip-15.net-81-220-185.rev.numericable.fr. [81.220.185.15]) by mx.google.com with ESMTPS id bq19sm17744170wib.7.2013.04.04.11.02.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 11:02:21 -0700 (PDT) Message-ID: <515DC02D.7050105@jitsi.org> Date: Thu, 04 Apr 2013 20:02:21 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> In-Reply-To: <515D853C.6020107@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnbgW6KUQt4aBuupABlUrN+VUkg5MQtyeiDNy8lAmqzP9HLmAX4oWFnGCPc63p4sY4pZeng Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Thu, 04 Apr 2013 18:02:25 -0000 Hey Paul, On 04.04.13, 15:50, Paul Kyzivat wrote: >>> UPDATE works as well as INFO, and is more SIPish. >> >> Well, I'd argue that there are more implementations out there making >> some use of INFO than supporting UPDATE so I am not sure I agree with >> this statement ;) > > Do you mean more implementations of *trickle ICE* using INFO than > UPDATE? Or do you mean that in general there are more implementations of > SIP supporting and using INFO than supporting and using UPDATE? > > I don't have real data, but I have the impression that for a long time > most sip implementations have supported UPDATE. That was mostly a joke about which of the two feels more "SIPish". I was referring to non-standard use of SIP INFO for things such as DTMF and how there's probably more implementations supporting that, than implementations that do UPDATE. >> Seriously now. There are several reasons we did not go for UPDATE: >> >> 1. Trickle ICE is not a new mechanism. It has been out there with XMPP >> for almost 8 years and it is now also part of WebRTC. SIP is the late >> arriver here and SIP implementations of trickle ICE are more likely to >> have to adapt to existing working systems than the other way around. We >> therefore believed that it would be a good think to preserve as much as >> possible the way that trickle ICE has been implemented with these other >> protocols. > > ISTM that there is likely to be a lot of sip-sip use, perhaps more than > any other kind, perhaps not. Well I don't know about this. I know of very few SIP deployments that even use ICE, let alone trickle ICE. As noted, the mechanism has existed forever and has not been considered for SIP. ISTM that the only reason we are even considering it now is because trickle is needed by RTCWEB and because we didn't want to standardize trickle in general without making sure we have a way to also make it work with SIP. > If so, that would argue for something that > most naturally integrates into existing sip signaling. I have nothing against natural integration as long as it doesn't just mean "doing things the natural level of complexity that we are used to getting with SIP, SDP and O/A". I'd like to point out no issues have been raised for the INFO approach. The UPDATE proposal is just an alternative way of doing the same thing, not a solution to a problem we are having. >> 2. We do not need to use offer answer. The exchange of trickled >> candidates has nothing to do with offer/answer. It is simply >> communication between ICE agents, pretty much the way connectivity >> checks are. Trickled candidates are actually quite similar to >> peer-reflexive candidates in that they are learned outside of the >> offer-answer exchange. So, in other words, there is no reason whatsoever >> that would really require use of offer/answer. There are however many >> reasons not to: > > Of course it has something to do with O/A. I insist that it doesn't. It has exactly the same relationship to O/A as peer-reflexive candidate discovery: it happens elsewhere and intermediaries are notified about it post factum. > ICE is also exchanged in O/A. > And the candidates you need to exchange are coupled to what was > exchanged in O/A. Yes of course, but that's not the point I am making. The O/A exchanged helped create agents and set their state. Now they have a life of their own: they do checks by themselves, they discover peer-reflexive candidates by themselves, and with trickle they can also discover other kinds of candidates. > Suppose you do one O/A exchange including ICE candidates, and then one > or both sides starts to trickle candidates with INFO. Then one side > sends a new offer, that changes the m-lines in some way. Presumably it > will also contain some ICE candidates. And then the other side sends > another trickle ICE INFO. How do all of these things relate? Is this > even legal? It sounds to me like this would simply be an ICE restart and that the second ICE INFO shouldn't happen (unless it is the result of a race condition but that can easily be detected and ignored). > Certainly you can set down a set of protocol rules so that it becomes > well defined. But you are going to need to take the SIP O/A rules into > account while doing that. Sure. I don't think we really need a set of new rules though. >> 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob answers. >> Both do full trickle. One O/A exchange has completed so now either of >> them can re-Offer. Obviously, if both are trickling, there's a pretty >> good chance for glare to occur. Also, after Bob sends a re-offer with >> trickled candidates, and then immediately learns of new candidates, it >> will not be able to immediately send them because it needs to first >> obtain an answer from Alice. Alice on the other hand may have nothing to >> say at the moment, but she may be giving it some thought (i.e. waiting >> for some checks to complete). > > You assume that a subsequent offer is used *only* to update trickle ICE. Not at all. What I am saying is that doing trickle with O/A would give you a ton of new offers and answers and handling those would be very problematic. > There are other reasons for a new offer. Of course, and when they are needed, those could just be ICE restarts. > Or are you assuming some constraints such as that first you do an O/A, > and then agree not to do another one until all trickling for the first > one has been completed? No, this is not what I was assuming. >> 4. Constantly updating the state of the offer answer machine. Oh my ... >> I get goose bumps only thinking about it. Every time new candidates are >> sent, new offers and answers will be exchanged. Clients would need to >> make sure that their view of the O/A state is properly updated and not >> only that but we would also need to make sure that: >> >> 5. All media aware intermediaries will also have to track the deluge of >> offers and answers and update their own states. It should be perfectly >> fine for such intermediaries to see the first offer and then the updated >> ICE offer. And that's that. > > That doesn't work so well for those intermediaries that gate media, and > so won't let anything through (including ICE) until they have seen the > address in signaling and opened the gate for it. There are a few cases here: 1. Intermediaries that gate media unconditionally would just put themselves in the c= line which would cause an ICE mismatch and that will be the end of it (with or without trickle). 2. Intermediaries that try to be intelligent and work with ICE, by adding relayed candidates or anything like this can be in one of the two following cases: a) they don't support trickle, in which case they should remove the a=ice-options:trickle token and cause a fallback to vanilla ICE. b) they know about trickle in which case they would look into INFO messages. I agree the above may need more discussion, but I simply don't think that doing consecutive O/As with UPDATEs would just work out of the box for any of the problematic situations. >> 6. ... And all this diffing. To me difs, are one of the worst parts of >> the O/A model. Analysing thousands of bytes just to find that the only >> difference is an added a=sendonly attribute ... how did this ever happen >> (in comparison XMPP only sends ). > > It is called idempotence. > > This presumes that you implement this by first finding the difference > and then applying it to your current state, rather than just setting out > to apply the entire new specification to your current state. Yup sure. The problem is that it exposes you to a number of situations that you probably wouldn't need to handle otherwise (not idempotence itself, but doing the diffing in O/A in general and trickle ICE in particular). For example, when implementing this I'd have to make sure I am prepared to take a candidate update offer that also places streams on hold, changes codec sets (which would also mean that I'd have to recalculate pacing timers for checks that are already in progress), adds new streams, disables existing ones, etc., etc. All this while my checks are already in progress. Yet, I would need to worry about none of these if I simply take trickle ICE for what it is: agent-to-agent communication that has no impact on the state of O/A. > There are pros/cons to both ways, and its not surprising that people are > most comfortable with the one most familiar to them. > >> Adding the same thing for >> trickle would make for extremely complicated code. You'd have to be >> prepared to update ICE state, remap your streams, add new ones, change >> codecs, and basically redo your entire session while trickling. Toe me >> it sounds like of of this is not even possible. Why would we lock >> ourselves into something like this? > > So what do you propose to happen if it *does* prove necessary to do a > new O/A after trickling has begun? An ICE restart. > Are you going to put the all the > trickled candidates into the offer? This is an implementation choice. If the agent is capable of reusing already obtained candidates, then they could certainly include them in the new offer and speed up the process. > If not, are you going to require > that the candidates be identical to what was in the prior offer? No, certainly not. Does this make sense? Cheers, Emil > > ISTM you must confront this in any case. > > Thanks, > Paul > >> Pretty much everyone in RAI agrees that SDP and O/A is something we are >> just stuck with and that it would be great if we weren't. Well in this >> case we aren't. So why would we do it? Unless we overlooked some >> substantial issue with INFO and that issue is resolved by use of O/A and >> UPDATE, then I think it would really be best for everyone not to go there :) >> >> Cheers, >> Emil >> >>> >>> Here's the call flow: >>> >>> STUN/Turn STUN/TURN >>> Servers Alice Bob Servers >>> | | | | >>> |<--------------| | | >>> | Candidate | | | >>> | Discovery | | | >>> (1) |-------------->| INVITE (Offer) | | >>> | |------------------------>| | >>> (2) | | 183 (Answer) |-------------->| >>> | |<------------------------| | >>> | | PRACK | | >>> | |------------------------>| | >>> | | 200 PRACK | | >>> | |<------------------------| | >>> | | | | >>> (3) | | UPDATE (more cands) | Candidate | >>> | |<------------------------| | >>> (4) | | 200 UPDATE | | >>> | |------------------------>| Discovery | >>> | | Connectivity Checks | | >>> | |<=======================>| | >>> (5) | | UPDATE (last cands) |<--------------| >>> | |<------------------------| | >>> (6) | | 200 UPDATE | | >>> | |------------------------>| | >>> | | 180 | | >>> | |<------------------------| | >>> | | Connectivity Checks | | >>> | |<=======================>| | >>> | | | | >>> | | 200 INVITE | | >>> | |<------------------------| | >>> | | | | >>> | | 5245 SIP re-INVITE | | >>> | |------------------------>| | >>> | | 200 reINVITE | | >>> | |<------------------------| | >>> | | | | >>> | | | | >>> | |<===== MEDIA FLOWS =====>| | >>> | | | | >>> >>> >>> 3. Use accumulated candidate list >>> >>> As far as I understand the documents, the candidates are sent as soon as they >>> are discovered. I think that it would be better to send an accumulated list >>> of candidates instead of the delta list of candidates. The priority >>> calculation and the elimination of redundant candidates do not need to know >>> the complete list of candidate to work, but sending the accumulated list >>> instead of a delta could permit in the future to remove candidates, if we find >>> a need to do so. This also removed the need for sdpfrag. >>> >>> But the most important reason is for the next step. >>> >>> >>> 4. Replace end-of-candidates attribute by precandidate attributes >>> >>> There is currently an end-of-candidates attribute that is sent to signal the >>> end of the candidate gathering phase. I think it is better to do it the >>> opposite way, i.e. to send candidates as they are discovered under a different >>> attribute name, and then to send all the candidates only when the gathering >>> phase is done. Here's the partial SDPs exchanged in the call flow in 2) but >>> skipping one update (examples are from RFC 5245): >>> >>> (1) Alice sends all the candidates after the end of the gathering phase >>> (half-trickle). She also signals that she supports trickle. >>> >>> a=ice-options:trickle >>> a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host >>> >>> (2) Bob knows that Alice supports half trickle, so he sends only the host >>> candidates, which is all he has so far, but using the attribute precandidate >>> instead of candidate. He sends them in a reliable 183: >>> >>> a=ice-options:trickle >>> a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>> a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>> >>> If Bob supported ICE but not trickle, he would have answered with its complete >>> list of candidates. >>> >>> (3) Bob discovers some candidates, but there is more to come, so it sends a >>> accumulated list of precandidates: >>> >>> a=ice-options:trickle >>> a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>> a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 >>> rport 8998 >>> a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>> >>> (4) Alice responds with the same SDP than in (1) >>> >>> (5) Bob receives the last batch of candidates, so now it sends an SDP >>> containing the all the candidates, as if it did not understand trickle.: >>> >>> a=ice-options:trickle >>> a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>> a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport >>> 8998 >>> a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>> >>> (6) Alice sends back the same SDP. Because Bob use candidate attributes >>> instead of precandidate, she knows that she has all the candidates, as if >>> end-of-candidates was received. >>> >>> - -- >>> Marc Petit-Huguenin >>> Email: marc@petit-huguenin.org >>> Blog: http://blog.marc.petit-huguenin.org >>> Profile: http://www.linkedin.com/in/petithug >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.12 (GNU/Linux) >>> >>> iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO >>> J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH >>> MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli >>> 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh >>> uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 >>> snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r >>> mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm >>> eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR >>> FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr >>> Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ >>> GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb >>> yk3C5OOf2RWXhf6ekDuf >>> =jzXd >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 emil@sip-communicator.org Thu Apr 4 11:05: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 7942E21F9452 for ; Thu, 4 Apr 2013 11:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=-2.867, BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_SORBS_DUL=0.877] 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 WCukav9tVjmw for ; Thu, 4 Apr 2013 11:05:20 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D41D921F942C for ; Thu, 4 Apr 2013 11:05:19 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn17so4991617wib.10 for ; Thu, 04 Apr 2013 11:05:18 -0700 (PDT) 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=1HYefznS+j7bk/ESoIvT1N0Cer6FwY5KRCw10VhEGKo=; b=mL5YbmnReD2yNWESF0WJN5n9PWXYlXxvg8y09rsN2MzW7MiZvvbYCtXBf1e/kIGfKD 2pqyfMmv/DiNoypl3ERIOLUPfNC75QFjNB5s9JUh+u980hAO9WG26kvDV11twbG2ZNpX UDMSvIJPqU/WcvYzm2m77ftKWiofsmv6ZvCDQJc16fwy4b/W2YkF/zSUBZgkvNYtyL9/ BWGyrSmeEUS+JEgK4PDEsLcS7dE81+02jEKag3b5t/IMyKDEqqDEwbmP+hylOyu4yKla hB/coyqHRFc2CjBfu55E/wdMMGASlurWi5mfqzYbTeUTSpfIg/tGlt9EiwYfujLoZsIS PzCw== X-Received: by 10.180.92.229 with SMTP id cp5mr30871948wib.20.1365098718573; Thu, 04 Apr 2013 11:05:18 -0700 (PDT) Received: from camionet.local (ip-15.net-81-220-185.rev.numericable.fr. [81.220.185.15]) by mx.google.com with ESMTPS id s2sm17773296wib.4.2013.04.04.11.05.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 11:05:17 -0700 (PDT) Message-ID: <515DC0DE.7010809@jitsi.org> Date: Thu, 04 Apr 2013 20:05:18 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DAE70.7070106@acm.org> In-Reply-To: <515DAE70.7070106@acm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlTPiaRt4RiUI/TMYQq8KS9l6kFwKxRrkwdu8CU2DM5m9L1EDw4UFHe0VyiZYWwx8h+WmOf Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Thu, 04 Apr 2013 18:05:21 -0000 Hey Marc, On 04.04.13, 18:46, Marc Petit-Huguenin wrote: >>>> 1. Trickle ICE is not a new mechanism. It has been out there with XMPP >>>> for almost 8 years and it is now also part of WebRTC. SIP is the late >>>> arriver here and SIP implementations of trickle ICE are more likely to >>>> have to adapt to existing working systems than the other way around. >>>> We therefore believed that it would be a good think to preserve as much >>>> as possible the way that trickle ICE has been implemented with these >>>> other protocols. > > It is not the trickle mechanism that my original email tried to fix, but the > mapping between this mechanism and SIP which, as you said yourself, is new so > there is nothing to preserve here. I get this. My point was that it would make sense to have it interoperate easily. Specifically, if I am translating WebRTC into SIP, I would just be getting individual a=candidate lines from WebRTC. It would be nice if I could just paste that candidate in a SIP message and send it through. It would be not so nice if I have to keep a state in the gateway so that I can regenerate the entire candidate list every time this happens. Emil >>> ISTM that there is likely to be a lot of sip-sip use, perhaps more than >>> any other kind, perhaps not. If so, that would argue for something that >>> most naturally integrates into existing sip signaling. >> >>>> 2. We do not need to use offer answer. The exchange of trickled >>>> candidates has nothing to do with offer/answer. It is simply >>>> communication between ICE agents, pretty much the way connectivity >>>> checks are. Trickled candidates are actually quite similar to >>>> peer-reflexive candidates in that they are learned outside of the >>>> offer-answer exchange. So, in other words, there is no reason >>>> whatsoever that would really require use of offer/answer. There are >>>> however many reasons not to: >> >>> Of course it has something to do with O/A. ICE is also exchanged in O/A. >>> And the candidates you need to exchange are coupled to what was exchanged >>> in O/A. >> >>> Suppose you do one O/A exchange including ICE candidates, and then one or >>> both sides starts to trickle candidates with INFO. Then one side sends a >>> new offer, that changes the m-lines in some way. Presumably it will also >>> contain some ICE candidates. And then the other side sends another >>> trickle ICE INFO. How do all of these things relate? Is this even legal? >> >>> Certainly you can set down a set of protocol rules so that it becomes >>> well defined. But you are going to need to take the SIP O/A rules into >>> account while doing that. >> >>>> 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob >>>> answers. Both do full trickle. One O/A exchange has completed so now >>>> either of them can re-Offer. Obviously, if both are trickling, there's >>>> a pretty good chance for glare to occur. Also, after Bob sends a >>>> re-offer with trickled candidates, and then immediately learns of new >>>> candidates, it will not be able to immediately send them because it >>>> needs to first obtain an answer from Alice. Alice on the other hand may >>>> have nothing to say at the moment, but she may be giving it some >>>> thought (i.e. waiting for some checks to complete). >> >>> You assume that a subsequent offer is used *only* to update trickle ICE. >>> There are other reasons for a new offer. >> >>> Or are you assuming some constraints such as that first you do an O/A, >>> and then agree not to do another one until all trickling for the first >>> one has been completed? >> >>>> 4. Constantly updating the state of the offer answer machine. Oh my >>>> ... I get goose bumps only thinking about it. Every time new candidates >>>> are sent, new offers and answers will be exchanged. Clients would need >>>> to make sure that their view of the O/A state is properly updated and >>>> not only that but we would also need to make sure that: >>>> >>>> 5. All media aware intermediaries will also have to track the deluge >>>> of offers and answers and update their own states. It should be >>>> perfectly fine for such intermediaries to see the first offer and then >>>> the updated ICE offer. And that's that. >> >>> That doesn't work so well for those intermediaries that gate media, and >>> so won't let anything through (including ICE) until they have seen the >>> address in signaling and opened the gate for it. >> >>>> 6. ... And all this diffing. To me difs, are one of the worst parts of >>>> the O/A model. Analysing thousands of bytes just to find that the only >>>> difference is an added a=sendonly attribute ... how did this ever >>>> happen (in comparison XMPP only sends ). >> >>> It is called idempotence. >> >>> This presumes that you implement this by first finding the difference and >>> then applying it to your current state, rather than just setting out to >>> apply the entire new specification to your current state. >> >>> There are pros/cons to both ways, and its not surprising that people are >>> most comfortable with the one most familiar to them. >> >>>> Adding the same thing for trickle would make for extremely complicated >>>> code. You'd have to be prepared to update ICE state, remap your >>>> streams, add new ones, change codecs, and basically redo your entire >>>> session while trickling. Toe me it sounds like of of this is not even >>>> possible. Why would we lock ourselves into something like this? >> >>> So what do you propose to happen if it *does* prove necessary to do a new >>> O/A after trickling has begun? Are you going to put the all the trickled >>> candidates into the offer? If not, are you going to require that the >>> candidates be identical to what was in the prior offer? >> >>> ISTM you must confront this in any case. >> >>> Thanks, Paul >> >>>> Pretty much everyone in RAI agrees that SDP and O/A is something we >>>> are just stuck with and that it would be great if we weren't. Well in >>>> this case we aren't. So why would we do it? Unless we overlooked some >>>> substantial issue with INFO and that issue is resolved by use of O/A >>>> and UPDATE, then I think it would really be best for everyone not to go >>>> there :) >>>> >>>> Cheers, Emil >>>> >> >> Here's the call flow: >> >> STUN/Turn STUN/TURN Servers >> Alice Bob Servers | | >> | | |<--------------| | >> | | Candidate | | | | Discovery >> | | | (1) |-------------->| >> INVITE (Offer) | | | >> |------------------------>| | (2) | | >> 183 (Answer) |-------------->| | |<------------------------| >> | | | PRACK | | | >> |------------------------>| | | | >> 200 PRACK | | | |<------------------------| >> | | | | | (3) | >> | UPDATE (more cands) | Candidate | | >> |<------------------------| | (4) | | >> 200 UPDATE | | | |------------------------>| >> Discovery | | | Connectivity Checks | | | >> |<=======================>| | (5) | | >> UPDATE (last cands) |<--------------| | >> |<------------------------| | (6) | | >> 200 UPDATE | | | |------------------------>| >> | | | 180 | | | >> |<------------------------| | | | Connectivity >> Checks | | | |<=======================>| >> | | | | | | >> | 200 INVITE | | | >> |<------------------------| | | | >> | | | | 5245 SIP re-INVITE | >> | | |------------------------>| | | >> | 200 reINVITE | | | >> |<------------------------| | | | >> | | | | | >> | | |<===== MEDIA FLOWS =====>| | | >> | | | >> >> >> 3. Use accumulated candidate list >> >> As far as I understand the documents, the candidates are sent as soon as >> they are discovered. I think that it would be better to send an >> accumulated list of candidates instead of the delta list of candidates. >> The priority calculation and the elimination of redundant candidates do not >> need to know the complete list of candidate to work, but sending the >> accumulated list instead of a delta could permit in the future to remove >> candidates, if we find a need to do so. This also removed the need for >> sdpfrag. >> >> But the most important reason is for the next step. >> >> >> 4. Replace end-of-candidates attribute by precandidate attributes >> >> There is currently an end-of-candidates attribute that is sent to signal >> the end of the candidate gathering phase. I think it is better to do it >> the opposite way, i.e. to send candidates as they are discovered under a >> different attribute name, and then to send all the candidates only when the >> gathering phase is done. Here's the partial SDPs exchanged in the call >> flow in 2) but skipping one update (examples are from RFC 5245): >> >> (1) Alice sends all the candidates after the end of the gathering phase >> (half-trickle). She also signals that she supports trickle. >> >> a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ >> host >> >> (2) Bob knows that Alice supports half trickle, so he sends only the host >> candidates, which is all he has so far, but using the attribute >> precandidate instead of candidate. He sends them in a reliable 183: >> >> a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ >> host a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >> >> If Bob supported ICE but not trickle, he would have answered with its >> complete list of candidates. >> >> (3) Bob discovers some candidates, but there is more to come, so it sends >> a accumulated list of precandidates: >> >> a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ >> host a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr >> 10.0.1.1 rport 8998 a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ >> host >> >> (4) Alice responds with the same SDP than in (1) >> >> (5) Bob receives the last batch of candidates, so now it sends an SDP >> containing the all the candidates, as if it did not understand trickle.: >> >> a=ice-options:trickle a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ >> host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr >> 10.0.1.1 rport 8998 a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >> >> (6) Alice sends back the same SDP. Because Bob use candidate attributes >> instead of precandidate, she knows that she has all the candidates, as if >> end-of-candidates was received. >> >>>> _______________________________________________ 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 >> > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRXa5lAAoJECnERZXWan7E710QAN3hWWnsPCQw8iCFPHl6HxZ+ > Q48BfHNKKzHe3n0ApJxeRTm8w2M11nj4J6vC1OdAHpWDEElzeLJjMGExdnLBwxOy > wHS3jDGgKA9DVw2kBox7IIHMpbOoW2UwCx0lwM3YkwL8q4xrb4F3FmTHA5gAGgks > P/mXJdRR8DCP1oiWYQELb+QmnuvFgBYbcGBUBy8P+XfL7f04IPTe8Cre6DaXqmVP > CfAToyeiQKo/WTa5rk7sKr2veqsSPmQ5ZnyyHxMy+K42mrC2CD43bNR+HjfvUa24 > pzZWxGQdNHZymccs0IP/TdP0N2oA4fv+TEVPsGLjHyUdTuObP7PunZvCDWFxls+S > 3OOnTBILlor1BCUR50LtWPeqhjylFywQLTDHVdiz62b9URdfeQPT8ANJSVsplCpf > //ep2AbRZEbdRtbfUjpSBs5uTX2N7SjJ50PRX0tqDlZ6E33GVFjjh9R/PHFLUrlV > BQxN3vuEnXZJzas3j747eaEqDBENYF4RfDjJf237VQ4lFBTQHkkkHA5h5wr+Fl9N > JKMNyrlTctvEOfJ9A11SCfikySjUuE+ZxMz6Z58teQqqatGWwJpMOlfZdDDHMAUA > YC0PB2dPT6XbsRs9mhkqovMpzLoL9mlVz7LbKI+8Y9mIfVHNquerJR6x7D5JGGBA > gmxM38lPaf5NLOzqEeAv > =I//c > -----END PGP SIGNATURE----- > -- https://jitsi.org From alan.b.johnston@gmail.com Thu Apr 4 12:08: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 057BE21F96D0 for ; Thu, 4 Apr 2013 12:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.833 X-Spam-Level: X-Spam-Status: No, score=-98.833 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_18=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, 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 zJuk39PGt+hf for ; Thu, 4 Apr 2013 12:08:05 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85421F8E75 for ; Thu, 4 Apr 2013 12:08:05 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ni5so2942915obc.12 for ; Thu, 04 Apr 2013 12:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:x-mailer:from:subject:date :to; bh=7INlhwpEG1IsQPoeuILSvPRO6xB0lNEgLeF84vkw8H8=; b=wWY/7HgyXdwtZl4XaJjvE5uaH9kMzKRJmMj7rhvOnZ3IcZ0z5ohzr7HHW9ANoHNqwq PZY79meqVuV4p08tJY0c/18QJYfI3nb+5GYxMvRyL602mjzIakBIO9VpfZIaMBAyqeTK vKD8U5ojKQPLOpQO1NGLV/NTazPPFNo4znRY/SSumE5k5QecuO6E4eM3kABqFG+s9TzE NhOxyWNLA4xbYLsgLmY6Eqj47WHMGwpKVO0xpvnDgKuFWXzBMuGDYSr005YhPd2+ksiS Nb3oXggQotKSgHAvAW6iWuWWgAiRUtnI5g/vEb9kzGmxyBbe3YmklcgjljxLG1jJ21IR T8Vw== X-Received: by 10.182.72.5 with SMTP id z5mr5427822obu.24.1365102485029; Thu, 04 Apr 2013 12:08:05 -0700 (PDT) Received: from [10.98.196.208] (mobile-166-147-099-057.mycingular.net. [166.147.99.57]) by mx.google.com with ESMTPS id h9sm7945847obg.14.2013.04.04.12.08.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 12:08:03 -0700 (PDT) References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> In-Reply-To: <515DC02D.7050105@jitsi.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Alan Johnston Date: Thu, 4 Apr 2013 14:07:50 -0500 To: Emil Ivov Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Thu, 04 Apr 2013 19:08:07 -0000 I admit that my first thought was that UPDATE was more appropriate than INFO= .=20 But the more I think about it, trickling in new candidates is not necessaril= y a part of O/A, rather it can be thought of as communication between two IC= E Agents. For tunneling another protocol using SIP as transport, INFO is the= right choice.=20 Not every ICE candidate is signaled in SDP - Peer Reflexive Candidates, for e= xample.=20 And remember ICE has a second O/A exchange that brings the SDP into line wit= h the chosen candidate pair. - Alan - On Apr 4, 2013, at 1:02 PM, Emil Ivov wrote: > Hey Paul, >=20 > On 04.04.13, 15:50, Paul Kyzivat wrote: >>>> UPDATE works as well as INFO, and is more SIPish. >>>=20 >>> Well, I'd argue that there are more implementations out there making >>> some use of INFO than supporting UPDATE so I am not sure I agree with >>> this statement ;) >>=20 >> Do you mean more implementations of *trickle ICE* using INFO than=20 >> UPDATE? Or do you mean that in general there are more implementations of=20= >> SIP supporting and using INFO than supporting and using UPDATE? >>=20 >> I don't have real data, but I have the impression that for a long time=20= >> most sip implementations have supported UPDATE. >=20 > That was mostly a joke about which of the two feels more "SIPish". I was > referring to non-standard use of SIP INFO for things such as DTMF and > how there's probably more implementations supporting that, than > implementations that do UPDATE. >=20 >>> Seriously now. There are several reasons we did not go for UPDATE: >>>=20 >>> 1. Trickle ICE is not a new mechanism. It has been out there with XMPP >>> for almost 8 years and it is now also part of WebRTC. SIP is the late >>> arriver here and SIP implementations of trickle ICE are more likely to >>> have to adapt to existing working systems than the other way around. We >>> therefore believed that it would be a good think to preserve as much as >>> possible the way that trickle ICE has been implemented with these other >>> protocols. >>=20 >> ISTM that there is likely to be a lot of sip-sip use, perhaps more than=20= >> any other kind, perhaps not.=20 >=20 > Well I don't know about this. I know of very few SIP deployments that > even use ICE, let alone trickle ICE. As noted, the mechanism has existed > forever and has not been considered for SIP. ISTM that the only reason > we are even considering it now is because trickle is needed by RTCWEB > and because we didn't want to standardize trickle in general without > making sure we have a way to also make it work with SIP. >=20 >> If so, that would argue for something that=20 >> most naturally integrates into existing sip signaling. >=20 > I have nothing against natural integration as long as it doesn't just > mean "doing things the natural level of complexity that we are used to > getting with SIP, SDP and O/A". I'd like to point out no issues have > been raised for the INFO approach. The UPDATE proposal is just an > alternative way of doing the same thing, not a solution to a problem we > are having. >=20 >>> 2. We do not need to use offer answer. The exchange of trickled >>> candidates has nothing to do with offer/answer. It is simply >>> communication between ICE agents, pretty much the way connectivity >>> checks are. Trickled candidates are actually quite similar to >>> peer-reflexive candidates in that they are learned outside of the >>> offer-answer exchange. So, in other words, there is no reason whatsoever= >>> that would really require use of offer/answer. There are however many >>> reasons not to: >>=20 >> Of course it has something to do with O/A.=20 >=20 > I insist that it doesn't. It has exactly the same relationship to O/A as > peer-reflexive candidate discovery: it happens elsewhere and > intermediaries are notified about it post factum. >=20 >> ICE is also exchanged in O/A.=20 >> And the candidates you need to exchange are coupled to what was=20 >> exchanged in O/A. >=20 > Yes of course, but that's not the point I am making. The O/A exchanged > helped create agents and set their state. Now they have a life of their > own: they do checks by themselves, they discover peer-reflexive > candidates by themselves, and with trickle they can also discover other > kinds of candidates. >=20 >> Suppose you do one O/A exchange including ICE candidates, and then one=20= >> or both sides starts to trickle candidates with INFO. Then one side=20 >> sends a new offer, that changes the m-lines in some way. Presumably it=20= >> will also contain some ICE candidates. And then the other side sends=20 >> another trickle ICE INFO. How do all of these things relate? Is this=20 >> even legal? >=20 > It sounds to me like this would simply be an ICE restart and that the > second ICE INFO shouldn't happen (unless it is the result of a race > condition but that can easily be detected and ignored). >=20 >> Certainly you can set down a set of protocol rules so that it becomes=20 >> well defined. But you are going to need to take the SIP O/A rules into=20= >> account while doing that. >=20 > Sure. I don't think we really need a set of new rules though. >=20 >>> 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob answers.= >>> Both do full trickle. One O/A exchange has completed so now either of >>> them can re-Offer. Obviously, if both are trickling, there's a pretty >>> good chance for glare to occur. Also, after Bob sends a re-offer with >>> trickled candidates, and then immediately learns of new candidates, it >>> will not be able to immediately send them because it needs to first >>> obtain an answer from Alice. Alice on the other hand may have nothing to= >>> say at the moment, but she may be giving it some thought (i.e. waiting >>> for some checks to complete). >>=20 >> You assume that a subsequent offer is used *only* to update trickle ICE.=20= >=20 > Not at all. What I am saying is that doing trickle with O/A would give > you a ton of new offers and answers and handling those would be very > problematic. >=20 >> There are other reasons for a new offer. >=20 > Of course, and when they are needed, those could just be ICE restarts. >=20 >> Or are you assuming some constraints such as that first you do an O/A,=20= >> and then agree not to do another one until all trickling for the first=20= >> one has been completed? >=20 > No, this is not what I was assuming. >=20 >>> 4. Constantly updating the state of the offer answer machine. Oh my ... >>> I get goose bumps only thinking about it. Every time new candidates are >>> sent, new offers and answers will be exchanged. Clients would need to >>> make sure that their view of the O/A state is properly updated and not >>> only that but we would also need to make sure that: >>>=20 >>> 5. All media aware intermediaries will also have to track the deluge of >>> offers and answers and update their own states. It should be perfectly >>> fine for such intermediaries to see the first offer and then the updated= >>> ICE offer. And that's that. >>=20 >> That doesn't work so well for those intermediaries that gate media, and=20= >> so won't let anything through (including ICE) until they have seen the=20= >> address in signaling and opened the gate for it. >=20 > There are a few cases here: >=20 > 1. Intermediaries that gate media unconditionally would just put > themselves in the c=3D line which would cause an ICE mismatch and that > will be the end of it (with or without trickle). >=20 > 2. Intermediaries that try to be intelligent and work with ICE, by > adding relayed candidates or anything like this can be in one of the two > following cases: > a) they don't support trickle, in which case they should remove the > a=3Dice-options:trickle token and cause a fallback to vanilla ICE. > b) they know about trickle in which case they would look into INFO > messages. >=20 > I agree the above may need more discussion, but I simply don't think > that doing consecutive O/As with UPDATEs would just work out of the box > for any of the problematic situations. >=20 >>> 6. ... And all this diffing. To me difs, are one of the worst parts of >>> the O/A model. Analysing thousands of bytes just to find that the only >>> difference is an added a=3Dsendonly attribute ... how did this ever happ= en >>> (in comparison XMPP only sends ). >>=20 >> It is called idempotence. >>=20 >> This presumes that you implement this by first finding the difference=20 >> and then applying it to your current state, rather than just setting out=20= >> to apply the entire new specification to your current state. >=20 > Yup sure. The problem is that it exposes you to a number of situations > that you probably wouldn't need to handle otherwise (not idempotence > itself, but doing the diffing in O/A in general and trickle ICE in > particular). For example, when implementing this I'd have to make sure I > am prepared to take a candidate update offer that also places streams on > hold, changes codec sets (which would also mean that I'd have to > recalculate pacing timers for checks that are already in progress), adds > new streams, disables existing ones, etc., etc. All this while my checks > are already in progress. >=20 > Yet, I would need to worry about none of these if I simply take trickle > ICE for what it is: agent-to-agent communication that has no impact on > the state of O/A. >=20 >> There are pros/cons to both ways, and its not surprising that people are=20= >> most comfortable with the one most familiar to them. >>=20 >>> Adding the same thing for >>> trickle would make for extremely complicated code. You'd have to be >>> prepared to update ICE state, remap your streams, add new ones, change >>> codecs, and basically redo your entire session while trickling. Toe me >>> it sounds like of of this is not even possible. Why would we lock >>> ourselves into something like this? >>=20 >> So what do you propose to happen if it *does* prove necessary to do a=20 >> new O/A after trickling has begun?=20 >=20 > An ICE restart. >=20 >> Are you going to put the all the=20 >> trickled candidates into the offer? >=20 > This is an implementation choice. If the agent is capable of reusing > already obtained candidates, then they could certainly include them in > the new offer and speed up the process. >=20 >> If not, are you going to require=20 >> that the candidates be identical to what was in the prior offer? >=20 > No, certainly not. >=20 > Does this make sense? >=20 > Cheers, > Emil >=20 >>=20 >> ISTM you must confront this in any case. >>=20 >> Thanks, >> Paul >>=20 >>> Pretty much everyone in RAI agrees that SDP and O/A is something we are >>> just stuck with and that it would be great if we weren't. Well in this >>> case we aren't. So why would we do it? Unless we overlooked some >>> substantial issue with INFO and that issue is resolved by use of O/A and= >>> UPDATE, then I think it would really be best for everyone not to go ther= e :) >>>=20 >>> Cheers, >>> Emil >>>=20 >>>>=20 >>>> Here's the call flow: >>>>=20 >>>> STUN/Turn STUN/TURN= >>>> Servers Alice Bob Servers= >>>> | | | | >>>> |<--------------| | | >>>> | Candidate | | | >>>> | Discovery | | | >>>> (1) |-------------->| INVITE (Offer) | | >>>> | |------------------------>| | >>>> (2) | | 183 (Answer) |-------------->| >>>> | |<------------------------| | >>>> | | PRACK | | >>>> | |------------------------>| | >>>> | | 200 PRACK | | >>>> | |<------------------------| | >>>> | | | | >>>> (3) | | UPDATE (more cands) | Candidate | >>>> | |<------------------------| | >>>> (4) | | 200 UPDATE | | >>>> | |------------------------>| Discovery | >>>> | | Connectivity Checks | | >>>> | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| | >>>> (5) | | UPDATE (last cands) |<--------------| >>>> | |<------------------------| | >>>> (6) | | 200 UPDATE | | >>>> | |------------------------>| | >>>> | | 180 | | >>>> | |<------------------------| | >>>> | | Connectivity Checks | | >>>> | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>| | >>>> | | | | >>>> | | 200 INVITE | | >>>> | |<------------------------| | >>>> | | | | >>>> | | 5245 SIP re-INVITE | | >>>> | |------------------------>| | >>>> | | 200 reINVITE | | >>>> | |<------------------------| | >>>> | | | | >>>> | | | | >>>> | |<=3D=3D=3D=3D=3D MEDIA FLOWS =3D=3D=3D=3D=3D= >| | >>>> | | | | >>>>=20 >>>>=20 >>>> 3. Use accumulated candidate list >>>>=20 >>>> As far as I understand the documents, the candidates are sent as soon a= s they >>>> are discovered. I think that it would be better to send an accumulated= list >>>> of candidates instead of the delta list of candidates. The priority >>>> calculation and the elimination of redundant candidates do not need to k= now >>>> the complete list of candidate to work, but sending the accumulated lis= t >>>> instead of a delta could permit in the future to remove candidates, if w= e find >>>> a need to do so. This also removed the need for sdpfrag. >>>>=20 >>>> But the most important reason is for the next step. >>>>=20 >>>>=20 >>>> 4. Replace end-of-candidates attribute by precandidate attributes >>>>=20 >>>> There is currently an end-of-candidates attribute that is sent to signa= l the >>>> end of the candidate gathering phase. I think it is better to do it th= e >>>> opposite way, i.e. to send candidates as they are discovered under a di= fferent >>>> attribute name, and then to send all the candidates only when the gathe= ring >>>> phase is done. Here's the partial SDPs exchanged in the call flow in 2= ) but >>>> skipping one update (examples are from RFC 5245): >>>>=20 >>>> (1) Alice sends all the candidates after the end of the gathering phase= >>>> (half-trickle). She also signals that she supports trickle. >>>>=20 >>>> a=3Dice-options:trickle >>>> a=3Dcandidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host >>>>=20 >>>> (2) Bob knows that Alice supports half trickle, so he sends only the ho= st >>>> candidates, which is all he has so far, but using the attribute precand= idate >>>> instead of candidate. He sends them in a reliable 183: >>>>=20 >>>> a=3Dice-options:trickle >>>> a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>>> a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>>>=20 >>>> If Bob supported ICE but not trickle, he would have answered with its c= omplete >>>> list of candidates. >>>>=20 >>>> (3) Bob discovers some candidates, but there is more to come, so it sen= ds a >>>> accumulated list of precandidates: >>>>=20 >>>> a=3Dice-options:trickle >>>> a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>>> a=3Dprecandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.= 0.1.1 >>>> rport 8998 >>>> a=3Dprecandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>>>=20 >>>> (4) Alice responds with the same SDP than in (1) >>>>=20 >>>> (5) Bob receives the last batch of candidates, so now it sends an SDP >>>> containing the all the candidates, as if it did not understand trickle.= : >>>>=20 >>>> a=3Dice-options:trickle >>>> a=3Dcandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >>>> a=3Dcandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1= .1 rport >>>> 8998 >>>> a=3Dcandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host >>>>=20 >>>> (6) Alice sends back the same SDP. Because Bob use candidate attribute= s >>>> instead of precandidate, she knows that she has all the candidates, as i= f >>>> end-of-candidates was received. >>>>=20 >>>> - -- >>>> Marc Petit-Huguenin >>>> Email: marc@petit-huguenin.org >>>> Blog: http://blog.marc.petit-huguenin.org >>>> Profile: http://www.linkedin.com/in/petithug >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.12 (GNU/Linux) >>>>=20 >>>> iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO >>>> J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH >>>> MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli >>>> 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh >>>> uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0 >>>> snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r >>>> mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm >>>> eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR >>>> FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr >>>> Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ >>>> GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb >>>> yk3C5OOf2RWXhf6ekDuf >>>> =3DjzXd >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From richard.ejzak@alcatel-lucent.com Thu Apr 4 13:36: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 0795921F8C78 for ; Thu, 4 Apr 2013 13:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] 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 oF-SRjT3DDHc for ; Thu, 4 Apr 2013 13:36:13 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 237B921F8BA6 for ; Thu, 4 Apr 2013 13:36:13 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r34KaAXb020879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Apr 2013 15:36:11 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r34Ka9ds026747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Apr 2013 16:36:10 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.63]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 4 Apr 2013 16:36:10 -0400 From: "Ejzak, Richard P (Richard)" To: Justin Uberti Thread-Topic: [MMUSIC] 10 BUNDLE questions Thread-Index: AQHOIb7u3UCm9g19LUKs5F6HDPZz4ZiwwNgAgBTO+QCAAP1IoA== Date: Thu, 4 Apr 2013 20:36:09 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36ECB275@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: 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.57 on 135.245.2.35 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 04 Apr 2013 20:36:14 -0000 DQo+IEZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dIA0KPiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDAzLCAyMDEzIDc6MDYgUE0NCg0KPj4gT24gVGh1LCBNYXIg MjEsIDIwMTMgYXQgNjo1MiBQTSwgRWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCkgPHJpY2hhcmQu ZWp6YWtAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCj4+IEhpIEp1c3RpbiwNCj4+IEkgaGF2 ZSBjb21tZW50cyBvbiBpdGVtcyA0IGFuZCAxMCBpbiB5b3VyIG9yaWdpbmFsIGxpc3QuDQoNCj4+ IElmIHlvdSByZWxheCBjb25kaXRpb25zIDIsIDUgYW5kIDcgZm9yIHRoZSAxc3Qgb2ZmZXIsIGl0 IHdvdWxkIHNlZW0gYSBsaXR0bGUgc3RyYW5nZSBhbmQgd291bGQgcmVxdWlyZSBleHRyYSB3b3Jr IHRvIGNsZWFuIHVwIGFsbCB0aGUgbSBsaW5lcyBpbiB0aGUgMm5kIG9mZmVyIGlmIHRoZSAxc3Qg b2ZmZXIgaGFkIGRpZmZlcmVudCB2YWx1ZXMgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJw cmludCBpbiBhbGwgdGhlIG0gbGluZXMgb2YgdGhlIGdyb3VwLsKgIEFzIEkgc2VlIGl0LCBpdOKA mXMgZWFzaWVyIHRvIGhhdmUgdGhpcyBydWxlIGZyb20gdGhlIGJlZ2lubmluZyB1bmxlc3MgdGhl cmUgYXJlIHNvbWUgdXNlIGNhc2VzIHdoZXJlIHlvdSBtaWdodCB3YW50IGRpZmZlcmVudCB2YWx1 ZXMgZm9yIGM9LCBydGNwLW11eCBhbmQgYT1maW5nZXJwcmludCBpZiBidW5kbGUgY2Fubm90IGJl IG5lZ290aWF0ZWQuwqAgRG8geW91IChvciBhbnlvbmUgZWxzZSkgc2VlIGFueSByZWFzb24gdG8g aGF2ZSB0aGlzIGNhcGFiaWxpdHk/IMKgSXQgcHJvYmFibHkgaXNu4oCZdCB0aGF0IGltcG9ydGFu dCBhIHJ1bGUgKGV4Y2VwdCBmb3IgY29udmVuaWVuY2UpIHNpbmNlIGFueSBtaWRkbGVib3ggd2ls bCBnZXQgc3RyYWlnaHRlbmVkIG91dCB3aXRoIHRoZSAybmQgb2ZmZXIgYW5kIGFueSBwZWVyIGFn cmVlaW5nIHRvIGJ1bmRsZSBrbm93cyB0byBpZ25vcmUgdGhlIHRyYW5zcG9ydCByZWxhdGVkIGlu Zm9ybWF0aW9uIGZyb20gdGhlIG90aGVyIGxpbmVzIChleGNlcHQgYXMgZGlzY3Vzc2VkIGJlbG93 KS4NCg0KPiBXZSBhbHJlYWR5IG5lZWQgdG8gZGVhbCB3aXRoIHRoaXMgZm9yIGE9Y2FuZGlkYXRl LCBhPWNyeXB0byBhbmQgYT1pY2UtdWZyYWcvcHdkLCBzbyBJIGRvbid0IHNlZSB3aHkgaGF2aW5n IHRvIGFsc28gZG8gdGhpcyBmb3IgdGhlc2Ugb3RoZXIgYXR0cmlidXRlcyBtYWtlcyB0aGluZ3Mg YW55IGhhcmRlci4gSXQncyBub3Qgc3VwZXIgaW1wb3J0YW50LCBidXQgaXQgc2VlbXMgb2RkIHRv IHByb2hpYml0IHRoaW5ncyB0aGF0IHdvdWxkIHNlZW0gdG8gYmUgbW9zdGx5IHVucmVsYXRlZCB0 byBCVU5ETEUuDQoNCkkgbm93IGFncmVlIHdpdGggeW91Lg0KwqANCj4+IDEwOiBJIHRoaW5rIHdl IGhhdmUgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byB1bmJ1bmRsZSB3aXRoaW4gYSBQZWVyQ29ubmVj dGlvbi7CoCBGb3IgdGhlIGVycm9yIGNhc2UgZGVzY3JpYmVkICh0d2ljZSkgYXQgdGhlIG1pa2Ug aW4gT3JsYW5kbywgaWYgdGhlIGZpcnN0IGFuc3dlciBjb21lcyBiYWNrIGFza2luZyB0byBidW5k bGUgYnV0IHNpZ25hbGluZyBkaWZmZXJlbnQgcG9ydHMsIGl0IGlzIGJlY2F1c2Ugb2YgYW4gaW50 ZXJtZWRpYXJ5IGZvcndhcmRpbmcgYnVuZGxlIGF0dHJpYnV0ZXMgd2l0aG91dCB1bmRlcnN0YW5k aW5nIHRoZW0gd2hpbGUgcmVtYXBwaW5nIHBvcnRzLsKgIFRoZXJlIHNlZW1lZCB0byBiZSBhZ3Jl ZW1lbnQgaW4gdGhpcyBjYXNlIChvciBhdCBsZWFzdCB0aGUgb3BpbmlvbiB3YXMgZXhwcmVzc2Vk KSB0aGF0IHRoZSBvZmZlcmVyIG5lZWRzIHRvIGRldGVjdCB0aGlzIGNvbmRpdGlvbiBhbmQgc2Vu ZCBhIDJuZCBvZmZlciB3aXRoIGRpZmZlcmVudCBwb3J0cyBhbmQgd2l0aG91dCBidW5kbGUgKGVs c2UgdGhlIGFuc3dlcmVyIHdpbGwgY29udGludWUgdG8gYXNzdW1lIGJ1bmRsZSB3aGlsZSB0aGUg aW50ZXJtZWRpYXJ5IHdpbGwgbm90KS4gwqBOb3RlIHRoYXQgdGhpcyBjYXNlIGFwcGVhcnMgKHRv IHRoZSBhbnN3ZXJlcikgYXMgaWYgYnVuZGxlIGlzIHN1Y2Nlc3NmdWxseSBuZWdvdGlhdGVkIGJ1 dCB0aGVuIGl0IGlzIGltbWVkaWF0ZWx5IHJlbW92ZWQgd2l0aCB0aGUgMm5kIG9mZmVyLsKgDQo+ PsKgdQ0KPj4gSSB0aGluayB3ZSBhbHNvIGhhdmUgdGhlIDNwY2MgdXNlIGNhc2Ugd2hlcmUgYSBt aWQtY2FsbCBidW5kbGVkIG9mZmVyIGdvZXMgdG8gYSBkaWZmZXJlbnQgZW5kcG9pbnQgdGhhdCBj aG9vc2VzIG5vdCB0byBidW5kbGUuwqAgQXMgbG9uZyBhcyBpdCByZW1vdmVzIHRoZSBidW5kbGUg YXR0cmlidXRlcyBhbmQgcmV0dXJucyBkaWZmZXJlbnQgcG9ydHMsIHdoeSBzaG91bGQgd2UgZGlz YWxsb3cgdGhpcz8gwqBJdCBvbmx5IHJlcXVpcmVzIGFuIElDRSByZXN0YXJ0LsKgIFRoaXMgd2ls bCBldmVuIHdvcmsgd2l0aCBtb3N0IChuZXcpIGludGVybWVkaWFyaWVzIGV4Y2VwdCB0aG9zZSB0 aGF0IGNob2tlIG9uIHNlZWluZyB0aGUgc2FtZSBwb3J0IGluIG11bHRpcGxlIG0gbGluZXMuwqAg V2hpY2ggYnJpbmdzIG1lIHRvIHdoeSBJIHRoaW5rIHdlIGFsc28gbmVlZCB0byBiZSBhYmxlIHRv IGluZGljYXRlIHZpYSB0aGUgQVBJIHdoZXRoZXIgYSBtaWQtY2FsbCBvZmZlciBpcyB0byBiZSBz aWduYWxlZCB3aXRoIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBwb3J0cyBmb3IgYSBidW5kbGUgZ3Jv dXAgKGFzIEkgYWxzbyByZXF1ZXN0ZWQgYXQgdGhlIG1pa2UpLg0KDQo+IEkgdGhpbmsgdGhpcyBp cyBoYXJkZXIgdGhhbiB5b3Ugc2F5LiBJdCdzIG1vcmUgdGhhbiBhbiBJQ0UgcmVzdGFydCwgaXQg YWxzbyByZXF1aXJlcyByZS1rZXlpbmcgb2YgU1JUUCAoc2luY2Ugd2Ugbm93IG5lZWQgdW5pcXVl IGNyeXB0byBwZXIgbS1saW5lKSBhbmQgZGVhbGluZyB3aXRoIHRoZSBzb3J0LW9mLUJVTkRMRWQg Y2FzZSB3aGVyZSB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gcmVjZWl2ZSBCVU5ETEVkIGFuZCBub24t QlVORExFZCBtZWRpYSBwb3RlbnRpYWxseSBzaW11bHRhbmVvdXNseSBkdXJpbmcgdGhlIHRyYW5z aXRpb24uIEknZCByZWFsbHkgbGlrZSB0byBhdm9pZCBoYXZpbmcgdG8gZGVhbCB3aXRoIHRoaXMu DQoNClRoZXJlIGFyZSB0d28gdGhpbmdzIGJlaW5nIGRlc2NyaWJlZCBoZXJlIChiZWluZyBhYmxl IHRvIHVuYnVuZGxlIGFuZCBiZWluZyBhYmxlIHRvIHJlcXVlc3QgbmV3IG9mZmVycyB3aXRoIHNh bWUgb3IgZGlmZmVyZW50IHBvcnRzKSwgYW5kIGl0IHNlZW1zIHRoYXQgeW91IGFyZSBtb3N0IGNv bmNlcm5lZCBhYm91dCB0aGUgZm9ybWVyLiAgSSBhbSBhIGxpdHRsZSBzdXJwcmlzZWQgdGhhdCBI YWRyaWVsIChvbmUgb2YgdGhlIGluZGl2aWR1YWxzIHdobyBzcG9rZSBhdCB0aGUgbWlrZSBhYm91 dCB0aGUgZXJyb3IgY2FzZSBkZXNjcmliZWQgYWJvdmUpIGFuZCBNYWdudXMvb3RoZXJzICh3aXRo IHdob20gSSBhbHNvIHNwb2tlIHByaXZhdGVseSBhYm91dCBpdCkgaGF2ZSBub3QgY2hpbWVkIGlu IG9uIHRoaXMsIGFzIGl0IHdhcyBwcm92aWRlZCBhcyBhIGtleSBqdXN0aWZpY2F0aW9uIGZvciB0 aGUgbmVlZCB0byBoYXZlIHR3byBkaWZmZXJlbnQgb2ZmZXIgZm9ybWF0cyAoc2FtZS9kaWZmZXJl bnQgcG9ydHMpIHJhdGhlciB0aGFuIHRoZSBzaW1wbGVyIHNjaGVtZSBJIHByb3Bvc2VkIHdpdGgg YSBzaW5nbGUgb2ZmZXIgZm9ybWF0IChhbGwgZGlmZmVyZW50IHBvcnRzKS4gIEkgdW5mb3J0dW5h dGVseSBkb24ndCBzZWUgYW55IGdvb2QgYWx0ZXJuYXRpdmUgdG8gImRlYWxpbmciIHdpdGggdGhp cy4gIEFzIEkndmUgc2FpZCBiZWZvcmUsIGRlYWxpbmcgd2l0aCB0aGUgb2xkIGFuZCBuZXcgbWVk aWEgZm9ybWF0cyBkdXJpbmcgdGhlIHRyYW5zaXRpb24gdHJpZ2dlcmVkIGJ5IG9mZmVyL2Fuc3dl ciBpcyBhIGxvdCBsaWtlIGNsb25pbmcgLSB3aGljaCBjb3VsZCBoYXZlIGFsc28gc29sdmVkIG90 aGVyIGlzc3Vlcy4NCg0K From petithug@acm.org Thu Apr 4 17:18: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 48E1121F8D8F for ; Thu, 4 Apr 2013 17:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UlqYA68bGEYk for ; Thu, 4 Apr 2013 17:18:53 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 727F521F8D03 for ; Thu, 4 Apr 2013 17:18:53 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec] (unknown [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DAEAD201BF; Fri, 5 Apr 2013 02:18:51 +0200 (CEST) Message-ID: <515E1868.2010601@acm.org> Date: Thu, 04 Apr 2013 17:18:48 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Alan Johnston References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> In-Reply-To: <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: [MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 00:18:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/04/2013 12:07 PM, Alan Johnston wrote: > I admit that my first thought was that UPDATE was more appropriate than > INFO. > > But the more I think about it, trickling in new candidates is not > necessarily a part of O/A, rather it can be thought of as communication > between two ICE Agents. For tunneling another protocol using SIP as > transport, INFO is the right choice. > > Not every ICE candidate is signaled in SDP - Peer Reflexive Candidates, for > example. True. But so why not push the idea further, and use an in-band mechanism to send the newly discovered candidates? E.g. the Offerer still sends the full list of candidates but the Answered uses the same path than a successful connectivity check to send its candidates as it discovers them, using a new STUN transaction. The Offerer will add the candidates received in this new transactions more or less in the same way Peer Reflexive Candidates are added, and start connectivity checks in the other direction. The answered will send its answer only when it has collected all the candidates on its side, making it identical to non-trickle ICE. Obviously there is lot of details missing here, but that solution does not require UPDATE or INFO, or a=ice-options:trickle. It's probably not compatible with non-SIP trickle implementations, but perhaps a gateway can convert candidates in the signaling path to and from candidates in the media path. > > And remember ICE has a second O/A exchange that brings the SDP into line > with the chosen candidate pair. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXhhmAAoJECnERZXWan7EiuEP/AtJycZvB/8Qi23OBu2Nla+5 SKniH7J139IQy6v2gEoAfDweuwcwYIH2lgX78bQMXNm/1P42zkqwTuvGtFEGej2b Q1ln6VkSnYhujjg2kP1iRntQhcI7wgSWa+w32MkHD1HPtuD1eoyVhSD+XYNGZBBO 1IN69JTzlOw2ygYUWBGS5ni7GyoHnAmAXIK3gDbtHys9ENBt3eI+6+0eTL3Bco+h BfYeG96ubnO2/H9Qbop1/Q8HjygxySWIeUf8m1ZLelnmMU019UeHGdyq2+tuLo8V yzS+3jwptEx9lendnxJUyMv4BLcx1Gx/3TEuyCkRolCef3etjrlTaP6Qmnfvztpe OkHR3WAKMIqRRMXHVqd+9QqQOWAosEL6utXBQzDqtZQmdmY9Qqiu8JOvP8GGNxKo 2uUAKSceguGl5T46/j4zQd1WGMArgg3rPAOPhSy1zl3ycC67S4u0zFNG2KvDWbaF W+xzlTuQMzoHerCQdrTdxWWZCi4ngfEDtSVxAtZxDOiXs8TpwFHX1cEpjDKPMYln /MIbWSjE/ORSB8DU7OMADhsJft3S9RqVxd+ia1cM+rVYp1kDPsD8yE94pkf/kb9s 8EdFOpBpl4gPXLG2o+ffYKSBsolFzl6K/0vHtkLj/2AJCzmd9eDs8m3Xs55JaUy1 KAfPUaz3+CDBE8uCypSs =Ov6n -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Thu Apr 4 17:35: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 7D9E021F8E7A for ; Thu, 4 Apr 2013 17:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 RjOFa+N+RD8w for ; Thu, 4 Apr 2013 17:35:08 -0700 (PDT) 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 C3F0A21F8E6C for ; Thu, 4 Apr 2013 17:35:07 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id KnY71l0060vyq2s550b72F; Fri, 05 Apr 2013 00:35:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id L0b61l01L3ZTu2S3R0b7qP; Fri, 05 Apr 2013 00:35:07 +0000 Message-ID: <515E1C3A.3050309@alum.mit.edu> Date: Fri, 05 Apr 2013 08:35:06 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F36ECB275@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36ECB275@US70UWXCHMBA04.zam.alcatel-lucent.com> 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=1365122107; bh=GWinshaMgPtv/QdDbKO7d8/tLnoYfCey7NlO6iQ3zJc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cciI7wKh7pS3B7rYfzu98Js/ut1rBO1VQBRK7ycrVCw1ZF4ofJF4y/j5nnAMR2mRz /HEz81VBFRJQJS75ApASDU9mz7rY+3dQQxCwCIKNElOoc7boNFl0KwD8cFtgK/bCJx 3d1T241neemlgP+b7q/oDqCkqCpfSe5lCbcuDj/ickFa0NqzwMHNXtQSinarQICFdw a/IUisZYCG0D6e6bYKQLPsF+aXo5cU5bN4m4xgVKN6BnumN4zbLlbLPVon+LjkRqf+ 1XwfJ0YtsgDs5ZDuVkL4NwoE4Ggg1tQhtRt9CpifZZO2yaDa0PAZkWVD98x7oJOivE KOSZ01cZM6ENA== Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 05 Apr 2013 00:35:08 -0000 Replying to Justin, (For some reason I got Richard's replies to Justin, but not the messages from Justin!) On 4/5/13 4:36 AM, Ejzak, Richard P (Richard) wrote: >>> 10: I think we have to have the ability to unbundle within a PeerConnection. For the error case described (twice) at the mike in Orlando, if the first answer comes back asking to bundle but signaling different ports, it is because of an intermediary forwarding bundle attributes without understanding them while remapping ports. There seemed to be agreement in this case (or at least the opinion was expressed) that the offerer needs to detect this condition and send a 2nd offer with different ports and without bundle (else the answerer will continue to assume bundle while the intermediary will not). Note that this case appears (to the answerer) as if bundle is successfully negotiated but then it is immediately removed with the 2nd offer. >>> u >>> I think we also have the 3pcc use case where a mid-call bundled offer goes to a different endpoint that chooses not to bundle. As long as it removes the bundle attributes and returns different ports, why should we disallow this? It only requires an ICE restart. This will even work with most (new) intermediaries except those that choke on seeing the same port in multiple m lines. Which brings me to why I think we also need to be able to indicate via the API whether a mid-call offer is to be signaled with the same or different ports for a bundle group (as I also requested at the mike). > >> I think this is harder than you say. It's more than an ICE restart, it also requires re-keying of SRTP (since we now need unique crypto per m-line) and dealing with the sort-of-BUNDLEd case where we need to be able to receive BUNDLEd and non-BUNDLEd media potentially simultaneously during the transition. I'd really like to avoid having to deal with this. There are lots of things that I would really like to avoid dealing with. (E.g. income taxes.) But just because I would like to doesn't mean I can. 3pcc scenarios break a lot of first proposals for how to do things. The solution is to fix the proposal so it still works. You can't control whether this happens to you. Thanks, Paul From aavella77@yahoo.com Fri Apr 5 01:30:17 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 00C4321F92C5 for ; Fri, 5 Apr 2013 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 haT9kDLciAKZ for ; Fri, 5 Apr 2013 01:30:15 -0700 (PDT) Received: from nm36-vm4.bullet.mail.ne1.yahoo.com (nm36-vm4.bullet.mail.ne1.yahoo.com [98.138.229.116]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B421F95E0 for ; Fri, 5 Apr 2013 01:30:07 -0700 (PDT) Received: from [98.138.90.57] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 05 Apr 2013 08:30:06 -0000 Received: from [98.138.89.251] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 05 Apr 2013 08:30:06 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 05 Apr 2013 08:30:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 842646.90393.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 70918 invoked by uid 60001); 5 Apr 2013 08:30:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365150606; bh=IijZ0hhsMPH9WMV7kxmlrq/v/iA4htfMPI+2et1k7Gs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Ur8fNk8cUqzYgG41hUrmmC+Yn5BYEXTGL4Otpu8Ub/JZX08ZdTwWZm8B1tV4o6YWVmrswcJuusUhhEcW9UDALV+ttJTBW/xBHyC0S35OOQCbQLQv85/Q2YlL9Vog/2OAipk77H/GVbTY2O67R8oN1fZmYqjQoSJN06/Axp62EPg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=evZ446jteMzl5Ew26egi685nFVrg1BDysqrOUgghloMUASfjRiS4EXIkpVPglZVhfaNkqQof9zlo2ei+X1/jyoigJ2FX0TB9hngqictUN0a+laSyAMcq+dDtnV3NY9IhrDdu/00wFM7WCP5voQh/e+szZ29B1YVmmmCLqNP51/A=; X-YMail-OSG: 57hmCnoVM1kbDsrt5UTK7cQwzF2sBHbBfbVUkqsVgxA.RCL nDriEou4a7Y6dzAkg39uo4ipcUyUpIWUCWD3CjDyetBbS6YdrYtWdLwRRTU0 zAvgDpc.sx0w3YDIyL2PKJFclsgabM10uUt646x36cJxXy23ibIvrC5p56va JnCJLgyyDYRyscuJdtPSjqp4.0L7_CuZuZe.RNLhq005KRw21jp3kWnZMUS3 JG5zIK0jeeTw8GKT2zRX7eS2jaLn4iieGcrt2p7_kBa7oVeq1zrsbkvAy_Gt ARVUEIUPi5ZOTT0.Zbc_Eu6TKwyh4p75Cse_e0onfgvQQ84y51tOMnRPpshC Xn8LEqaNDP55MQ3Z5Zykb1DaRFmGbyb.mmP2d6c7fzdeQYBMri07GH4GBwnQ tWh20gXKhu05vgYWkNLiNV6.AvmS2ZWcRD35D9gGVRapTAYOXzH7Kx7BijfU p6d.56ujlbMm0l3HnnJ2r35C5GQUpchkGCUWfE3BBEjO3qEMu9DShcfD9qFW E.NnClRFdeFqJ1jkaEkwuHMe5b5k3mB1fFNVkPZakxi945Rod8d4mrXXpSnb p8sckO5GMxAGiiTieB_BATun5iOSYFAsbkJ1JOZGmzkPwAONohaToWklnPUB 6d_4- Received: from [123.26.233.205] by web122002.mail.ne1.yahoo.com via HTTP; Fri, 05 Apr 2013 01:30:06 PDT X-Rocket-MIMEInfo: 002.001, aHR0cDovL3d3dy5tYWRlaW5jcmV0ZS5jb20vaW5jbHVkZXMvbG92ZXBsdWdpbi5waHA_Y21nd3I3MTJsZWJ1bmUKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCi0tLS0tLQpNYXkgeW91ciBtb3V0aCBuZXZlciBjbG9zZSBhbmQgeW91ciBhcnNlIG5ldmVyIG9wZW4uATABAQEB X-Mailer: YahooMailWebService/0.8.140.532 Message-ID: <1365150606.68752.YahooMailNeo@web122002.mail.ne1.yahoo.com> Date: Fri, 5 Apr 2013 01:30:06 -0700 (PDT) From: aea To: mperezo , mmusic , Gustavo Carrero , Rafael Franco , robertico gonzalez77 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1073417382-1594706628-1365150606=:68752" Subject: [MMUSIC] hi! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aea List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:30:17 -0000 --1073417382-1594706628-1365150606=:68752 Content-Type: text/plain; charset=us-ascii http://www.madeincrete.com/includes/loveplugin.php?cmgwr712lebune ------ May your mouth never close and your arse never open. --1073417382-1594706628-1365150606=:68752 Content-Type: text/html; charset=us-ascii
http://www.madeincrete.com/includes/loveplugin.php?cmgwr712lebune




































































































------
May your mouth never close and your arse never open.
--1073417382-1594706628-1365150606=:68752-- From thomas.stach@siemens-enterprise.com Fri Apr 5 03:04: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 BB72A21F9669 for ; Fri, 5 Apr 2013 03:04:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozZc7rwsTrnO for ; Fri, 5 Apr 2013 03:04:13 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C45C921F970C for ; Fri, 5 Apr 2013 03:04:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0FBAF1EB84DB; Fri, 5 Apr 2013 12:04:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Fri, 5 Apr 2013 12:04:09 +0200 From: "Stach, Thomas" To: Emil Ivov , Marc Petit-Huguenin Thread-Topic: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice Thread-Index: AQHOML9FDf6aeN36rE2qZ64lnSNh25jHZe1w Date: Fri, 5 Apr 2013 10:04:09 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> In-Reply-To: <515CB4F2.3010404@jitsi.org> Accept-Language: de-AT, en-US Content-Language: de-DE 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 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 10:04:14 -0000 inline Emil Ivov wrote: > Hey Marc and thanks for your comments! >=20 > Replies inline. >=20 > On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >>=20 >> I read draft-ivov-dispatch-trickle-ice-sip and >> draft-ivov-mmusic-trickle-ice during the preparation of the >> rfc5245bis draft and I have some suggestions that I will be >> presenting step by step below:=20 >>=20 >> 1. The 180 needs to be reliable >=20 > Agreed. We'll make the change in the next revision. >=20 The answer with any initial candidates needs to be in a 183 not a 180. In addition, I don't think that the 183 needs to be reliable. This was not necessary for RFC5245 and could also be avoided for trickle IC= E, since the INFO with the new candidates is already reliably sent.=20 If the INFO contains always the complete list of candidates (instead of jus= t a delta), the ICE agents will=20 eventually have all candidates even if the 183 with the initial candidates = got lost with the initial candidates. As an optimisation if you don't want to always send the complete list,=20 you could just include it in the first INFO and use deltas afterwards. Regards Thomas= From ari.keranen@ericsson.com Fri Apr 5 07:59:17 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 5A43121F97EE for ; Fri, 5 Apr 2013 07:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5+oaO25Al3GM for ; Fri, 5 Apr 2013 07:59:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7440D21F97EC for ; Fri, 5 Apr 2013 07:59:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-78-515ee6c3ed6e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 86.7B.10459.3C6EE515; Fri, 5 Apr 2013 16:59:15 +0200 (CEST) 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; Fri, 5 Apr 2013 16:59:15 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1126E24ED for ; Fri, 5 Apr 2013 17:59:15 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3D75E54965 for ; Fri, 5 Apr 2013 17:59:12 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F154354942 for ; Fri, 5 Apr 2013 17:59:11 +0300 (EEST) Message-ID: <515EE6C1.6080608@ericsson.com> Date: Fri, 5 Apr 2013 17:59:13 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 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+NgFupiluLIzCtJLcpLzFFi42KZGfG3Vvfws7hAg/9PpSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMt3/zIX9DJXrNq5iLGB8ThTFyMnh4SAicTvQ88YIWwxiQv3 1rN1MXJxCAmcYpSY2b6BHcJZzyhxd8kSVgjnIqPE1IYWqMwRRon+JxuYIJx9jBIXL25jBxnG K6At0X7iCdgSFgEVic27t7CB2GwC9hI3J1wHqxEVSJa4+v8TC0S9oMTJmU/AbBEBGYm9mzYz g9jCQAfuW3yEFcRmFrCVuDDnOguELS+x/e0cZojD1SSuntsEZgsJqEpc/feKcQKj0CwkY2ch aZ+FpH0BI/MqRvbcxMyc9HLDTYzA8Dy45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwDh5UeL7awVLLn9dvvzmHHleu5J24dAZ8yRX+wgd2hpmp7f2/JL7 +xPeZedFyhQ+uvYl9U5XZwfX1bJj+0zz8o5knuNOlH2/f2b07OqbL2tVJMxjU0u9xRymXtsX dZl3x9/uqddMV/pkPtDnf31RzLzKp8lcf8k5/oOJwlOSrn2vuCea9PNFzEUlluKMREMt5qLi RADvDybGHQIAAA== Subject: [MMUSIC] RTP grouping taxonomy work at the AVTEXT WG 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, 05 Apr 2013 14:59:17 -0000 Hi all, The "Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" draft [1] was presented at the joint AVTEXT/MMUSIC session at the Orlando meeting. Note that this work will be progressed at the AVTEXT WG and discussed on the AVTEXT mailing list. Cheers, Ari [1] http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-00 From ari.keranen@ericsson.com Fri Apr 5 10:03: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 3585821F96F2 for ; Fri, 5 Apr 2013 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 d6VOleW1iNsM for ; Fri, 5 Apr 2013 10:03:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0AE21F9675 for ; Fri, 5 Apr 2013 10:03:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-e1-515f03f1945f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A6.27.10459.1F30F515; Fri, 5 Apr 2013 19:03:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Apr 2013 19:03:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D616124ED; Fri, 5 Apr 2013 20:03:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0EB3C54965; Fri, 5 Apr 2013 20:03:42 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8DEC454942; Fri, 5 Apr 2013 20:03:41 +0300 (EEST) Message-ID: <515F03EF.1030100@ericsson.com> Date: Fri, 5 Apr 2013 20:03:43 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic , draft-ietf-mmusic-duplication-grouping@tools.ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre5H5vhAg6kLxS12P/jOZDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj9q1n7AWXmCumtz5mbmD8xdTFyMkhIWAi sfTqD0YIW0ziwr31bF2MXBxCAqcYJab9PMkO4axnlHjyahErhLObUaJ/WTs7SIuQwDpGiVdn JSASKxglZjw5B5Tg4OAV0Ja4eSwUpIZFQEVi888jYCvYBOwlbk64DtYrKpAscfX/JxYQm1dA UOLkzCdgtohAmMTNG5fB6oUFrCVaFz9jBbGZBWwlLsy5zgJhy0tsfzuHGeJsNYmr5zYxQ9yj KnH13yvGCYxCs5CMnYWkfRaS9gWMzKsY2XMTM3PSyw03MQLD9eCW37o7GE+dEznEKM3BoiTO G+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI6PJGSmv7LfcJ6+XpzLddJ+8Si3KSErT 9cRebhVvxfa8khVMQc3xCnOPPvN68+nG3n6GV4mTz8dMEvVjnC9eF+QgOnNrQS7ftncy84+4 pC5qvHMhcYlFi++Fqwxv9E03KT7olRHN1n5+8G/uIYarn3IehF+Rt839+eprw5HYhQIBEQrV /AlLlViKMxINtZiLihMBdQ1bYiUCAAA= Subject: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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, 05 Apr 2013 17:03:47 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-duplication-grouping-01 The WGLC ends on April 19th, 2013. Please review the document send your comments both to the authors and to the MMUSIC mailing list. If you review the document but do not have any comments, please send a note to that effect as well. The document is available here: http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-01 Thanks, Ari From ari.keranen@ericsson.com Fri Apr 5 10:03: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 30E1621F980B for ; Fri, 5 Apr 2013 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 7zbV+dgGqXVI for ; Fri, 5 Apr 2013 10:03:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3221F9800 for ; Fri, 5 Apr 2013 10:03:51 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-44-515f03f56064 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id ED.37.19728.5F30F515; Fri, 5 Apr 2013 19:03:50 +0200 (CEST) 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; Fri, 5 Apr 2013 19:03:49 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A02A624ED; Fri, 5 Apr 2013 20:03:49 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E164C54965; Fri, 5 Apr 2013 20:03:46 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E36BB54942; Fri, 5 Apr 2013 20:03:44 +0300 (EEST) Message-ID: <515F03F3.6070400@ericsson.com> Date: Fri, 5 Apr 2013 20:03:47 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mmusic , draft-ietf-mmusic-delayed-duplication@tools.ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre435vhAg1ntghb7L95mtZi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXxauJDtoILzBV3DjUzNTD+YOpi5OSQEDCR mLPmDzuELSZx4d56ti5GLg4hgVOMEuebJrJDOOsZJT52P2aEcHYzSjTseQiVWcco8WDbK1aQ fiGBFYwS3zcIdDFycPAKaEu8vRwMEmYRUJF4duAo2Do2AXuJmxOug60TFUiWuPr/EwuIzSsg KHFy5hMwW0QgVOLKu2tsILawgJXEof9rwOqZBWwlLsy5zgJhy0tsfzuHGeJsNYmr5zYxQ5yg KnH13yvGCYxCs5CMnYWkfRaS9gWMzKsY2XMTM3PSy402MQLD9eCW36o7GO+cEznEKM3BoiTO G+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo8zryfMn7bldbJ6fXdXM5vkqx+zhAW0Z A6XbZQ9Ohjpv3PT6qWDjPcVfHL4/psrmiHhamLb53bJ7YRxXNDFWtPGIoG7EImZl29zQ+Tsf rrjLMbHhCntT8ykv8asrk9jebn+z0bbPt+h1aFz8+gDmWkc1oUcPfVitT544aZrxa6uoZJvO epXXSizFGYmGWsxFxYkA2T5aXCUCAAA= Subject: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 05 Apr 2013 17:03:52 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-delayed-duplication-01 The WGLC ends on April 19th, 2013. Please review the document send your comments both to the authors and to the MMUSIC mailing list. If you review the document but do not have any comments, please send a note to that effect as well. The document is available here: http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-01 Thanks, Ari From emil@sip-communicator.org Fri Apr 5 11: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 412AE21F9862 for ; Fri, 5 Apr 2013 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=1.734, 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 9TMswixqd5L5 for ; Fri, 5 Apr 2013 11:51:14 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 453C221F984B for ; Fri, 5 Apr 2013 11:51:14 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so4140822wgh.27 for ; Fri, 05 Apr 2013 11:51:13 -0700 (PDT) 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=QQfueZeZ8XX2a9kqDXErvnFR1/Gch6AFMAtJwlKgYJE=; b=e11sfdrRmqA9cSwdzIrUoBee9ylHmmcCN6OabC1kosDsaKeahFwAApKH0NY/YEfEcS CwR0eykdxXS62G4FTxHENG5SakSvtfWnK2WBhoq3U1PVrNGR6OquFwkoZLMrIs8rifhS I26riSYm6QXlF+UVd9BfhvqdicJuyMpPpLFAMv3r1vLGRZCI8QTiFfgfzsUeg4PS04Ks MrspNAOjRaT63dJX1uSZLJ+QCNwJci1iiqg04V6l5cSKjIxF/RC91ZzA8z1ZL4yf+MWT YLGl5/lDutlTkvI5SE4ItWHab0ZAwyUzTe9Irz1aSS9G97dZ30vTskw2TvBVLt5azRes ftsw== X-Received: by 10.194.121.6 with SMTP id lg6mr18611605wjb.22.1365187873443; Fri, 05 Apr 2013 11:51:13 -0700 (PDT) Received: from camionet.local (ip-15.net-81-220-185.rev.numericable.fr. [81.220.185.15]) by mx.google.com with ESMTPS id gl11sm5352274wic.8.2013.04.05.11.51.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 11:51:12 -0700 (PDT) Message-ID: <515F1D24.8040703@jitsi.org> Date: Fri, 05 Apr 2013 20:51:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Stach, Thomas" References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnbwUHsf8DOMEJ8QRj3KGiUDQ2vun/e9nvPIwtdVE9/TAlhYAcLC7wk+WiG/uJLpzEeaPpI Cc: Marc Petit-Huguenin , "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 18:51:15 -0000 Hey Thomas, On 05.04.13, 12:04, Stach, Thomas wrote: > inline > > Emil Ivov wrote: >> Hey Marc and thanks for your comments! >> >> Replies inline. >> >> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> I read draft-ivov-dispatch-trickle-ice-sip and >>> draft-ivov-mmusic-trickle-ice during the preparation of the >>> rfc5245bis draft and I have some suggestions that I will be >>> presenting step by step below: >>> >>> 1. The 180 needs to be reliable >> >> Agreed. We'll make the change in the next revision. >> > The answer with any initial candidates needs to be in a 183 not a 180. Well 5245 actually talks about 18x but I agree that using 183 rather than 180 would help manage post pick-up latency better. > In addition, I don't think that the 183 needs to be reliable. > This was not necessary for RFC5245 and could also be avoided for trickle ICE, since the > INFO with the new candidates is already reliably sent. Well, it's not only about the candidates (the 183 could actually contain none of those). However, we'd also need to make sure that things like the ufrag and password are also received. > If the INFO contains always the complete list of candidates (instead of just a delta), the ICE agents will > eventually have all candidates even if the 183 with the initial candidates got lost with the initial candidates. > As an optimisation if you don't want to always send the complete list, > you could just include it in the first INFO and use deltas afterwards. I like this suggestion and I agree we could add something along those lines in case PRACK is not user or supported. Thanks for the tip! Emil > > > Regards > Thomas > -- https://jitsi.org From pkyzivat@alum.mit.edu Fri Apr 5 12:10: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 DEBA921F9891 for ; Fri, 5 Apr 2013 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 2VzfbXk1u8wW for ; Fri, 5 Apr 2013 12:10:36 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 0505621F989E for ; Fri, 5 Apr 2013 12:10:35 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id LH6P1l0060cZkys59KAbPt; Fri, 05 Apr 2013 19:10:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id LKAb1l00M3ZTu2S3WKAbn0; Fri, 05 Apr 2013 19:10:35 +0000 Message-ID: <515F21AA.2080003@alum.mit.edu> Date: Sat, 06 Apr 2013 03:10:34 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> In-Reply-To: <515F1D24.8040703@jitsi.org> 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=1365189035; bh=MXnI469RhijYaBxnoxJS3n6avAN4EPj0cEKr3lhhPGc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KwrExdeDsNPldzT6IaSMC7uxpkOVpn9raN4byih2RkISpMqbYmjFZiHSa7Ou6oxtV X9UyvxmOdieP6VzquntWWKfRIOUB/T8DBuuFEqgePjo9aIry0/7g58BoovlcPRtQts FpjFOa6nSkHe4075oghNiCh58U556UGeFa07MPoSrSqQucWEW7iKh1xwg7PKK1oKZQ +yZL3RTKxLndKkxSR5NfmVgFpTHFmaldmjYZX2FTXSzAXJuaP+Wy3E/aYBOMGRo5C8 uHGJ4hTweS5uykOASGFNeGHcpzDdrCOJSzijqEqtewkcSGdWQSDzWzX86tzNf9N+y+ 1dz8caXACXz5A== Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 19:10:37 -0000 Note that until at least one provisional response makes it back to the UAC it won't be possible for the UAC to send INFOs. (It can't do so until there is an early dialog.) So its possible that if you only send unreliable provisionals then the trickling from UAC to UAS may not be happen until the call is established. Thanks, Paul On 4/6/13 2:51 AM, Emil Ivov wrote: > Hey Thomas, > > On 05.04.13, 12:04, Stach, Thomas wrote: >> inline >> >> Emil Ivov wrote: >>> Hey Marc and thanks for your comments! >>> >>> Replies inline. >>> >>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>> rfc5245bis draft and I have some suggestions that I will be >>>> presenting step by step below: >>>> >>>> 1. The 180 needs to be reliable >>> >>> Agreed. We'll make the change in the next revision. >>> >> The answer with any initial candidates needs to be in a 183 not a 180. > > Well 5245 actually talks about 18x but I agree that using 183 rather > than 180 would help manage post pick-up latency better. > >> In addition, I don't think that the 183 needs to be reliable. >> This was not necessary for RFC5245 and could also be avoided for trickle ICE, since the >> INFO with the new candidates is already reliably sent. > > Well, it's not only about the candidates (the 183 could actually contain > none of those). However, we'd also need to make sure that things like > the ufrag and password are also received. > >> If the INFO contains always the complete list of candidates (instead of just a delta), the ICE agents will >> eventually have all candidates even if the 183 with the initial candidates got lost with the initial candidates. >> As an optimisation if you don't want to always send the complete list, >> you could just include it in the first INFO and use deltas afterwards. > > I like this suggestion and I agree we could add something along those > lines in case PRACK is not user or supported. > > Thanks for the tip! > Emil >> >> >> Regards >> Thomas >> > From martin.thomson@gmail.com Fri Apr 5 15:27: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 0DF7B21F9937 for ; Fri, 5 Apr 2013 15:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 gd6ICRcGxKHZ for ; Fri, 5 Apr 2013 15:27:07 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id BA00221F9935 for ; Fri, 5 Apr 2013 15:27:06 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so4378359wgh.9 for ; Fri, 05 Apr 2013 15:27:06 -0700 (PDT) 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=5ekAk6TKx6Vv4BFRkl2UJ5g5wjuQfGwI8TL46H3pnGg=; b=ULGKrrbVN6haf2+5dCo1ZVmFpH2+yoGB0dobJGb8nI6It6pSQ+xd99dCslBJYxSejI m1bgZGlfcss0JOpTGfqxMZ3xyn++qtwAAuaLuOHkzvfOMd71g4ZLQgy9PaE7OaCVNVn+ 5BMqNEC4fvLBZ6Gm/Cuw3VF7sCcMapSM73Ad3X+2BVwT8ZyrpwhW7+8aYddV7tfTRoWB cF2bS1aQGr5yZpYxzcO7uGMyEwaYL5pv0xHyXn8t8EfoOReDQ9qEkhYB5lYp5VN/yTDJ 2F5SJqeE+KCNVbjWkrhni25DiKWIu58XdTJi1LNkNTMNU9E5yYzG8/UeVAd1Am9Tm/ql jWxw== MIME-Version: 1.0 X-Received: by 10.194.82.104 with SMTP id h8mr19550579wjy.3.1365200825978; Fri, 05 Apr 2013 15:27:05 -0700 (PDT) Received: by 10.194.41.35 with HTTP; Fri, 5 Apr 2013 15:27:05 -0700 (PDT) In-Reply-To: <515E1868.2010601@acm.org> References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> <515E1868.2010601@acm.org> Date: Fri, 5 Apr 2013 15:27:05 -0700 Message-ID: From: Martin Thomson To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Cc: Alan Johnston , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 22:27:08 -0000 On 4 April 2013 17:18, Marc Petit-Huguenin wrote: > True. But so why not push the idea further, and use an in-band mechanism to > send the newly discovered candidates? That only works if you find a workable path using un-trickled candidates. That seems unlikely, except in the half-trickle case. From petithug@acm.org Fri Apr 5 16:26: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 D72F121F970F for ; Fri, 5 Apr 2013 16:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, NO_RELAYS=-0.001, 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 xkadAEKSdFIq for ; Fri, 5 Apr 2013 16:26:44 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEE21F9706 for ; Fri, 5 Apr 2013 16:26:44 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec] (unknown [IPv6:2601:9:4bc0:1f:84a4:8f1c:631d:60ec]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CDB2E202EB; Sat, 6 Apr 2013 01:26:42 +0200 (CEST) Message-ID: <515F5DB0.5020305@acm.org> Date: Fri, 05 Apr 2013 16:26:40 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Martin Thomson References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> <515E1868.2010601@acm.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Johnston , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Fri, 05 Apr 2013 23:26:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/05/2013 03:27 PM, Martin Thomson wrote: > On 4 April 2013 17:18, Marc Petit-Huguenin wrote: >> True. But so why not push the idea further, and use an in-band mechanism >> to send the newly discovered candidates? > > That only works if you find a workable path using un-trickled candidates. > That seems unlikely, except in the half-trickle case. > Yes, this is why I said that the Offerer sends the full list of candidates. But if the Offerer already knows that the Answerer supports this way of doing trickle, it just has to send one relayed candidate in the Offer (can even be the one in the m= line and do not send any a=candidates lines). Let's call this 3/4 trickle :-) - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRX12uAAoJECnERZXWan7EdycQAL+EF+Pdl528qncDVs/rkfqz wuMUcVeHKHrqTwon+GTuZ338ZXsBdbFo1YxZpujoMVRrW2T+/4mdHv1SENlBQI9f uXz6pooZPB3rhvPzIY10sE1qDwemqEJUIlvtO1BX1wRpMzuu5l9g1y0TBaENsf6J ChtOj6VSqzMp/f3D9Wd2sGXWi6pyLcrUEGoUAv+b1y/8m/voKn3TBhC1pt4D/K5b 43trZRkJ4/13zSvkhfKJ+wIMXRt1xWHYdrh79u2qsHFJQtffPSiHJoKtUd/yG2iQ yR9qDrqf93f7+4gx+2/dn5u6ndvhUTKhTAzFsDeG3drgMost8dt3LeHF73QV11kP aAC6/6uLUamz0YobZ+XeHLIf39RrA3+M0tXLs1PZsnp8ApAgzLMiXCm9efEAmtXl kOgJpBrfww5/UnW7uYQVCFePFp9nzmo8+Hvcqif5xeuFr6S0dbhMfe6njcfuLvXn CyfNzYKgPmH9vXL0sXQiC3AEMez81QpY2J/hgkTqfw9WPxfOTg4rcZr0U/7FLaP8 nslldbjPNgheFsiV5Qj0YDuvLZIPZGE2Xi/EsDhHChnmKbCpBZKtDLksvVigBMiQ 3AAwyvvSOXl7ltckOQvfxE3QHf3DXjv+YFvxUHWnUYLoQV+BZ3uMb6ZNmM8B0JVL KabzMlTgHrFC1OwG5rEK =WeGN -----END PGP SIGNATURE----- From emil@sip-communicator.org Fri Apr 5 23:02: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 B7B1C21F93ED for ; Fri, 5 Apr 2013 23:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 nRLclcVpQm9N for ; Fri, 5 Apr 2013 23:02:28 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53A21F93E5 for ; Fri, 5 Apr 2013 23:02:28 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so3319211wer.12 for ; Fri, 05 Apr 2013 23:02:27 -0700 (PDT) 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=mH65qx1hMPia9XaT2v59Tsge8Fr6yZfQxNLZtYsPRAE=; b=TJHcUtpsoJoz3gy1EGUvn1Kc8G3A8QkmLW6G+GUWDl47cA4/r3ypwZ1i2HO4Yz2ocA Swd6J0KslWl5EO22HvEWQXKLRCJoklZQqdTmfT22ncy18MoVHE6ft5aD740zW4k303uO cp/q0InoWRm9lJDqbyxJvtDHOeY6AISbqNvAePkpRmHWYM2r/BdYrecMlWXTaIw+KwyJ 6AVYJYJXrAmIvGFZBSMYe+xK7O+Y7dFfiJyCTVT4NnVQdzFoRiwqlm5ABTD/TbL8O5pu oWvBxHtVwpfwcwTgVchyBpd85h5gOqIMP0xgKaD/T2A5JxfBtcfbO/4q5hxP+k58JmZl aFjw== X-Received: by 10.180.188.141 with SMTP id ga13mr2654959wic.9.1365228147753; Fri, 05 Apr 2013 23:02:27 -0700 (PDT) Received: from vpn-rp-3.u-strasbg.fr (vpn-rp-3.u-strasbg.fr. [130.79.91.50]) by mx.google.com with ESMTPS id du2sm7378733wib.0.2013.04.05.23.02.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 23:02:26 -0700 (PDT) Message-ID: <515FBA77.1030007@jitsi.org> Date: Sat, 06 Apr 2013 08:02:31 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> In-Reply-To: <515F21AA.2080003@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlJcN9BF7Ng0Mg77krzwgHZmAIsBZWVMeiExrkbYyMjbtl/dpFxGz19FblLLTj6C/L7o69W Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-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: Sat, 06 Apr 2013 06:02:30 -0000 On 05.04.13, 21:10, Paul Kyzivat wrote: > Note that until at least one provisional response makes it back to the > UAC it won't be possible for the UAC to send INFOs. (It can't do so > until there is an early dialog.) > > So its possible that if you only send unreliable provisionals then the > trickling from UAC to UAS may not be happen until the call is established. Great point! So it seems like we are back to mandating PRACK. What would be the issue with this anyway? Emil > > Thanks, > Paul > > On 4/6/13 2:51 AM, Emil Ivov wrote: >> Hey Thomas, >> >> On 05.04.13, 12:04, Stach, Thomas wrote: >>> inline >>> >>> Emil Ivov wrote: >>>> Hey Marc and thanks for your comments! >>>> >>>> Replies inline. >>>> >>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>>> rfc5245bis draft and I have some suggestions that I will be >>>>> presenting step by step below: >>>>> >>>>> 1. The 180 needs to be reliable >>>> >>>> Agreed. We'll make the change in the next revision. >>>> >>> The answer with any initial candidates needs to be in a 183 not a 180. >> >> Well 5245 actually talks about 18x but I agree that using 183 rather >> than 180 would help manage post pick-up latency better. >> >>> In addition, I don't think that the 183 needs to be reliable. >>> This was not necessary for RFC5245 and could also be avoided for trickle ICE, since the >>> INFO with the new candidates is already reliably sent. >> >> Well, it's not only about the candidates (the 183 could actually contain >> none of those). However, we'd also need to make sure that things like >> the ufrag and password are also received. >> >>> If the INFO contains always the complete list of candidates (instead of just a delta), the ICE agents will >>> eventually have all candidates even if the 183 with the initial candidates got lost with the initial candidates. >>> As an optimisation if you don't want to always send the complete list, >>> you could just include it in the first INFO and use deltas afterwards. >> >> I like this suggestion and I agree we could add something along those >> lines in case PRACK is not user or supported. >> >> Thanks for the tip! >> Emil >>> >>> >>> Regards >>> Thomas >>> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From Simo.Veikkolainen@nokia.com Sun Apr 7 23:35: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 72D2E21F9196 for ; Sun, 7 Apr 2013 23:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 yc4oohejacRX for ; Sun, 7 Apr 2013 23:35:49 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DA8AD21F9193 for ; Sun, 7 Apr 2013 23:35:48 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r386ZPZ8003550; Mon, 8 Apr 2013 09:35:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Apr 2013 09:35:26 +0300 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.211]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Mon, 8 Apr 2013 06:35:25 +0000 From: To: , , Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: AQHOKPiD6pdLNgC57ki9NhYvjILwhZjL7uuA Date: Mon, 8 Apr 2013 06:35:24 +0000 Message-ID: References: <514FA8F7.7060203@cisco.com> In-Reply-To: <514FA8F7.7060203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJqGQGjDbs/6xOk+Dlxfbjl5VXKchx6OzBfeO4cc3F7+MUmMtodKd85oy1wHYZv5GYzI/F/cmqh5CTck5O/f37Ckg4iIQ0p6ntfU9N5kbV2nfV1RKNHt/bxrpXz2caQPxdQ9DIzeR8Af1vFOIkyGETD2P9zbaIMH7Xd4m5/yUfeTo7OmxzVM9lJzMWfLt71lLsuVsIIEHgvQayV0c10JYimZxqiZsMdAlHRO6Bt+7fgcPg8vRBOJ4vBI1wZ4VPILHpN6/nqALJpZ83K0qfQ5RldQ== x-originating-ip: [172.21.81.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Apr 2013 06:35:26.0518 (UTC) FILETIME=[41591560:01CE3423] X-Nokia-AV: Clean Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 08 Apr 2013 06:35:50 -0000 Recapping the discussion so far: - ICE is the way to negotiate between different IP addresses. There seems t= o be no disagreement here. - since no alternative port number can be expressed, in practice the IN add= ress needs to go to the actual configuration (address in the c=3D line and = port number in the m=3D line), and the alternative PSTN address in the pote= ntial configurations. Also here, there seems to be no disagreement. - then, whether the "ccap" attribute should be limited to carry only PSTN a= ddresses, or also other types. I'm with Flemming on this one; SDP capneg fr= amework is already fragmented enough, and limiting the connection address c= apability to PSTN addresses only would again be targeted for a single use c= ase only, whereas we should strive for general solutions.=20 Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Flemming Andreasen Sent: 25. maaliskuuta 2013 3:32 To: Andrew Allen Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (d= raft-ietf-mmusic-sdp-miscellaneous-caps-04) On 3/24/13 1:33 PM, Andrew Allen wrote: > There is also nothing that prevents people from defining their own propri= etary attributes to do such a thing but that is not part of an IETF standar= d and is not approved usage. Agreed. > If we really feel the need to discourage further such usage I suppose we = could add some text stating that if CCAP s received containing an IN net t= ype and an IN net type is present in the corresponding Connection Attribute= then the CCAP attribute MUST be ignored. I think that gets complicated quickly for a questionable gain. I'd=20 prefer the "MUST NOT" described below with an explanation as to why it's=20 there; as you note, ultimately people either decide to be spec compliant=20 or not. -- Flemming > That way compliant implementations would not perfom the discouraged behav= ior. > > Andrew > > ----- Original Message ----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time > To: Christer Holmberg > Cc: Jonathan Lennox ; mmusic@ietf.org > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses = (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 3/23/13 5:24 AM, Christer Holmberg wrote: >> Hi, >> >> In general I agree that having multiple ways of doing the same thing is = not a good thing, and I don't have any strong feelings regarding the ccap u= sage. >> >> But, no matter what we say, what would actually prevent people from usin= g ccap, in the same way they are using ANAT and altc? :) > There's no port signaling capability with ccap, but other than that, the > only thing that prevents people from using this to signal alternative > IP-addresses is the existence of a "MUST NOT" in the spec. > > -- Flemming > >> Regards, >> >> Christer >> >> >> ________________________________________ >> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jon= athan Lennox [jonathan@vidyo.com] >> Sent: Friday, 22 March 2013 10:00 PM >> To: Flemming Andreasen >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addre= sses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> Currently, the deployed SIP world has three mechanisms to allow some fla= vor of negotiation among multiple IP addresses: ICE, altc (despite the gene= ral disapproval of the working group), and ANAT (despite its deprecation). >> >> I think that adding ccap as a fourth member of this set would be a terri= ble idea; and as far as I can tell, no one wants to do that. So we need to= make it clear that that it MUST NOT be used for that purpose. >> >> In the formulation below, I think I'd say that a given media description= MUST NOT indicate more than one address with an IN network type, across al= l its configurations (actual and potential). >> >> Obviously, different media descriptions (m=3D line blocks) can have diff= erent addresses. >> >> In practice, given the port number issue that started this thread, I sus= pect this means that the SDP offer will need to put the IN address in the a= ctual configuration (in the c=3D line), and the PSTN address(es) will be in= the potential configurations. >> >> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >> >>> Still waiting for more comments on this, especially from the people tha= t >>> were very vocal in their complaints previously: Now is the time to spea= k up. >>> >>> Regardless, a few comments on the below: >>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4" >>> addresses in a given SDP. >>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6" >>> addresses in a given SDP. >>> >>> Nit-picking a bit on the actual text, which I think is important: >>> The "ccap" attribute is not what is being to select between different >>> IP-addresses; the use of a "ccap" attribute in a potential configuratio= n >>> ("pcfg") is what is being used for this. Is the restriction that we wan= t >>> here: >>> a) A potential configuration MUST NOT reference more than one "ccap" >>> attribute with a network type of "IN" ? >>> b) All potential configurations for a particular media description MUST >>> NOT reference more than one "ccap" attribute with a network type of "IN= " ? >>> c) Something else ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>> I am OK with either of these proposals >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Beha= lf Of Simo.Veikkolainen@nokia.com >>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>> To: fandreas@cisco.com; mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-address= es (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> I went through the discussion, and my reading is that there is agreeme= nt on not allowing ccap to be used for alternative IP address negotiation. >>>> >>>> That could be made clear in the text e.g. by modifying the second sent= ence Flemming quoted to read: >>>> >>>> >>>> The 'ccap' attribute MUST NOT be used to select >>>> between different IP connection addresses (e.g. between >>>> "IP4" and "IP6" address families or different IP addresses >>>> within the same IP address family). >>>> >>>> >>>> The ccap attribute should be able to carry either an IP or PSTN addres= s; that way either a PSTN or an IP bearer could be offered as the highest p= riority configuration (in the "m=3D" line). However, if we want to clarify= the intended use of ccap, we could modify the first sentence to read: >>>> >>>> >>>> The 'ccap' capability attribute is intended for offering >>>> alternative connection addresses where the >>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>> bearer or a circuit-switched bearer. >>>> >>>> >>>> Simo >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Beha= lf Of ext Flemming Andreasen >>>> Sent: 19. maaliskuuta 2013 8:24 >>>> To: mmusic >>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (= draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> Greetings >>>> >>>> As you may have seen, there has recently been some list discussion on = the "connection data capability" defined in >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>> >>>> To recap, the connection data capability ("ccap") provides capability = negotiation capabilities for what amounts to the "c=3D" line in regular SDP= , and as such enables negotiation of network type (such as "IN") and IP-add= ress information (v4 and v6 addresses). The Standards Track mechanism for n= egotiating and determining alternative IP-address information today is ICE,= and hence the draft currently includes the following wording: >>>> >>>> The 'ccap' capability attribute is intended to >>>> be used only when there is no other mechanism available for >>>> negotiating alternative connection address information, such as = when >>>> the is different among the alternative addresses (e.g. >>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>> situations where an existing mechanism (such as Interactive >>>> Connectivity Establishment (ICE) [RFC5245]) can be used to selec= t >>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>> different IP addresses within the same IP address family). >>>> >>>> >>>> The above text has led to some confusion as to exactly when and what "= ccap" can be used for. More specifically, is it/should it ever be allowed t= o use "ccap" to convey an IP4 or IP6 address, and if so, under what circums= tances ? >>>> >>>> If you have an opinion, please let us know. >>>> >>>> A couple of points to keep in mind: >>>> - The current document has been WGLC'ed without comment ~6 months ago. >>>> - 3GPP has a dependency on the document (however I'm not sure if that = dependency includes the above "IN" feature) >>>> - The connection data capability is defined in a general manner to be = generally useful in line with the overall capability negotiation framework = (as opposed to targeted at one specific use case with one specific value) >>>> - There are scenarios where ICE cannot be used, even if implemented (e= .g. ice-mismatch). >>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence = of ICE support >>>> >>>> >>>> Thanks >>>> >>>> -- 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 >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended reci= pient is prohibited. If you have received this transmission in error, pleas= e immediately reply to the sender and delete this information from your sys= tem. Use, dissemination, distribution, or reproduction of this transmission= by unintended recipients is not authorized and may be unlawful. >>>> . >>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> -- >> Jonathan Lennox >> jonathan@vidyo.com >> >> >> _______________________________________________ >> 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > . > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@siemens-enterprise.com Mon Apr 8 05:15: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 0B2E221F93A5 for ; Mon, 8 Apr 2013 05:15:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od7-pPhLgQmo for ; Mon, 8 Apr 2013 05:15:16 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4FD21F938A for ; Mon, 8 Apr 2013 05:15:16 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A39F91EB844C; Mon, 8 Apr 2013 14:15:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 14:15:15 +0200 From: "Stach, Thomas" To: Emil Ivov , Paul Kyzivat Thread-Topic: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory Thread-Index: AQHOMjFE1g/QYzH9GEOEnVeBGBqJMJjIkryAgAOjdmA= Date: Mon, 8 Apr 2013 12:15:14 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> In-Reply-To: <515FBA77.1030007@jitsi.org> Accept-Language: de-AT, en-US Content-Language: de-DE 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 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory 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, 08 Apr 2013 12:15:18 -0000 I agree, that Paul has a good point. However, I still do not see a requirement for PRACK.=20 I would still like to avoid it due to the big debate during development of = ICE that occurred back in IETF64.=20 Once the UAS has sent the 183 there is an early dialog.=20 Of course the 183 can be lost, such that UAS and UAC are out of sync with r= espect to the dialog state. Now, RFC5245 specifies (in case PRACK is not used) that the provisional res= ponse is retransmitted=20 with the exponential backoff timers. I want to keep this behaviour also for= trickle ICE because now=20 the UAC will eventually receive one of the retransmissions and could also s= end trickled candidates. Interesting is of course what happens with the INFO if the UAC has not yet = received a provisional response. I would expect receipt of a 481 response to the INFO request since the UAC = does not yet know about the dialog. This 481 could trigger at the UAS the immediate retransmission of the provi= sional response=20 in order to establish the early dialog. Then, the INFO could also be retran= smitted.=20 Regards Thomas Emil Ivov wrote: > On 05.04.13, 21:10, Paul Kyzivat wrote: >> Note that until at least one provisional response makes it back to >> the UAC it won't be possible for the UAC to send INFOs. (It can't do >> so until there is an early dialog.) >>=20 >> So its possible that if you only send unreliable provisionals then >> the trickling from UAC to UAS may not be happen until the call is >> established.=20 >=20 > Great point! So it seems like we are back to mandating PRACK. >=20 > What would be the issue with this anyway? >=20 > Emil >=20 >>=20 >> Thanks, >> Paul >>=20 >> On 4/6/13 2:51 AM, Emil Ivov wrote: >>> Hey Thomas, >>>=20 >>> On 05.04.13, 12:04, Stach, Thomas wrote: >>>> inline >>>>=20 >>>> Emil Ivov wrote: >>>>> Hey Marc and thanks for your comments! >>>>>=20 >>>>> Replies inline. >>>>>=20 >>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA256 >>>>>>=20 >>>>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>>>> rfc5245bis draft and I have some suggestions that I will be >>>>>> presenting step by step below: >>>>>>=20 >>>>>> 1. The 180 needs to be reliable >>>>>=20 >>>>> Agreed. We'll make the change in the next revision. >>>>>=20 >>>> The answer with any initial candidates needs to be in a 183 not a >>>> 180.=20 >>>=20 >>> Well 5245 actually talks about 18x but I agree that using 183 rather >>> than 180 would help manage post pick-up latency better. >>>=20 >>>> In addition, I don't think that the 183 needs to be reliable. >>>> This was not necessary for RFC5245 and could also be > avoided for trickle ICE, since the >>>> INFO with the new candidates is already reliably sent. >>>=20 >>> Well, it's not only about the candidates (the 183 could actually >>> contain none of those). However, we'd also need to make sure that >>> things like the ufrag and password are also received. >>>=20 >>>> If the INFO contains always the complete list of > candidates (instead of just a delta), the ICE agents will >>>> eventually have all candidates even if the 183 with the > initial candidates got lost with the initial candidates. >>>> As an optimisation if you don't want to always send the complete >>>> list, you could just include it in the first INFO and use deltas >>>> afterwards.=20 >>>=20 >>> I like this suggestion and I agree we could add something along >>> those lines in case PRACK is not user or supported. >>>=20 >>> Thanks for the tip! >>> Emil >>>>=20 >>>>=20 >>>> Regards >>>> Thomas >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic= From thomas.stach@siemens-enterprise.com Mon Apr 8 05:15: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 831E621F938A for ; Mon, 8 Apr 2013 05:15:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilBJvNo6Qmc6 for ; Mon, 8 Apr 2013 05:15:17 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB021F939F for ; Mon, 8 Apr 2013 05:15:17 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A478B23F0416; Mon, 8 Apr 2013 14:15:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 14:15:16 +0200 From: "Stach, Thomas" To: Emil Ivov Thread-Topic: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - ICE attributes to be sent in INFO Thread-Index: AQHOMi6MYxUfp7s2uUGESuz/vOHpGZjMCehQ Date: Mon, 8 Apr 2013 12:15:16 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> In-Reply-To: <515F1D24.8040703@jitsi.org> Accept-Language: de-AT, en-US Content-Language: de-DE 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 Cc: Marc Petit-Huguenin , "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - ICE attributes to be sent in INFO 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, 08 Apr 2013 12:15:18 -0000 Emil, inline > Hey Thomas, >=20 > On 05.04.13, 12:04, Stach, Thomas wrote: >> inline >>=20 >> Emil Ivov wrote: >>> Hey Marc and thanks for your comments! >>>=20 >>> Replies inline. >>>=20 >>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>>=20 >>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>> rfc5245bis draft and I have some suggestions that I will be >>>> presenting step by step below: >>>>=20 >>>> 1. The 180 needs to be reliable >>>=20 >>> Agreed. We'll make the change in the next revision. >>>=20 >> The answer with any initial candidates needs to be in a 183 not a >> 180.=20 >=20 > Well 5245 actually talks about 18x but I agree that using 183 rather > than 180 would help manage post pick-up latency better. >=20 >> In addition, I don't think that the 183 needs to be reliable. >> This was not necessary for RFC5245 and could also be > avoided for trickle ICE, since the >> INFO with the new candidates is already reliably sent. >=20 > Well, it's not only about the candidates (the 183 could > actually contain > none of those). However, we'd also need to make sure that things like > the ufrag and password are also received. Of course you are right. However, since the INFO can carry arbitrary SDP fragments, you can also inc= lude ufrag and password=20 and any of the other ICE attributes. Regards Thomas >=20 >> If the INFO contains always the complete list of candidates > (instead of just a delta), the ICE agents will >> eventually have all candidates even if the 183 with the > initial candidates got lost with the initial candidates. >> As an optimisation if you don't want to always send the complete >> list, you could just include it in the first INFO and use deltas >> afterwards.=20 >=20 > I like this suggestion and I agree we could add something along those > lines in case PRACK is not user or supported. >=20 > Thanks for the tip! > Emil >>=20 >>=20 >> Regards >> Thomas= From emil@sip-communicator.org Mon Apr 8 15:04: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 BB9F921F8470 for ; Mon, 8 Apr 2013 15:04:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RteN-qPULCHL for ; Mon, 8 Apr 2013 15:04:11 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 784F721F8464 for ; Mon, 8 Apr 2013 15:04:11 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3054689wiw.7 for ; Mon, 08 Apr 2013 15:04:10 -0700 (PDT) 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=C0fM/P0X+GbmTSXTj6YMk1gzXo0q3X/2IeRwg+0pVKE=; b=SVitmzh2lH/Cjy/t++cqRsA8/oCVwntxPJ85lXi/EW0KhOWPVjhYrNCMhOof/Jcydj HyVhBfvgHJeoI9wrKLb/eWQIeDhuQRCVYjzGktR/YEl5PNJiXh3aMPBIEoPw6IsTaqOm 4Ajmo4ObgB/dyQWeobXWDLd0l/qDES/tsGqcNJmzwk/pDsSgu58jrF09+IfK/Yv9ZLII G3LGv1iZhjdo7SefXe7Awzo1YaTtU2dAZMXE8U1P+ArRcbytzGBFbA4oC+e4Kn2o7IdI LTUEPyNh6GC+NAIM0+8+3nK/Hi77yRwWyN0aFAgrImJDOm+RKysJJu4eq+gHjZMqhCxc OQJA== X-Received: by 10.194.121.6 with SMTP id lg6mr382483wjb.22.1365458650580; Mon, 08 Apr 2013 15:04:10 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:6de6:27c6:8e47:6767]) by mx.google.com with ESMTPS id du2sm22305137wib.0.2013.04.08.15.04.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 15:04:09 -0700 (PDT) Message-ID: <51633ED7.4080407@jitsi.org> Date: Tue, 09 Apr 2013 00:04:07 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Stach, Thomas" References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlcHA6jrOAekmoDU/LSXz1t3A+17PSC/l0FRfdBoVmiVGd4k8wz4g+fxm2Ak2gYGFXuySKZ Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory 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, 08 Apr 2013 22:04:12 -0000 Hey Thomas, On 08.04.13, 14:15, Stach, Thomas wrote: > I agree, that Paul has a good point. > However, I still do not see a requirement for PRACK. > I would still like to avoid it due to the big debate during development of ICE that occurred back in IETF64. For those of us who weren't around back then, it would help if you could remind exactly what the reasons were. This way we can decide if they also apply to the trickle ICE case. > Once the UAS has sent the 183 there is an early dialog. > Of course the 183 can be lost, such that UAS and UAC are out of sync with respect to the dialog state. > > Now, RFC5245 specifies (in case PRACK is not used) that the provisional response is retransmitted > with the exponential backoff timers. I want to keep this behaviour also for trickle ICE because now > the UAC will eventually receive one of the retransmissions and could also send trickled candidates. Not necessarily. The UAC may be performing half trickle in which case it won't be sending anything else. > Interesting is of course what happens with the INFO if the UAC has not yet received a provisional response. > I would expect receipt of a 481 response to the INFO request since the UAC does not yet know about the dialog. > This 481 could trigger at the UAS the immediate retransmission of the provisional response > in order to establish the early dialog. Then, the INFO could also be retransmitted. This could indeed work and it could potentially help gain almost up to an RTT. Anyone has a problem with it? > Of course you are right. > However, since the INFO can carry arbitrary SDP fragments, you can also include ufrag and password > and any of the other ICE attributes. I didn't mean to imply you couldn't, however Paul's comment, discussed above, killed this approach anyway. Cheers, Emil > > > Regards > Thomas > > Emil Ivov wrote: >> On 05.04.13, 21:10, Paul Kyzivat wrote: >>> Note that until at least one provisional response makes it back to >>> the UAC it won't be possible for the UAC to send INFOs. (It can't do >>> so until there is an early dialog.) >>> >>> So its possible that if you only send unreliable provisionals then >>> the trickling from UAC to UAS may not be happen until the call is >>> established. >> >> Great point! So it seems like we are back to mandating PRACK. >> >> What would be the issue with this anyway? >> >> Emil >> >>> >>> Thanks, >>> Paul >>> >>> On 4/6/13 2:51 AM, Emil Ivov wrote: >>>> Hey Thomas, >>>> >>>> On 05.04.13, 12:04, Stach, Thomas wrote: >>>>> inline >>>>> >>>>> Emil Ivov wrote: >>>>>> Hey Marc and thanks for your comments! >>>>>> >>>>>> Replies inline. >>>>>> >>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA256 >>>>>>> >>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>>>>> rfc5245bis draft and I have some suggestions that I will be >>>>>>> presenting step by step below: >>>>>>> >>>>>>> 1. The 180 needs to be reliable >>>>>> >>>>>> Agreed. We'll make the change in the next revision. >>>>>> >>>>> The answer with any initial candidates needs to be in a 183 not a >>>>> 180. >>>> >>>> Well 5245 actually talks about 18x but I agree that using 183 rather >>>> than 180 would help manage post pick-up latency better. >>>> >>>>> In addition, I don't think that the 183 needs to be reliable. >>>>> This was not necessary for RFC5245 and could also be >> avoided for trickle ICE, since the >>>>> INFO with the new candidates is already reliably sent. >>>> >>>> Well, it's not only about the candidates (the 183 could actually >>>> contain none of those). However, we'd also need to make sure that >>>> things like the ufrag and password are also received. >>>> >>>>> If the INFO contains always the complete list of >> candidates (instead of just a delta), the ICE agents will >>>>> eventually have all candidates even if the 183 with the >> initial candidates got lost with the initial candidates. >>>>> As an optimisation if you don't want to always send the complete >>>>> list, you could just include it in the first INFO and use deltas >>>>> afterwards. >>>> >>>> I like this suggestion and I agree we could add something along >>>> those lines in case PRACK is not user or supported. >>>> >>>> Thanks for the tip! >>>> Emil >>>>> >>>>> >>>>> Regards >>>>> Thomas >>>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic -- https://jitsi.org From worley@shell01.TheWorld.com Mon Apr 8 16:22: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 4FA8C21F8EBE for ; Mon, 8 Apr 2013 16:22:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcktfFzKDyNk for ; Mon, 8 Apr 2013 16:22:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1F21F8EB2 for ; Mon, 8 Apr 2013 16:22:02 -0700 (PDT) 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 r38NLk4X010264 for ; Mon, 8 Apr 2013 19:21:48 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r38NLkvm2196652 for ; Mon, 8 Apr 2013 19:21:46 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r38NLkV72189030; Mon, 8 Apr 2013 19:21:46 -0400 (EDT) Date: Mon, 8 Apr 2013 19:21:46 -0400 (EDT) Message-Id: <201304082321.r38NLkV72189030@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> (alan.b.johnston@gmail.com) References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> Subject: [MMUSIC] 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: Mon, 08 Apr 2013 23:22:03 -0000 > From: Alan Johnston > > I admit that my first thought was that UPDATE was more appropriate than INFO. > > But the more I think about it, trickling in new candidates is not > necessarily a part of O/A, rather it can be thought of as > communication between two ICE Agents. For tunneling another protocol > using SIP as transport, INFO is the right choice. Ah, yes, I now agree with that -- the trickle-ICE updates are "back channel" amendments to the original offer/answer transfer, not additional offer/answer transactions. Within generic trickle ICE, there is the possibility that additional candidates are provided "incrementally", that is, each protocol message includes only the new candidates (and end-of-candidate indications). There is also the possibility that additional candidates are provided "cumulatively", that is, each protocol message includes all of the previously provided candidates. We could specify that trickle ICE uses one method or the other, but I think that we should consider these to be logically equivalent at the level of generic trickle ICE, and allow the choice between methods to be done by the usage. The reason for this is that the decision of method seems to be heavily dependent on the specifics of the usage. (Allowing each usage to make its own choice requires that we not allow cumulative updates to withdraw candidates previously offered, as that functionality cannot be provided with incremental updates.) For instance, if updates are carried by an ordered, reliable channel like TCP, then there is no benefit in sending updates cumulatively. Similarly if the SIP usage sends updates in UPDATE requests, because the UAC must serialize UPDATE requests. But if we carry updates in INFO messages, and we wish to not require the UAC to serialize them, then cumulative updates are desirable, as out-of-order receipt of INFO messages can cause an earlier-sent INFO to be permanently blocked by a later-sent INFO which reaches the UAS first. This leads to the point that INFO is preferable to UPDATE because the UAC does not have to serialize INFOs, which reduces blocking. (As Paul notes, we've done a lot of work to define how to properly handle complex cases involving UPDATE, but that work is needed because UPDATEs have to be serialized with respect to each other, and with certain other requests.) This leads to a broader issue: Generic trickle ICE needs to define its expectations regarding reliability, correlation, and sequencing of updates. If both generic ICE and its usages were defined in one I-D, these issues would just be design considerations, but since the generic specification and the usage specification are separate, these issues are requirements defined in the generic ICE document and each usage document has to show how it satisfies the requirements. That's hard to do if the requirements aren't explicitly stated. In particular, if cumulative updating is used, and candidates are allowed to be withdrawn, the receiver cannot determine wihch of two updates is "newer" by inspection, updates need to be sequenced by the transport mechanism. If incremental updating is used, sequencing is not relevant. Similarly, if candidates cannot be withdrawn, the newer of two cumulative updates has the larger candidate list. Also, the updates need to be correlated with the "ICE negotiation context", so if there is an ICE restart, any delayed updates for a previous context that arrive can be recognized as such and ignored. For the SIP usage, a considerable amount of sequencing and correlation is provided by the CSeq values: A trickle ICE update INFO must have a CSeq higher than the message containing the offer/answer that started the corresponding ICE context, and will have a CSeq lower than the offer/answer that starts the next ICE context. Similarly, CSeq sequences INFOs. Other usages may need other mechanisms to provide this information. One matter that I haven't seen discussed is how trickle ICE ensures that both UAs always test the same candidate pair at the same time. Even if we assume that the transport of updates is quick and reliable, slight differences in timing at the two UAs could cause them to choose (at some moment) different pairs to test. Since vanilla ICE seems to have been constructed to prevent this, this seems to me that it might be a problem and must be investigated and documented. Dale From thomas.stach@siemens-enterprise.com Tue Apr 9 03:15: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 E638821F93DC for ; Tue, 9 Apr 2013 03:15:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-X4APICJTqQ for ; Tue, 9 Apr 2013 03:15:50 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id A754D21F93AB for ; Tue, 9 Apr 2013 03:15:49 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id AE69C23F044F; Tue, 9 Apr 2013 12:15:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 12:15:48 +0200 From: "Stach, Thomas" To: Emil Ivov Thread-Topic: AW: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory Thread-Index: AQHONKUAuecfKNfWd0Owxkajp9hYoJjNpOHw Date: Tue, 9 Apr 2013 10:15:48 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> <51633ED7.4080407@jitsi.org> In-Reply-To: <51633ED7.4080407@jitsi.org> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory 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, 09 Apr 2013 10:15:51 -0000 Emil, inline > -----Urspr=FCngliche Nachricht----- > Von: Emil Ivov [mailto:emcho@jitsi.org]=20 > Gesendet: Dienstag, 09. April 2013 00:04 > An: Stach, Thomas > Cc: Paul Kyzivat; mmusic@ietf.org > Betreff: Re: AW: [MMUSIC]=20 > draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle- > ice - PRACK not mandatory >=20 > Hey Thomas, >=20 > On 08.04.13, 14:15, Stach, Thomas wrote: > > I agree, that Paul has a good point. > > However, I still do not see a requirement for PRACK.=20 > > I would still like to avoid it due to the big debate during=20 > development of ICE that occurred back in IETF64.=20 >=20 > For those of us who weren't around back then, it would help=20 > if you could > remind exactly what the reasons were. This way we can decide if they > also apply to the trickle ICE case. The main arguments were complexity and lack of implementation.=20 Excerpt from the MMUSIC minutes at http://www.ietf.org/proceedings/64/ The -06 version of ICE solves the race condition noted during the 62nd IETF meeting using a mechanism based on PRACK and UPDATE. There was a heated discussion of this mechanism, with many people complaining that PRACK and UPDATE are complex and difficult to implement, and requesting an alternative ICE formulation which doesn't require them. Others noted that this mechanism was discussed in a previous working group session, and suggested that the complexity argument was overblown. There was no resolution to this discussion in the meeting, and after a review of the issues, an ad-hoc meeting was scheduled to discuss the issues in detail later in the week (notes from the side meeting were sent to the mailing list on 14th November 2005). Which is here --> http://www.ietf.org/mail-archive/web/mmusic/current/msg03= 829.html More on "The Problem with PRACK" is here and the following thread. http://www.ietf.org/mail-archive/web/sip/current/msg13221.html Regards Thomas >=20 > > Once the UAS has sent the 183 there is an early dialog.=20 > > Of course the 183 can be lost, such that UAS and UAC are=20 > out of sync with respect to the dialog state. > >=20 > > Now, RFC5245 specifies (in case PRACK is not used) that the=20 > provisional response is retransmitted=20 > > with the exponential backoff timers. I want to keep this=20 > behaviour also for trickle ICE because now=20 > > the UAC will eventually receive one of the retransmissions=20 > and could also send trickled candidates. >=20 > Not necessarily. The UAC may be performing half trickle in=20 > which case it > won't be sending anything else. >=20 > > Interesting is of course what happens with the INFO if the=20 > UAC has not yet received a provisional response. > > I would expect receipt of a 481 response to the INFO=20 > request since the UAC does not yet know about the dialog. > > This 481 could trigger at the UAS the immediate=20 > retransmission of the provisional response=20 > > in order to establish the early dialog. Then, the INFO=20 > could also be retransmitted. >=20 > This could indeed work and it could potentially help gain almost up to > an RTT. Anyone has a problem with it? >=20 > > Of course you are right. > > However, since the INFO can carry arbitrary SDP fragments,=20 > you can also include ufrag and password=20 > > and any of the other ICE attributes. >=20 > I didn't mean to imply you couldn't, however Paul's comment, discussed > above, killed this approach anyway. >=20 > Cheers, > Emil >=20 > >=20 > >=20 > > Regards > > Thomas > >=20 > > Emil Ivov wrote: > >> On 05.04.13, 21:10, Paul Kyzivat wrote: > >>> Note that until at least one provisional response makes it back to > >>> the UAC it won't be possible for the UAC to send INFOs.=20 > (It can't do > >>> so until there is an early dialog.) > >>> > >>> So its possible that if you only send unreliable provisionals then > >>> the trickling from UAC to UAS may not be happen until the call is > >>> established.=20 > >> > >> Great point! So it seems like we are back to mandating PRACK. > >> > >> What would be the issue with this anyway? > >> > >> Emil > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 4/6/13 2:51 AM, Emil Ivov wrote: > >>>> Hey Thomas, > >>>> > >>>> On 05.04.13, 12:04, Stach, Thomas wrote: > >>>>> inline > >>>>> > >>>>> Emil Ivov wrote: > >>>>>> Hey Marc and thanks for your comments! > >>>>>> > >>>>>> Replies inline. > >>>>>> > >>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>> Hash: SHA256 > >>>>>>> > >>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and > >>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the > >>>>>>> rfc5245bis draft and I have some suggestions that I will be > >>>>>>> presenting step by step below: > >>>>>>> > >>>>>>> 1. The 180 needs to be reliable > >>>>>> > >>>>>> Agreed. We'll make the change in the next revision. > >>>>>> > >>>>> The answer with any initial candidates needs to be in a=20 > 183 not a > >>>>> 180.=20 > >>>> > >>>> Well 5245 actually talks about 18x but I agree that=20 > using 183 rather > >>>> than 180 would help manage post pick-up latency better. > >>>> > >>>>> In addition, I don't think that the 183 needs to be reliable. > >>>>> This was not necessary for RFC5245 and could also be > >> avoided for trickle ICE, since the > >>>>> INFO with the new candidates is already reliably sent. > >>>> > >>>> Well, it's not only about the candidates (the 183 could actually > >>>> contain none of those). However, we'd also need to make sure that > >>>> things like the ufrag and password are also received. > >>>> > >>>>> If the INFO contains always the complete list of > >> candidates (instead of just a delta), the ICE agents will > >>>>> eventually have all candidates even if the 183 with the > >> initial candidates got lost with the initial candidates. > >>>>> As an optimisation if you don't want to always send the complete > >>>>> list, you could just include it in the first INFO and use deltas > >>>>> afterwards.=20 > >>>> > >>>> I like this suggestion and I agree we could add something along > >>>> those lines in case PRACK is not user or supported. > >>>> > >>>> Thanks for the tip! > >>>> Emil > >>>>> > >>>>> > >>>>> Regards > >>>>> Thomas > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic >=20 > --=20 > https://jitsi.org > = From pkyzivat@alum.mit.edu Tue Apr 9 06:28: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 A8F2F21F84E3 for ; Tue, 9 Apr 2013 06:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 jz1EX7BWeu8X for ; Tue, 9 Apr 2013 06:28:52 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1D21F84CD for ; Tue, 9 Apr 2013 06:28:51 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id Mn4m1l0030bG4ec5DpUrUT; Tue, 09 Apr 2013 13:28:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id MpUr1l0063ZTu2S3PpUr1b; Tue, 09 Apr 2013 13:28:51 +0000 Message-ID: <51641792.2050100@alum.mit.edu> Date: Tue, 09 Apr 2013 21:28:50 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Emil Ivov References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> <51633ED7.4080407@jitsi.org> In-Reply-To: <51633ED7.4080407@jitsi.org> 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=1365514131; bh=SPEM4mhuRT3W5IO2earkSRz6I3ID+D3wDIJ81vfWx88=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q0Q/AIQYdhIFnKcwB+R05l68/4akZWoCyogrzGfcetlpVCi9jYmH0MupAY9occyoi 9FmdwPdI+5O1Z9F2g94xID8oN4PtSgtDMqDGKSumpVGD7fpLx96pzMxv31z5G1c6Bi IdhcGIkaq3flRw71FAkH/LIdiE3vLJL1kwN93sCLf362T12oTT5QKtGyeptAfL0Ffo jxCtjBYuNzC/3MDR9HAlKT/p4qhSNZ+3eYs6GI4oAIJ208p3rHf++CR80v/g1EdhZI pdoIS6HR36KChQHMxjaUmBm7ZC8tZ18SW+S8cPrXaQUMPm2ueHba7ZO+9CBIVwDD1g oeaO4TJD+5FQw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory 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, 09 Apr 2013 13:28:52 -0000 On 4/9/13 6:04 AM, Emil Ivov wrote: > Hey Thomas, > > On 08.04.13, 14:15, Stach, Thomas wrote: >> I agree, that Paul has a good point. >> However, I still do not see a requirement for PRACK. >> I would still like to avoid it due to the big debate during development of ICE that occurred back in IETF64. > > For those of us who weren't around back then, it would help if you could > remind exactly what the reasons were. This way we can decide if they > also apply to the trickle ICE case. My argument was that without a reliable provisional the UAS can't be certain that the UAC has established an early dialog, and without that the UAC can't trickle using INFO. Thinking further, *if* the UAS keeps retransmitting the unreliable provisional until it receives some ICE messages then things may work. But in the case of trickle ICE this might effectively mean that it must keep retransmitting until it receives an INFO with additional candidates, because none of the initial candidates may be usable. Thanks, Paul >> Once the UAS has sent the 183 there is an early dialog. >> Of course the 183 can be lost, such that UAS and UAC are out of sync with respect to the dialog state. >> >> Now, RFC5245 specifies (in case PRACK is not used) that the provisional response is retransmitted >> with the exponential backoff timers. I want to keep this behaviour also for trickle ICE because now >> the UAC will eventually receive one of the retransmissions and could also send trickled candidates. > > Not necessarily. The UAC may be performing half trickle in which case it > won't be sending anything else. > >> Interesting is of course what happens with the INFO if the UAC has not yet received a provisional response. >> I would expect receipt of a 481 response to the INFO request since the UAC does not yet know about the dialog. >> This 481 could trigger at the UAS the immediate retransmission of the provisional response >> in order to establish the early dialog. Then, the INFO could also be retransmitted. > > This could indeed work and it could potentially help gain almost up to > an RTT. Anyone has a problem with it? > >> Of course you are right. >> However, since the INFO can carry arbitrary SDP fragments, you can also include ufrag and password >> and any of the other ICE attributes. > > I didn't mean to imply you couldn't, however Paul's comment, discussed > above, killed this approach anyway. > > Cheers, > Emil > >> >> >> Regards >> Thomas >> >> Emil Ivov wrote: >>> On 05.04.13, 21:10, Paul Kyzivat wrote: >>>> Note that until at least one provisional response makes it back to >>>> the UAC it won't be possible for the UAC to send INFOs. (It can't do >>>> so until there is an early dialog.) >>>> >>>> So its possible that if you only send unreliable provisionals then >>>> the trickling from UAC to UAS may not be happen until the call is >>>> established. >>> >>> Great point! So it seems like we are back to mandating PRACK. >>> >>> What would be the issue with this anyway? >>> >>> Emil >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/6/13 2:51 AM, Emil Ivov wrote: >>>>> Hey Thomas, >>>>> >>>>> On 05.04.13, 12:04, Stach, Thomas wrote: >>>>>> inline >>>>>> >>>>>> Emil Ivov wrote: >>>>>>> Hey Marc and thanks for your comments! >>>>>>> >>>>>>> Replies inline. >>>>>>> >>>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA256 >>>>>>>> >>>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and >>>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the >>>>>>>> rfc5245bis draft and I have some suggestions that I will be >>>>>>>> presenting step by step below: >>>>>>>> >>>>>>>> 1. The 180 needs to be reliable >>>>>>> >>>>>>> Agreed. We'll make the change in the next revision. >>>>>>> >>>>>> The answer with any initial candidates needs to be in a 183 not a >>>>>> 180. >>>>> >>>>> Well 5245 actually talks about 18x but I agree that using 183 rather >>>>> than 180 would help manage post pick-up latency better. >>>>> >>>>>> In addition, I don't think that the 183 needs to be reliable. >>>>>> This was not necessary for RFC5245 and could also be >>> avoided for trickle ICE, since the >>>>>> INFO with the new candidates is already reliably sent. >>>>> >>>>> Well, it's not only about the candidates (the 183 could actually >>>>> contain none of those). However, we'd also need to make sure that >>>>> things like the ufrag and password are also received. >>>>> >>>>>> If the INFO contains always the complete list of >>> candidates (instead of just a delta), the ICE agents will >>>>>> eventually have all candidates even if the 183 with the >>> initial candidates got lost with the initial candidates. >>>>>> As an optimisation if you don't want to always send the complete >>>>>> list, you could just include it in the first INFO and use deltas >>>>>> afterwards. >>>>> >>>>> I like this suggestion and I agree we could add something along >>>>> those lines in case PRACK is not user or supported. >>>>> >>>>> Thanks for the tip! >>>>> Emil >>>>>> >>>>>> >>>>>> Regards >>>>>> Thomas >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic > From thomas.stach@siemens-enterprise.com Tue Apr 9 07:17: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 94DA321F9309 for ; Tue, 9 Apr 2013 07:17:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lunfcMsDLzD2 for ; Tue, 9 Apr 2013 07:17:40 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 591C621F9311 for ; Tue, 9 Apr 2013 07:17:38 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3E0E823F046F; Tue, 9 Apr 2013 16:17:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 16:17:38 +0200 From: "Stach, Thomas" To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Trickle ICE Thread-Index: AQHONK/meLB09GO/TUexf6RCKJEGx5jN79kg Date: Tue, 9 Apr 2013 14:17:37 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515D853C.6020107@alum.mit.edu> <515DC02D.7050105@jitsi.org> <99971244-6523-4025-AF84-1AC72D8E0681@gmail.com> <201304082321.r38NLkV72189030@shell01.TheWorld.com> In-Reply-To: <201304082321.r38NLkV72189030@shell01.TheWorld.com> Accept-Language: de-AT, en-US Content-Language: de-DE 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] 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, 09 Apr 2013 14:17:41 -0000 Dale, this is an excellent analysis and I agree completely. Regards Thomas Dale R. Worley wrote: >> From: Alan Johnston >>=20 >> I admit that my first thought was that UPDATE was more appropriate >> than INFO.=20 >>=20 >> But the more I think about it, trickling in new candidates is not >> necessarily a part of O/A, rather it can be thought of as >> communication between two ICE Agents. For tunneling another protocol >> using SIP as transport, INFO is the right choice. >=20 > Ah, yes, I now agree with that -- the trickle-ICE updates are "back > channel" amendments to the original offer/answer transfer, not > additional offer/answer transactions. >=20 > Within generic trickle ICE, there is the possibility that additional > candidates are provided "incrementally", that is, each protocol > message includes only the new candidates (and end-of-candidate > indications). There is also the possibility that additional > candidates are provided "cumulatively", that is, each protocol message > includes all of the previously provided candidates. >=20 > We could specify that trickle ICE uses one method or the other, but I > think that we should consider these to be logically equivalent at the > level of generic trickle ICE, and allow the choice between methods to > be done by the usage. The reason for this is that the decision of > method seems to be heavily dependent on the specifics of the usage. > (Allowing each usage to make its own choice requires that we not allow > cumulative updates to withdraw candidates previously offered, as that > functionality cannot be provided with incremental updates.) >=20 > For instance, if updates are carried by an ordered, reliable channel > like TCP, then there is no benefit in sending updates cumulatively. > Similarly if the SIP usage sends updates in UPDATE requests, because > the UAC must serialize UPDATE requests. But if we carry updates in > INFO messages, and we wish to not require the UAC to serialize them, > then cumulative updates are desirable, as out-of-order receipt of INFO > messages can cause an earlier-sent INFO to be permanently blocked by a > later-sent INFO which reaches the UAS first. >=20 > This leads to the point that INFO is preferable to UPDATE because the > UAC does not have to serialize INFOs, which reduces blocking. (As > Paul notes, we've done a lot of work to define how to properly handle > complex cases involving UPDATE, but that work is needed because > UPDATEs have to be serialized with respect to each other, and with > certain other requests.)=20 >=20 > This leads to a broader issue: Generic trickle ICE needs to define > its expectations regarding reliability, correlation, and sequencing of > updates. If both generic ICE and its usages were defined in one I-D, > these issues would just be design considerations, but since the > generic specification and the usage specification are separate, these > issues are requirements defined in the generic ICE document and each > usage document has to show how it satisfies the requirements. That's > hard to do if the requirements aren't explicitly stated. >=20 > In particular, if cumulative updating is used, and candidates are > allowed to be withdrawn, the receiver cannot determine wihch of two > updates is "newer" by inspection, updates need to be sequenced by the > transport mechanism. If incremental updating is used, sequencing is > not relevant. Similarly, if candidates cannot be withdrawn, the newer > of two cumulative updates has the larger candidate list. >=20 > Also, the updates need to be correlated with the "ICE negotiation > context", so if there is an ICE restart, any delayed updates for a > previous context that arrive can be recognized as such and ignored. >=20 > For the SIP usage, a considerable amount of sequencing and correlation > is provided by the CSeq values: A trickle ICE update INFO must have a > CSeq higher than the message containing the offer/answer that started > the corresponding ICE context, and will have a CSeq lower than the > offer/answer that starts the next ICE context. Similarly, CSeq > sequences INFOs.=20 >=20 > Other usages may need other mechanisms to provide this information. >=20 > One matter that I haven't seen discussed is how trickle ICE ensures > that both UAs always test the same candidate pair at the same time. > Even if we assume that the transport of updates is quick and reliable, > slight differences in timing at the two UAs could cause them to choose > (at some moment) different pairs to test. Since vanilla ICE seems to > have been constructed to prevent this, this seems to me that it might > be a problem and must be investigated and documented. >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic= From worley@shell01.TheWorld.com Tue Apr 9 08:40: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 B6CA521F9733 for ; Tue, 9 Apr 2013 08:40:09 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drB5wm4fN2wV for ; Tue, 9 Apr 2013 08:40:03 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A301621F972F for ; Tue, 9 Apr 2013 08:40:03 -0700 (PDT) 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 r39Fdk7i010379 for ; Tue, 9 Apr 2013 11:39:50 -0400 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 r39Fdkf52244693 for ; Tue, 9 Apr 2013 11:39:46 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r39FdjqJ2253833; Tue, 9 Apr 2013 11:39:45 -0400 (EDT) Date: Tue, 9 Apr 2013 11:39:45 -0400 (EDT) Message-Id: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 09 Apr 2013 15:40:11 -0000 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. Comments? Dale From pkyzivat@alum.mit.edu Tue Apr 9 12:06: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 27B1921F91D4 for ; Tue, 9 Apr 2013 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 xZTEgZfU2L6q for ; Tue, 9 Apr 2013 12:06:47 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7968821F91CF for ; Tue, 9 Apr 2013 12:06:47 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id MnMk1l00316LCl059v6mMa; Tue, 09 Apr 2013 19:06:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id Mv6m1l00m3ZTu2S3Sv6mS5; Tue, 09 Apr 2013 19:06:46 +0000 Message-ID: <516466C5.1070201@alum.mit.edu> Date: Wed, 10 Apr 2013 03:06:45 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> In-Reply-To: <201304091539.r39FdjqJ2253833@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=1365534406; bh=sJlL6zyH/8e/8f7lLrFUIlKrT9W/Kk7uS2Qv2CUCzd4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aVHZk9q8EmUobLCBWwnce8nl8uRb7oMKic0fTCRLa/ict8ZdjIcTPoxFeO05pjiBn yudRnlOf7jB55kaN5V6ELy7MqGMPQ9mCeb3V1yjWjhL9aCEXVc+jfRtjrVyV8J1VS6 Shfj8g0NjgDJ6CeMvE9OdOeeOSEu548z1qeU2rl+k14qe1UBld9mXs1gfxFTA0kk4o tPhSCklmNlSBLDRghAIByq6GjAZeQ8tMIjBRObxwXJM568hA903OcrFjFyeBX9ZCB3 zOGvRAduvGDMy6q13j95OuwtbMB9wFV3TNlGKADuOmAPC8dnhWwvBwwndan5y21puq 10dAHdn31OC/Q== Subject: [MMUSIC] "splitting" 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: Tue, 09 Apr 2013 19:06:48 -0000 I'd like to add to the cases that Dale lists below. This has come up in CLUE, and pertains to cases where not all media processing equipment is at the same address. In such cases bundling may be supported, but more than one bundle may be required. When this happens on the offering end the offerer can propose multiple bundles from the beginning. But when it is the answerer that needs things in separate bundles then it will need to "split" (partition) the offered bundle into multiple bundles. You can view this as a variant of (1)+(3) below. Conceptually this isn't complex. But given the o/a rules in the grouping framework I don't think it ca be achieved in the answer to the offer that proposes a single bundle. It could be accomplished by: - process the first answer in accord with (1) below - accepting the m-lines that can go into one bundle, and rejecting (port=0) the others. - send a 2nd offer, with one bundle including the previously accepted m-lines, and a separate bundle for the previously rejected m-lines. Since mutual support of bundle is now presumed, this 2nd offer can use a single addr/port, and a single set of ice candidates, for all the m-lines in each bundle. Thanks, Paul On 4/9/13 11:39 PM, Dale R. Worley wrote: > 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. > > Comments? > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From thomas.stach@siemens-enterprise.com Wed Apr 10 00:18: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 9B2C321F8FC6 for ; Wed, 10 Apr 2013 00:18:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnm7EY2M0BZm for ; Wed, 10 Apr 2013 00:18:47 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF521F8FA5 for ; Wed, 10 Apr 2013 00:18:47 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 976CF23F0491; Wed, 10 Apr 2013 09:18:46 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 09:18:46 +0200 From: "Stach, Thomas" To: Paul Kyzivat , Emil Ivov Thread-Topic: AW: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory Thread-Index: AQHONSYruecfKNfWd0Owxkajp9hYoJjPC6zA Date: Wed, 10 Apr 2013 07:18:45 +0000 Message-ID: References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> <51633ED7.4080407@jitsi.org> <51641792.2050100@alum.mit.edu> In-Reply-To: <51641792.2050100@alum.mit.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory 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, 10 Apr 2013 07:18:48 -0000 inline > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Gesendet: Dienstag, 09. April 2013 15:29 > An: Emil Ivov > Cc: Stach, Thomas; mmusic@ietf.org > Betreff: Re: AW: [MMUSIC]=20 > draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle- > ice - PRACK not mandatory >=20 > On 4/9/13 6:04 AM, Emil Ivov wrote: > > Hey Thomas, > > > > On 08.04.13, 14:15, Stach, Thomas wrote: > >> I agree, that Paul has a good point. > >> However, I still do not see a requirement for PRACK. > >> I would still like to avoid it due to the big debate=20 > during development of ICE that occurred back in IETF64. > > > > For those of us who weren't around back then, it would help=20 > if you could > > remind exactly what the reasons were. This way we can decide if they > > also apply to the trickle ICE case. >=20 > My argument was that without a reliable provisional the UAS can't be=20 > certain that the UAC has established an early dialog, and=20 > without that=20 > the UAC can't trickle using INFO. >=20 > Thinking further, *if* the UAS keeps retransmitting the unreliable=20 > provisional until it receives some ICE messages then things may work.=20 > But in the case of trickle ICE this might effectively mean=20 > that it must=20 > keep retransmitting until it receives an INFO with additional=20 > candidates,=20 ... or if the UAS receives a 200 OK (instead of 481) for an INFO request.=20 That would also indicate that the 18X was received and the early dialog was= established. Regards Thomas > because none of the initial candidates may be usable. >=20 > Thanks, > Paul >=20 > >> Once the UAS has sent the 183 there is an early dialog. > >> Of course the 183 can be lost, such that UAS and UAC are=20 > out of sync with respect to the dialog state. > >> > >> Now, RFC5245 specifies (in case PRACK is not used) that=20 > the provisional response is retransmitted > >> with the exponential backoff timers. I want to keep this=20 > behaviour also for trickle ICE because now > >> the UAC will eventually receive one of the retransmissions=20 > and could also send trickled candidates. > > > > Not necessarily. The UAC may be performing half trickle in=20 > which case it > > won't be sending anything else. > > > >> Interesting is of course what happens with the INFO if the=20 > UAC has not yet received a provisional response. > >> I would expect receipt of a 481 response to the INFO=20 > request since the UAC does not yet know about the dialog. > >> This 481 could trigger at the UAS the immediate=20 > retransmission of the provisional response > >> in order to establish the early dialog. Then, the INFO=20 > could also be retransmitted. > > > > This could indeed work and it could potentially help gain=20 > almost up to > > an RTT. Anyone has a problem with it? > > > >> Of course you are right. > >> However, since the INFO can carry arbitrary SDP fragments,=20 > you can also include ufrag and password > >> and any of the other ICE attributes. > > > > I didn't mean to imply you couldn't, however Paul's=20 > comment, discussed > > above, killed this approach anyway. > > > > Cheers, > > Emil > > > >> > >> > >> Regards > >> Thomas > >> > >> Emil Ivov wrote: > >>> On 05.04.13, 21:10, Paul Kyzivat wrote: > >>>> Note that until at least one provisional response makes=20 > it back to > >>>> the UAC it won't be possible for the UAC to send INFOs.=20 > (It can't do > >>>> so until there is an early dialog.) > >>>> > >>>> So its possible that if you only send unreliable=20 > provisionals then > >>>> the trickling from UAC to UAS may not be happen until the call is > >>>> established. > >>> > >>> Great point! So it seems like we are back to mandating PRACK. > >>> > >>> What would be the issue with this anyway? > >>> > >>> Emil > >>> > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 4/6/13 2:51 AM, Emil Ivov wrote: > >>>>> Hey Thomas, > >>>>> > >>>>> On 05.04.13, 12:04, Stach, Thomas wrote: > >>>>>> inline > >>>>>> > >>>>>> Emil Ivov wrote: > >>>>>>> Hey Marc and thanks for your comments! > >>>>>>> > >>>>>>> Replies inline. > >>>>>>> > >>>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: > >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>> Hash: SHA256 > >>>>>>>> > >>>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and > >>>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the > >>>>>>>> rfc5245bis draft and I have some suggestions that I will be > >>>>>>>> presenting step by step below: > >>>>>>>> > >>>>>>>> 1. The 180 needs to be reliable > >>>>>>> > >>>>>>> Agreed. We'll make the change in the next revision. > >>>>>>> > >>>>>> The answer with any initial candidates needs to be in=20 > a 183 not a > >>>>>> 180. > >>>>> > >>>>> Well 5245 actually talks about 18x but I agree that=20 > using 183 rather > >>>>> than 180 would help manage post pick-up latency better. > >>>>> > >>>>>> In addition, I don't think that the 183 needs to be reliable. > >>>>>> This was not necessary for RFC5245 and could also be > >>> avoided for trickle ICE, since the > >>>>>> INFO with the new candidates is already reliably sent. > >>>>> > >>>>> Well, it's not only about the candidates (the 183 could actually > >>>>> contain none of those). However, we'd also need to make=20 > sure that > >>>>> things like the ufrag and password are also received. > >>>>> > >>>>>> If the INFO contains always the complete list of > >>> candidates (instead of just a delta), the ICE agents will > >>>>>> eventually have all candidates even if the 183 with the > >>> initial candidates got lost with the initial candidates. > >>>>>> As an optimisation if you don't want to always send=20 > the complete > >>>>>> list, you could just include it in the first INFO and=20 > use deltas > >>>>>> afterwards. > >>>>> > >>>>> I like this suggestion and I agree we could add something along > >>>>> those lines in case PRACK is not user or supported. > >>>>> > >>>>> Thanks for the tip! > >>>>> Emil > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> Thomas > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > = From fandreas@cisco.com Wed Apr 10 12:30: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 BF2FE21F9019 for ; Wed, 10 Apr 2013 12:30:13 -0700 (PDT) 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_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 pwPfbvOyReph for ; Wed, 10 Apr 2013 12:30:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 684FD21F8FFC for ; Wed, 10 Apr 2013 12:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12793; q=dns/txt; s=iport; t=1365622212; x=1366831812; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FyOwD0blS4/bqlEnt4xDSqutSGYtpwWY3gQclZFnP0Y=; b=XrteH5qb6rTVzmXZmua64PnEMSXaVXY3lkp4O0mrpLi9wZnUI5+zYy+j o7Ej1xa3eVZ7sz0J+f9+CUWQv8Mzo/g8/uLQEqkgjVAIQUXFm5QJ+5Ixr BRp8BifaeihAtn6nuNnN2l6oyYUgr5HqMnFBbFMzNjT5ntsDpvZu5yhuP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAKK8ZVGtJXG8/2dsb2JhbABQgwY2wUCBEBZ0gh8BAQEDAQEBATU0AggCAQUHBAsRBAEBAQkWBAQHCQMCAQIBFR8JCBMBBQIBAQUSh3MGDL87jV4GgScLBwaDOwOXAJEOgVWBUiCBLgkX X-IronPort-AV: E=Sophos;i="4.87,449,1363132800"; d="scan'208";a="197317279" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 10 Apr 2013 19:30:11 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3AJUAxQ017663; Wed, 10 Apr 2013 19:30:10 GMT Message-ID: <5165BDC2.6090701@cisco.com> Date: Wed, 10 Apr 2013 15:30:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <514FA8F7.7060203@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 10 Apr 2013 19:30:13 -0000 On 4/8/13 2:35 AM, Simo.Veikkolainen@nokia.com wrote: > Recapping the discussion so far: > > > - ICE is the way to negotiate between different IP addresses. There seems to be no disagreement here. > > - since no alternative port number can be expressed, in practice the IN address needs to go to the actual configuration (address in the c= line and port number in the m= line), and the alternative PSTN address in the potential configurations. Also here, there seems to be no disagreement. > > - then, whether the "ccap" attribute should be limited to carry only PSTN addresses, or also other types. I'm with Flemming on this one; SDP capneg framework is already fragmented enough, and limiting the connection address capability to PSTN addresses only would again be targeted for a single use case only, whereas we should strive for general solutions. Agree with you. Any other comments from anybody ? If we do not hear otherwise from anybody by the end of this week, we will proceed according to the above. Thanks -- Flemming (MMUSIC co-chair) > Simo > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen > Sent: 25. maaliskuuta 2013 3:32 > To: Andrew Allen > Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 3/24/13 1:33 PM, Andrew Allen wrote: >> There is also nothing that prevents people from defining their own proprietary attributes to do such a thing but that is not part of an IETF standard and is not approved usage. > Agreed. > >> If we really feel the need to discourage further such usage I suppose we could add some text stating that if CCAP s received containing an IN net type and an IN net type is present in the corresponding Connection Attribute then the CCAP attribute MUST be ignored. > I think that gets complicated quickly for a questionable gain. I'd > prefer the "MUST NOT" described below with an explanation as to why it's > there; as you note, ultimately people either decide to be spec compliant > or not. > > -- Flemming >> That way compliant implementations would not perfom the discouraged behavior. >> >> Andrew >> >> ----- Original Message ----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >> To: Christer Holmberg >> Cc: Jonathan Lennox ; mmusic@ietf.org >> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>> Hi, >>> >>> In general I agree that having multiple ways of doing the same thing is not a good thing, and I don't have any strong feelings regarding the ccap usage. >>> >>> But, no matter what we say, what would actually prevent people from using ccap, in the same way they are using ANAT and altc? :) >> There's no port signaling capability with ccap, but other than that, the >> only thing that prevents people from using this to signal alternative >> IP-addresses is the existence of a "MUST NOT" in the spec. >> >> -- Flemming >> >>> Regards, >>> >>> Christer >>> >>> >>> ________________________________________ >>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Jonathan Lennox [jonathan@vidyo.com] >>> Sent: Friday, 22 March 2013 10:00 PM >>> To: Flemming Andreasen >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> Currently, the deployed SIP world has three mechanisms to allow some flavor of negotiation among multiple IP addresses: ICE, altc (despite the general disapproval of the working group), and ANAT (despite its deprecation). >>> >>> I think that adding ccap as a fourth member of this set would be a terrible idea; and as far as I can tell, no one wants to do that. So we need to make it clear that that it MUST NOT be used for that purpose. >>> >>> In the formulation below, I think I'd say that a given media description MUST NOT indicate more than one address with an IN network type, across all its configurations (actual and potential). >>> >>> Obviously, different media descriptions (m= line blocks) can have different addresses. >>> >>> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations. >>> >>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>> >>>> Still waiting for more comments on this, especially from the people that >>>> were very vocal in their complaints previously: Now is the time to speak up. >>>> >>>> Regardless, a few comments on the below: >>>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4" >>>> addresses in a given SDP. >>>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6" >>>> addresses in a given SDP. >>>> >>>> Nit-picking a bit on the actual text, which I think is important: >>>> The "ccap" attribute is not what is being to select between different >>>> IP-addresses; the use of a "ccap" attribute in a potential configuration >>>> ("pcfg") is what is being used for this. Is the restriction that we want >>>> here: >>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>> attribute with a network type of "IN" ? >>>> b) All potential configurations for a particular media description MUST >>>> NOT reference more than one "ccap" attribute with a network type of "IN" ? >>>> c) Something else ? >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> >>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>> I am OK with either of these proposals >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Simo.Veikkolainen@nokia.com >>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation. >>>>> >>>>> That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read: >>>>> >>>>> >>>>> The 'ccap' attribute MUST NOT be used to select >>>>> between different IP connection addresses (e.g. between >>>>> "IP4" and "IP6" address families or different IP addresses >>>>> within the same IP address family). >>>>> >>>>> >>>>> The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line). However, if we want to clarify the intended use of ccap, we could modify the first sentence to read: >>>>> >>>>> >>>>> The 'ccap' capability attribute is intended for offering >>>>> alternative connection addresses where the >>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>> bearer or a circuit-switched bearer. >>>>> >>>>> >>>>> Simo >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen >>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>> To: mmusic >>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Greetings >>>>> >>>>> As you may have seen, there has recently been some list discussion on the "connection data capability" defined in >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>>> >>>>> To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording: >>>>> >>>>> The 'ccap' capability attribute is intended to >>>>> be used only when there is no other mechanism available for >>>>> negotiating alternative connection address information, such as when >>>>> the is different among the alternative addresses (e.g. >>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>> situations where an existing mechanism (such as Interactive >>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to select >>>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>>> different IP addresses within the same IP address family). >>>>> >>>>> >>>>> The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ? >>>>> >>>>> If you have an opinion, please let us know. >>>>> >>>>> A couple of points to keep in mind: >>>>> - The current document has been WGLC'ed without comment ~6 months ago. >>>>> - 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature) >>>>> - The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value) >>>>> - There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch). >>>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support >>>>> >>>>> >>>>> Thanks >>>>> >>>>> -- 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 >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>> . >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> -- >>> Jonathan Lennox >>> jonathan@vidyo.com >>> >>> >>> _______________________________________________ >>> 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 >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> . >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From worley@shell01.TheWorld.com Thu Apr 11 16:08: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 8BE7C21F89D8 for ; Thu, 11 Apr 2013 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 Gx9Y+R6uAa24 for ; Thu, 11 Apr 2013 16:08:04 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A93E221F89A6 for ; Thu, 11 Apr 2013 16:08:02 -0700 (PDT) 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 r3BN74Ph003427 for ; Thu, 11 Apr 2013 19:07:06 -0400 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 r3BN72mE2402802 for ; Thu, 11 Apr 2013 19:07:04 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3BN72Gq2404864; Thu, 11 Apr 2013 19:07:02 -0400 (EDT) Date: Thu, 11 Apr 2013 19:07:02 -0400 (EDT) Message-Id: <201304112307.r3BN72Gq2404864@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 11 Apr 2013 23:08:07 -0000 DES F10 When an offer is constructed, the offerer must not need to preallocate 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. Comments? Dale From worley@shell01.TheWorld.com Thu Apr 11 16:08: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 1FD7121F899E for ; Thu, 11 Apr 2013 16:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 jopg338hH4jb for ; Thu, 11 Apr 2013 16:08:07 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A975421F89B0 for ; Thu, 11 Apr 2013 16:08:02 -0700 (PDT) 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 r3BN7lSl004972; Thu, 11 Apr 2013 19:07:49 -0400 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 r3BN7kJM2399862; Thu, 11 Apr 2013 19:07:46 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3BN7kZK2397616; Thu, 11 Apr 2013 19:07:46 -0400 (EDT) Date: Thu, 11 Apr 2013 19:07:46 -0400 (EDT) Message-Id: <201304112307.r3BN7kZK2397616@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <516466C5.1070201@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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: Thu, 11 Apr 2013 23:08:08 -0000 > From: Paul Kyzivat > > This has come up in CLUE, and pertains to cases where not all media > processing equipment is at the same address. In such cases bundling may > be supported, but more than one bundle may be required. > > When this happens on the offering end the offerer can propose multiple > bundles from the beginning. But when it is the answerer that needs > things in separate bundles then it will need to "split" (partition) the > offered bundle into multiple bundles. You can view this as a variant of > (1)+(3) below. There's a lot of complexity in that case. In a situation where the offerer can predict what partitions might be desired, you could use hierarchical bundling. E.g., in the solution proposed in http://www.ietf.org/mail-archive/web/mmusic/current/msg10516.html, the audio m= lines were put into one bundle and the video m= lines were put into another bundle, and then the two bundles were put into one large bundle. That allows the answerer to use one transport association for all media, or two transport associations (one for each media type) so that they can have different QoS. In CLUE situations, this might not work well, because the real grouping is based on physical origin of the traffic, and one end can't guess the physical configuration of the other end. Another approach would be to have the grouping that marks the bundle to be independent of which application-level flows are grouped with which. So one a=group:BUNDLE attribute just marks a bunch of m= lines as being available for bundling, and each end provides the address/ports for each m= line, which imply which m= lines are bundled together. That leads to the possibility that the bundling could be *different* at each end of the connection. E.g., at UA1, m= lines 1 and 2 could use one port and m= lines 3 and 4 could use another port, while at UA2, m= lines 1 and 3 use the same port and m= lines 2 and 4 use the same port. That isn't as insane as it sounds, if UA1 controls two cameras at different addresses, each of which generates an audio and a video stream, whereas UA2 controls an audio system (at one address) and a video display (at another address). The multiplexing and demultiplexing works OK, but getting UA1 and UA2 to coordinate everything is messy. Thinking about these possibilities, it seems like Paul's proposal is the simplest: > Conceptually this isn't complex. But given the o/a rules in the grouping > framework I don't think it ca be achieved in the answer to the offer > that proposes a single bundle. It could be accomplished by: > > - process the first answer in accord with (1) below - accepting the > m-lines that can go into one bundle, and rejecting (port=0) the > others. > > - send a 2nd offer, with one bundle including the previously accepted > m-lines, and a separate bundle for the previously rejected m-lines. > Since mutual support of bundle is now presumed, this 2nd offer can > use a single addr/port, and a single set of ice candidates, for > all the m-lines in each bundle. Of course, that does require that the bundling proposed in a later offer doesn't have to closely match the bundling proposed in an earlier offer in the O/A sequence. That depends on the rules we write regarding dependencies between successive offers/answers in an O/A sequence, which we haven't written. But at this point, I think that those rules will be extremely loose, not because that's the conceptually clean solution but because it would be difficult to write strict rules that could be implemented reliably. Dale From mohamed.boucadair@orange.com Fri Apr 12 08:39: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 B408721F8E66 for ; Fri, 12 Apr 2013 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=0.001] 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 TpoQh-xruInb for ; Fri, 12 Apr 2013 08:39:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47421F8A91 for ; Fri, 12 Apr 2013 08:39:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id F2869264206; Fri, 12 Apr 2013 17:39:05 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CF7AA238048; Fri, 12 Apr 2013 17:39:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 12 Apr 2013 17:39:05 +0200 From: To: "Simo.Veikkolainen@nokia.com" , "fandreas@cisco.com" , "aallen@blackberry.com" , "HKaplan@acmepacket.com" Date: Fri, 12 Apr 2013 17:39:04 +0200 Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: AQHOKPiD6pdLNgC57ki9NhYvjILwhZjL7uuAgAbl+5A= Message-ID: <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> References: <514FA8F7.7060203@cisco.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 12 Apr 2013 15:39:08 -0000 Hi Simo, I'm in favor of restricting the alternative address to PSTN. This is cohere= nt whit your first bullet below. If you share the text changes you are proposing, this would be more easier = to review. Thanks for taking care of this issue. Cheers, Med >-----Message d'origine----- >De=A0: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part= de >Simo.Veikkolainen@nokia.com >Envoy=E9=A0: lundi 8 avril 2013 08:35 >=C0=A0: fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.com >Cc=A0: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >Objet=A0: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >(draft-ietf-mmusic-sdp-miscellaneous-caps-04) > >Recapping the discussion so far: > > >- ICE is the way to negotiate between different IP addresses. There seems >to be no disagreement here. > >- since no alternative port number can be expressed, in practice the IN >address needs to go to the actual configuration (address in the c=3D line = and >port number in the m=3D line), and the alternative PSTN address in the >potential configurations. Also here, there seems to be no disagreement. > >- then, whether the "ccap" attribute should be limited to carry only PSTN >addresses, or also other types. I'm with Flemming on this one; SDP capneg >framework is already fragmented enough, and limiting the connection addres= s >capability to PSTN addresses only would again be targeted for a single use >case only, whereas we should strive for general solutions. > >Simo > > >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f >ext Flemming Andreasen >Sent: 25. maaliskuuta 2013 3:32 >To: Andrew Allen >Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >(draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > >On 3/24/13 1:33 PM, Andrew Allen wrote: >> There is also nothing that prevents people from defining their own >proprietary attributes to do such a thing but that is not part of an IETF >standard and is not approved usage. >Agreed. > >> If we really feel the need to discourage further such usage I suppose we >could add some text stating that if CCAP s received containing an IN net >type and an IN net type is present in the corresponding Connection >Attribute then the CCAP attribute MUST be ignored. >I think that gets complicated quickly for a questionable gain. I'd >prefer the "MUST NOT" described below with an explanation as to why it's >there; as you note, ultimately people either decide to be spec compliant >or not. > >-- Flemming >> That way compliant implementations would not perfom the discouraged >behavior. >> >> Andrew >> >> ----- Original Message ----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >> To: Christer Holmberg >> Cc: Jonathan Lennox ; mmusic@ietf.org > >> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>> Hi, >>> >>> In general I agree that having multiple ways of doing the same thing is >not a good thing, and I don't have any strong feelings regarding the ccap >usage. >>> >>> But, no matter what we say, what would actually prevent people from >using ccap, in the same way they are using ANAT and altc? :) >> There's no port signaling capability with ccap, but other than that, the >> only thing that prevents people from using this to signal alternative >> IP-addresses is the existence of a "MUST NOT" in the spec. >> >> -- Flemming >> >>> Regards, >>> >>> Christer >>> >>> >>> ________________________________________ >>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of >Jonathan Lennox [jonathan@vidyo.com] >>> Sent: Friday, 22 March 2013 10:00 PM >>> To: Flemming Andreasen >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> Currently, the deployed SIP world has three mechanisms to allow some >flavor of negotiation among multiple IP addresses: ICE, altc (despite the >general disapproval of the working group), and ANAT (despite its >deprecation). >>> >>> I think that adding ccap as a fourth member of this set would be a >terrible idea; and as far as I can tell, no one wants to do that. So we >need to make it clear that that it MUST NOT be used for that purpose. >>> >>> In the formulation below, I think I'd say that a given media descriptio= n >MUST NOT indicate more than one address with an IN network type, across al= l >its configurations (actual and potential). >>> >>> Obviously, different media descriptions (m=3D line blocks) can have >different addresses. >>> >>> In practice, given the port number issue that started this thread, I >suspect this means that the SDP offer will need to put the IN address in >the actual configuration (in the c=3D line), and the PSTN address(es) will= be >in the potential configurations. >>> >>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>> >>>> Still waiting for more comments on this, especially from the people >that >>>> were very vocal in their complaints previously: Now is the time to >speak up. >>>> >>>> Regardless, a few comments on the below: >>>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4= " >>>> addresses in a given SDP. >>>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6= " >>>> addresses in a given SDP. >>>> >>>> Nit-picking a bit on the actual text, which I think is important: >>>> The "ccap" attribute is not what is being to select between different >>>> IP-addresses; the use of a "ccap" attribute in a potential >configuration >>>> ("pcfg") is what is being used for this. Is the restriction that we >want >>>> here: >>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>> attribute with a network type of "IN" ? >>>> b) All potential configurations for a particular media description MUS= T >>>> NOT reference more than one "ccap" attribute with a network type of >"IN" ? >>>> c) Something else ? >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> >>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>> I am OK with either of these proposals >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >Behalf Of Simo.Veikkolainen@nokia.com >>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> I went through the discussion, and my reading is that there is >agreement on not allowing ccap to be used for alternative IP address >negotiation. >>>>> >>>>> That could be made clear in the text e.g. by modifying the second >sentence Flemming quoted to read: >>>>> >>>>> >>>>> The 'ccap' attribute MUST NOT be used to select >>>>> between different IP connection addresses (e.g. between >>>>> "IP4" and "IP6" address families or different IP addresses >>>>> within the same IP address family). >>>>> >>>>> >>>>> The ccap attribute should be able to carry either an IP or PSTN >address; that way either a PSTN or an IP bearer could be offered as the >highest priority configuration (in the "m=3D" line). However, if we want = to >clarify the intended use of ccap, we could modify the first sentence to >read: >>>>> >>>>> >>>>> The 'ccap' capability attribute is intended for offering >>>>> alternative connection addresses where the >>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>> bearer or a circuit-switched bearer. >>>>> >>>>> >>>>> Simo >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >Behalf Of ext Flemming Andreasen >>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>> To: mmusic >>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >(draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Greetings >>>>> >>>>> As you may have seen, there has recently been some list discussion on >the "connection data capability" defined in >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>>> >>>>> To recap, the connection data capability ("ccap") provides capability >negotiation capabilities for what amounts to the "c=3D" line in regular SD= P, >and as such enables negotiation of network type (such as "IN") and IP- >address information (v4 and v6 addresses). The Standards Track mechanism >for negotiating and determining alternative IP-address information today i= s >ICE, and hence the draft currently includes the following wording: >>>>> >>>>> The 'ccap' capability attribute is intended to >>>>> be used only when there is no other mechanism available for >>>>> negotiating alternative connection address information, such as >when >>>>> the is different among the alternative addresses (e.g= . >>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>> situations where an existing mechanism (such as Interactive >>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to >select >>>>> between different connection addresses (e.g. "IP4" and "IP6" o= r >>>>> different IP addresses within the same IP address family). >>>>> >>>>> >>>>> The above text has led to some confusion as to exactly when and what >"ccap" can be used for. More specifically, is it/should it ever be allowed >to use "ccap" to convey an IP4 or IP6 address, and if so, under what >circumstances ? >>>>> >>>>> If you have an opinion, please let us know. >>>>> >>>>> A couple of points to keep in mind: >>>>> - The current document has been WGLC'ed without comment ~6 months ago= . >>>>> - 3GPP has a dependency on the document (however I'm not sure if that >dependency includes the above "IN" feature) >>>>> - The connection data capability is defined in a general manner to be >generally useful in line with the overall capability negotiation framework >(as opposed to targeted at one specific use case with one specific value) >>>>> - There are scenarios where ICE cannot be used, even if implemented >(e.g. ice-mismatch). >>>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence >of ICE support >>>>> >>>>> >>>>> Thanks >>>>> >>>>> -- 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 >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidentia= l >information, privileged material (including material protected by the >solicitor-client or other applicable privileges), or constitute non-public >information. Any use of this information by anyone other than the intended >recipient is prohibited. If you have received this transmission in error, >please immediately reply to the sender and delete this information from >your system. Use, dissemination, distribution, or reproduction of this >transmission by unintended recipients is not authorized and may be >unlawful. >>>>> . >>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> -- >>> Jonathan Lennox >>> jonathan@vidyo.com >>> >>> >>> _______________________________________________ >>> 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 >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >information, privileged material (including material protected by the >solicitor-client or other applicable privileges), or constitute non-public >information. Any use of this information by anyone other than the intended >recipient is prohibited. If you have received this transmission in error, >please immediately reply to the sender and delete this information from >your system. Use, dissemination, distribution, or reproduction of this >transmission by unintended recipients is not authorized and may be >unlawful. >> . >> > >_______________________________________________ >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 Fri Apr 12 14:43: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 A660621F8E59 for ; Fri, 12 Apr 2013 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ynJN7-F5yrIK for ; Fri, 12 Apr 2013 14:43:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C828421F8EF1 for ; Fri, 12 Apr 2013 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=278; q=dns/txt; s=iport; t=1365802984; x=1367012584; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=O3udh+7UGFYNV1+pFD1lgY43I7pzyQK95geULthMgNI=; b=g7wJBIOofNhDO09fIeZb6MuR1+b9K4DYUmbR4339KYlmz7jfiHq3Wi7D ZXkG5ONkmRM9aD0IDN965u1UiTMZB6N+yaWNY5IzFjZrIwrQUgQdox/Gf qF/SI8HzcU4wfpEMaC8MHFyx5bUOQNIw1x96eOqC3UM2Tcuzw/qtC86KU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoLABZ/aFGtJXHB/2dsb2JhbABQgwY2gme+dAQDgQ4WdIJeQD0WGAMCAQIBSw0IAQEFiAsMm0ehIZJfA5cCkRGDJyA X-IronPort-AV: E=Sophos;i="4.87,465,1363132800"; d="scan'208";a="198058414" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 12 Apr 2013 21:43:04 +0000 Received: from rtp-fandreas-8718.cisco.com (rtp-fandreas-8718.cisco.com [10.117.7.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3CLh3YG024378 for ; Fri, 12 Apr 2013 21:43:04 GMT Message-ID: <51687FE7.6060108@cisco.com> Date: Fri, 12 Apr 2013 17:43:03 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Draft Minutes of MMUSIC WG meeting at IETF 86, Florida 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, 12 Apr 2013 21:43:05 -0000 Greetings The draft minutes of the MMUSIC WG meeting at IETF 86 (Florida) have been posted at: http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic Please review the minutes and let us know of any comments or corrections. Thanks -- Ari & Flemming From fandreas@cisco.com Fri Apr 12 17:39: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 AD3C821F8DD4 for ; Fri, 12 Apr 2013 17:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 3OcqFNAgJLsO for ; Fri, 12 Apr 2013 17:39:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0354621F8DD1 for ; Fri, 12 Apr 2013 17:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14158; q=dns/txt; s=iport; t=1365813582; x=1367023182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7wH8H1ZXm2hzBQr1D5MhDtryE7WneH1ie/Ld0MCvn00=; b=JVyRBZfJJuSc7F/zxA+GADfliugLz+VQiK+7bAe4m7v4WYegY9u+PKMy hf/LZR48mxNFpHrdg1eyGD7+7urDa0ETE5cH4YZZyfjfqZjnkm4AqzDmo KlqUswdcEVMP+DnvFtGyJj6ouH04uc+NWyBk2lp0zF/2MrKFNGZAQdRyH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAMGoaFGtJV2b/2dsb2JhbABQgwY2wWSBDRZ0gh8BAQEDAQEBAS8BBTQCCAMFBwQLEQQBAQEJGgQHDwIWHwkIEwEFAgEBBRKHcwYMvEmNXwaBJwsHBoM7A5cCkRGBVYFSIIEuCRc X-IronPort-AV: E=Sophos;i="4.87,466,1363132800"; d="scan'208";a="198368217" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Apr 2013 00:39:41 +0000 Received: from rtp-fandreas-8718.cisco.com (rtp-fandreas-8718.cisco.com [10.117.7.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3D0ddCs005761; Sat, 13 Apr 2013 00:39:40 GMT Message-ID: <5168A94B.20608@cisco.com> Date: Fri, 12 Apr 2013 20:39:39 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 13 Apr 2013 00:39:44 -0000 On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: > Hi Simo, > > I'm in favor of restricting the alternative address to PSTN. Can you elaborate on why ? We have defined a generic connection data capability as part of a general capability negotiation framework. What's the point of that if the only value it can convey is PSTN ? Thanks -- Flemming > This is coherent whit your first bullet below. > > If you share the text changes you are proposing, this would be more easier to review. > > Thanks for taking care of this issue. > > Cheers, > Med > >> -----Message d'origine----- >> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part de >> Simo.Veikkolainen@nokia.com >> Envoyé : lundi 8 avril 2013 08:35 >> À : fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.com >> Cc : jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> Recapping the discussion so far: >> >> >> - ICE is the way to negotiate between different IP addresses. There seems >> to be no disagreement here. >> >> - since no alternative port number can be expressed, in practice the IN >> address needs to go to the actual configuration (address in the c= line and >> port number in the m= line), and the alternative PSTN address in the >> potential configurations. Also here, there seems to be no disagreement. >> >> - then, whether the "ccap" attribute should be limited to carry only PSTN >> addresses, or also other types. I'm with Flemming on this one; SDP capneg >> framework is already fragmented enough, and limiting the connection address >> capability to PSTN addresses only would again be targeted for a single use >> case only, whereas we should strive for general solutions. >> >> Simo >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of >> ext Flemming Andreasen >> Sent: 25. maaliskuuta 2013 3:32 >> To: Andrew Allen >> Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 3/24/13 1:33 PM, Andrew Allen wrote: >>> There is also nothing that prevents people from defining their own >> proprietary attributes to do such a thing but that is not part of an IETF >> standard and is not approved usage. >> Agreed. >> >>> If we really feel the need to discourage further such usage I suppose we >> could add some text stating that if CCAP s received containing an IN net >> type and an IN net type is present in the corresponding Connection >> Attribute then the CCAP attribute MUST be ignored. >> I think that gets complicated quickly for a questionable gain. I'd >> prefer the "MUST NOT" described below with an explanation as to why it's >> there; as you note, ultimately people either decide to be spec compliant >> or not. >> >> -- Flemming >>> That way compliant implementations would not perfom the discouraged >> behavior. >>> Andrew >>> >>> ----- Original Message ----- >>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>> To: Christer Holmberg >>> Cc: Jonathan Lennox ; mmusic@ietf.org >> >>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> In general I agree that having multiple ways of doing the same thing is >> not a good thing, and I don't have any strong feelings regarding the ccap >> usage. >>>> But, no matter what we say, what would actually prevent people from >> using ccap, in the same way they are using ANAT and altc? :) >>> There's no port signaling capability with ccap, but other than that, the >>> only thing that prevents people from using this to signal alternative >>> IP-addresses is the existence of a "MUST NOT" in the spec. >>> >>> -- Flemming >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ________________________________________ >>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of >> Jonathan Lennox [jonathan@vidyo.com] >>>> Sent: Friday, 22 March 2013 10:00 PM >>>> To: Flemming Andreasen >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> Currently, the deployed SIP world has three mechanisms to allow some >> flavor of negotiation among multiple IP addresses: ICE, altc (despite the >> general disapproval of the working group), and ANAT (despite its >> deprecation). >>>> I think that adding ccap as a fourth member of this set would be a >> terrible idea; and as far as I can tell, no one wants to do that. So we >> need to make it clear that that it MUST NOT be used for that purpose. >>>> In the formulation below, I think I'd say that a given media description >> MUST NOT indicate more than one address with an IN network type, across all >> its configurations (actual and potential). >>>> Obviously, different media descriptions (m= line blocks) can have >> different addresses. >>>> In practice, given the port number issue that started this thread, I >> suspect this means that the SDP offer will need to put the IN address in >> the actual configuration (in the c= line), and the PSTN address(es) will be >> in the potential configurations. >>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>> >>>>> Still waiting for more comments on this, especially from the people >> that >>>>> were very vocal in their complaints previously: Now is the time to >> speak up. >>>>> Regardless, a few comments on the below: >>>>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4" >>>>> addresses in a given SDP. >>>>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6" >>>>> addresses in a given SDP. >>>>> >>>>> Nit-picking a bit on the actual text, which I think is important: >>>>> The "ccap" attribute is not what is being to select between different >>>>> IP-addresses; the use of a "ccap" attribute in a potential >> configuration >>>>> ("pcfg") is what is being used for this. Is the restriction that we >> want >>>>> here: >>>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>>> attribute with a network type of "IN" ? >>>>> b) All potential configurations for a particular media description MUST >>>>> NOT reference more than one "ccap" attribute with a network type of >> "IN" ? >>>>> c) Something else ? >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>> I am OK with either of these proposals >>>>>> >>>>>> -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Simo.Veikkolainen@nokia.com >>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> I went through the discussion, and my reading is that there is >> agreement on not allowing ccap to be used for alternative IP address >> negotiation. >>>>>> That could be made clear in the text e.g. by modifying the second >> sentence Flemming quoted to read: >>>>>> >>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>> between different IP connection addresses (e.g. between >>>>>> "IP4" and "IP6" address families or different IP addresses >>>>>> within the same IP address family). >>>>>> >>>>>> >>>>>> The ccap attribute should be able to carry either an IP or PSTN >> address; that way either a PSTN or an IP bearer could be offered as the >> highest priority configuration (in the "m=" line). However, if we want to >> clarify the intended use of ccap, we could modify the first sentence to >> read: >>>>>> >>>>>> The 'ccap' capability attribute is intended for offering >>>>>> alternative connection addresses where the >>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>> bearer or a circuit-switched bearer. >>>>>> >>>>>> >>>>>> Simo >>>>>> >>>>>> -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of ext Flemming Andreasen >>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>> To: mmusic >>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> Greetings >>>>>> >>>>>> As you may have seen, there has recently been some list discussion on >> the "connection data capability" defined in >>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>>>> >>>>>> To recap, the connection data capability ("ccap") provides capability >> negotiation capabilities for what amounts to the "c=" line in regular SDP, >> and as such enables negotiation of network type (such as "IN") and IP- >> address information (v4 and v6 addresses). The Standards Track mechanism >> for negotiating and determining alternative IP-address information today is >> ICE, and hence the draft currently includes the following wording: >>>>>> >>>>>> The 'ccap' capability attribute is intended to >>>>>> be used only when there is no other mechanism available for >>>>>> negotiating alternative connection address information, such as >> when >>>>>> the is different among the alternative addresses (e.g. >>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>>> situations where an existing mechanism (such as Interactive >>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to >> select >>>>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>>>> different IP addresses within the same IP address family). >>>>>> >>>>>> >>>>>> The above text has led to some confusion as to exactly when and what >> "ccap" can be used for. More specifically, is it/should it ever be allowed >> to use "ccap" to convey an IP4 or IP6 address, and if so, under what >> circumstances ? >>>>>> If you have an opinion, please let us know. >>>>>> >>>>>> A couple of points to keep in mind: >>>>>> - The current document has been WGLC'ed without comment ~6 months ago. >>>>>> - 3GPP has a dependency on the document (however I'm not sure if that >> dependency includes the above "IN" feature) >>>>>> - The connection data capability is defined in a general manner to be >> generally useful in line with the overall capability negotiation framework >> (as opposed to targeted at one specific use case with one specific value) >>>>>> - There are scenarios where ICE cannot be used, even if implemented >> (e.g. ice-mismatch). >>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the absence >> of ICE support >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- 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 >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be >> unlawful. >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> -- >>>> Jonathan Lennox >>>> jonathan@vidyo.com >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be >> unlawful. >>> . >>> >> _______________________________________________ >> 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 ari.keranen@ericsson.com Mon Apr 15 06:56: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 39C3421F93CA for ; Mon, 15 Apr 2013 06:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 EnfSbJlR9SMY for ; Mon, 15 Apr 2013 06:56:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 314EA21F9370 for ; Mon, 15 Apr 2013 06:56:46 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-5f-516c071da736 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.8B.19728.D170C615; Mon, 15 Apr 2013 15:56:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Apr 2013 15:56:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CB0A6238A; Mon, 15 Apr 2013 16:56:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7665954AB9; Mon, 15 Apr 2013 16:56:44 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D857754957; Mon, 15 Apr 2013 16:56:43 +0300 (EEST) Message-ID: <516C071B.5050204@ericsson.com> Date: Mon, 15 Apr 2013 16:56:43 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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+NgFprILMWRmVeSWpSXmKPExsUyM+Jvra4se06gwcuLohbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyji1dyJrwSz2iv/r7rM2ML5h7WLk4JAQMJH4 cUKji5ETyBSTuHBvPVsXIxeHkMApRokDbZdYQBJCAhsYJT43SUMkdjNKtM9rZYJw1jFK/Fi7 jgXCWQFUtfQTE0gLr4C2xMFpR5lBbBYBVYkNl36wgthsAvYSNydcZwexRQWSJZbuXMoGUS8o cXLmE7B1IgIyEns3bQbrFRawkJjw/CpYL7OArcSFOddZIGx5ie1v5zBD3K0mcfXcJmaIU1Ul rv57xTiBUWgWkrGzkLTPQtK+gJF5FSN7bmJmTnq50SZGYLAe3PJbdQfjnXMihxilOViUxHnD XS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUUXBp56ue0fVobaP7Mhm3S48u/WDclvwy lonrsjlvdl25/6nl7BKrNqy4rqU3K1i34d4KoXlTVmxw/F3imOB8SbgvJk/jIcMZManTRtM/ b5ntd+zTzV+C/52jDr8uWVzfnWg8n+vJMsETE4Vj1i2e1hHxc/vegz6nl6y6cHh+V1rfpane +5vklViKMxINtZiLihMBi5Mk8yQCAAA= Subject: [MMUSIC] Confirming consensus on way forward with 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, 15 Apr 2013 13:56:47 -0000 At the Orlando meeting we had a call for consensus (see the minutes of the meeting at [1]) on using the current SDP bundle WG document [2] as the baseline of the bundle work. That is, using the offer/answer exchange as outlined in the draft (subject to clarifying comments made during the meeting) and using the port numbers as described in the draft. The other option would be to not use this as the baseline but to continue discussing the alternative methods. The show-of-hands at the meeting was around 30 for (going forward with the method described in the WG bundle doc) and 4 against. The MMUSIC chairs would like to confirm the consensus on this. Those who were not present at the meeting to comment on this, please do so now. Cheers, Ari [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03 From andrew.hutton@siemens-enterprise.com Tue Apr 16 06:28: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 5959D21F969F for ; Tue, 16 Apr 2013 06:28:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDhqFCwobU3E for ; Tue, 16 Apr 2013 06:28:50 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9338521F95F5 for ; Tue, 16 Apr 2013 06:28:50 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9E46223F0423; Tue, 16 Apr 2013 15:28:49 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 16 Apr 2013 15:28:49 +0200 From: "Hutton, Andrew" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] Confirming consensus on way forward with Bundle Thread-Index: AQHOOeEXkoV4z+UOyUKzFdVVZNLXNJjY1gTQ Date: Tue, 16 Apr 2013 13:28:49 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> References: <516C071B.5050204@ericsson.com> In-Reply-To: <516C071B.5050204@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Confirming consensus on way forward with 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: Tue, 16 Apr 2013 13:28:51 -0000 Hi, I stated during the discussion in Orlando that I believe the WG needs to do= a deeper dive in to some of the more complex scenarios involving multiple = ICE candidates (E.g. Dual Stack, relay candidates etc.). After the meeting I thought about this some more and submitted http://tools= .ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00 which makes a = small start on this. I will spend some time over the next couple of weeks t= hinking this out a bit more and will probably update the draft but any comm= ents from the working group as to whether this is valuable or not would be = appreciated. My thinking is that this might be an extension to the current approach rath= er than an alternative. Regards Andy > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ari Ker=E4nen > Sent: 15 April 2013 14:57 > To: mmusic > Subject: [MMUSIC] Confirming consensus on way forward with Bundle >=20 > At the Orlando meeting we had a call for consensus (see the minutes of > the meeting at [1]) on using the current SDP bundle WG document [2] as > the baseline of the bundle work. That is, using the offer/answer > exchange as outlined in the draft (subject to clarifying comments made > during the meeting) and using the port numbers as described in the > draft. >=20 > The other option would be to not use this as the baseline but to > continue discussing the alternative methods. >=20 > The show-of-hands at the meeting was around 30 for (going forward with > the method described in the WG bundle doc) and 4 against. The MMUSIC > chairs would like to confirm the consensus on this. >=20 > Those who were not present at the meeting to comment on this, please do > so now. >=20 >=20 > Cheers, > Ari >=20 > [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic > [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle- > negotiation-03 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From worley@shell01.TheWorld.com Tue Apr 16 08:50: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 A22AB21F974F for ; Tue, 16 Apr 2013 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 0FVCY5Sl+lfe for ; Tue, 16 Apr 2013 08:50:12 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A9E4021F9734 for ; Tue, 16 Apr 2013 08:50:12 -0700 (PDT) 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 r3GFnxSn005280 for ; Tue, 16 Apr 2013 11:50:01 -0400 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 r3GFnvNh2797498 for ; Tue, 16 Apr 2013 11:49:57 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3GFnui72796125; Tue, 16 Apr 2013 11:49:56 -0400 (EDT) Date: Tue, 16 Apr 2013 11:49:56 -0400 (EDT) Message-Id: <201304161549.r3GFnui72796125@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 16 Apr 2013 15:50:13 -0000 DES F11 It must be possible to add and remove one way video flows within the bundle without requiring an additional offer/answer cycle. DES F12 Bundling must not interfere with ICE usage, and in particular, ICE's ability to negotiate both IPv4 and IPv6 addresses simultaneously. DES F13 It is desirable for RTP media to appear on the wire as (encrypted) SRTP packets and for RTCP reports to appear on the wire as (authenticated but not encrypted) SRTCP packets. Thus, encryption of RTP/RTCP via DTLS and encapsulation of multiplexed packets is not desirable. Comments? Dale From juberti@google.com Tue Apr 16 23:12: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 8F70421F8D02 for ; Tue, 16 Apr 2013 23:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 j9UyYFui3c2d for ; Tue, 16 Apr 2013 23:12:53 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5221F842A for ; Tue, 16 Apr 2013 23:12:53 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id u28so571498qcs.36 for ; Tue, 16 Apr 2013 23:12:45 -0700 (PDT) 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=ORwg6bXpmucKqsZmyk739PTJ0G0+Etv4ZWkzl92sf7M=; b=Fo7EuPJoQxU/mHZu9p7JRjgtvOJ1gtjuQye4ngitn0LZVrZ/Wmsy+Ld0wo82mg3hL2 /dyZEM2WaoK4YxFLRqz0o08ROEYridiOD8yp2F3Rb/hsMLG7PtXGyOTbDeKqNkcNNPNw ypOLiGdoX1dKZGsAmdZER2RISthOToejhCtAEkOJCuF3Uy51q8SFX+vQD8qPjuIqmEeN +n2s9TgSzzEv7GTiqZbQlmK6jn1hB/ev16nsPa2H5LpqOfKWtwwYz/S5I19uK3JxmH9+ CMYMnaVOFeMPfe7VqJeiFdgGTtPJqao4UEsY15VIVTMVBzPd4eXFJC5cUHQCQALN3nGG 5h1Q== 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=ORwg6bXpmucKqsZmyk739PTJ0G0+Etv4ZWkzl92sf7M=; b=kGg8Zm1d8vKoe1JSJ3JEnHRvOm1w713JL7YdnZ0T3WKEeb+TwTdo5lW77tkM5xf7wn Sh5geI1U2SlqEKYMMj2BDGHyLxCLA01mBflK9l2KOf6M88i3cPIVvz+UXxKxR8omdrP4 se7D/lYTqJfqaDvxY5QwEGq1cuonop4mMWTVGq8DTar/sdlhL/MvqGIG5Bcq99d7uUut 3H9KMR7T2/JnwhQVNfHfwcR9wS1XhG3wSzYqChYt/jeRfakj4bcG7syTIp2rN4hzfaTC 0xMzYNIeDdseREwQxqwaQ/yn/Pl4kn8yuXIOnn9N5EOrR0DAd1KSdhBzguiID1BjCuOv 3/LA== X-Received: by 10.229.122.6 with SMTP id j6mr1554448qcr.111.1366179164989; Tue, 16 Apr 2013 23:12:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Tue, 16 Apr 2013 23:12:24 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Tue, 16 Apr 2013 23:12:24 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=14dae94ede37d456fd04da885f69 X-Gm-Message-State: ALoCoQkH62fkhppHnAC2/GUEik23d8sWbcbGPF0BAKpIOND+2m8KSlIZJzQmvDSt9wWIENvRcBcM9Pwj9km05HB1yA5IlV5ZKXZ/+IJSCqJ/5CDuqt/0Ek1lpon8ntwR89mUG9XM1RPYa3MQLYTUxNvNI2lDd/TlNrFHxBEcvbelUP/MR3dWcDDvFet78gAsQKkOVh0dSjDf Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Confirming consensus on way forward with 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: Wed, 17 Apr 2013 06:12:54 -0000 --14dae94ede37d456fd04da885f69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support using the current BUNDLE document as the basis of future multiplexing work. However, I agree there are a number of outstanding details that need to be resolved before this specification is implementable. On Tue, Apr 16, 2013 at 6:28 AM, Hutton, Andrew < andrew.hutton@siemens-enterprise.com> wrote: > Hi, > > I stated during the discussion in Orlando that I believe the WG needs to > do a deeper dive in to some of the more complex scenarios involving > multiple ICE candidates (E.g. Dual Stack, relay candidates etc.). > > After the meeting I thought about this some more and submitted > http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00w= hich makes a small start on this. I will spend some time over the next > couple of weeks thinking this out a bit more and will probably update the > draft but any comments from the working group as to whether this is > valuable or not would be appreciated. > > My thinking is that this might be an extension to the current approach > rather than an alternative. > > Regards > Andy > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Ari Ker=C3=A4nen > > Sent: 15 April 2013 14:57 > > To: mmusic > > Subject: [MMUSIC] Confirming consensus on way forward with Bundle > > > > At the Orlando meeting we had a call for consensus (see the minutes of > > the meeting at [1]) on using the current SDP bundle WG document [2] as > > the baseline of the bundle work. That is, using the offer/answer > > exchange as outlined in the draft (subject to clarifying comments made > > during the meeting) and using the port numbers as described in the > > draft. > > > > The other option would be to not use this as the baseline but to > > continue discussing the alternative methods. > > > > The show-of-hands at the meeting was around 30 for (going forward with > > the method described in the WG bundle doc) and 4 against. The MMUSIC > > chairs would like to confirm the consensus on this. > > > > Those who were not present at the meeting to comment on this, please do > > so now. > > > > > > Cheers, > > Ari > > > > [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic > > [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle- > > negotiation-03 > > _______________________________________________ > > 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 > --14dae94ede37d456fd04da885f69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support using the current BUNDLE document as the basis o= f future multiplexing work.

However, I agree there are a= number of outstanding details that need to be resolved before this specifi= cation is implementable.


On Tue,= Apr 16, 2013 at 6:28 AM, Hutton, Andrew <andrew.hutton= @siemens-enterprise.com> wrote:
Hi,

I stated during the discussion in Orlando that I believe the WG needs to do= a deeper dive in to some of the more complex scenarios involving multiple = ICE candidates (E.g. Dual Stack, relay candidates etc.).

After the meeting I thought about this some more and submitted http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-= candidates-00 which makes a small start on this. I will spend some time= over the next couple of weeks thinking this out a bit more and will probab= ly update the draft but any comments from the working group as to whether t= his is valuable or not would be appreciated.

My thinking is that this might be an extension to the current approach rath= er than an alternative.

Regards
Andy



> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On
> Behalf Of Ari Ker=C3=A4nen
> Sent: 15 April 2013 14:57
> To: mmusic
> Subject: [MMUSIC] Confirming consensus on way forward with Bundle
>
> At the Orlando meeting we had a call for consensus (see the minutes of=
> the meeting at [1]) on using the current SDP bundle WG document [2] as=
> the baseline of the bundle work. That is, using the offer/answer
> exchange as outlined in the draft (subject to clarifying comments made=
> during the meeting) and using the port numbers as described in the
> draft.
>
> The other option would be to not use this as the baseline but to
> continue discussing the alternative methods.
>
> The show-of-hands at the meeting was around 30 for (going forward with=
> the method described in the WG bundle doc) and 4 against. The MMUSIC > chairs would like to confirm the consensus on this.
>
> Those who were not present at the meeting to comment on this, please d= o
> so now.
>
>
> Cheers,
> Ari
>
> [1] http://www.ietf.org/proceedings/86/minutes/minutes= -86-mmusic
> [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundl= e-
> negotiation-03
> _______________________________________________
> 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

--14dae94ede37d456fd04da885f69-- From christer.holmberg@ericsson.com Tue Apr 16 23:37: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 B959F21F943A for ; Tue, 16 Apr 2013 23:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 CxCyif7OlJKP for ; Tue, 16 Apr 2013 23:37:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3904721F9402 for ; Tue, 16 Apr 2013 23:37:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-56-516e43427cca Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E1.5F.03253.2434E615; Wed, 17 Apr 2013 08:37:55 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 08:37:53 +0200 From: Christer Holmberg To: Justin Uberti , "Hutton, Andrew" Thread-Topic: [MMUSIC] Confirming consensus on way forward with Bundle Thread-Index: AQHOOeEWQWKHLLV+NkawyHpup4keiJjYt16AgAEYZgCAACg7YA== Date: Wed, 17 Apr 2013 06:37:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3257F3@ESESSMB208.ericsson.se> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3257F3ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvra6zc16gweTTHBZn+7rYLbZOFbKY uvwxiwOzx4JNpR5Llvxk8rhx+z1zAHMUl01Kak5mWWqRvl0CV0bD3vOsBQcqKmad28DSwLig tIuRk0NCwESis/MrI4QtJnHh3nq2LkYuDiGBw4wSu1duY4RwFjNKvLxxmLmLkYODTcBCovuf NkiDiECixJL3fUwgNrNAuMSDH6vZQWxhAVeJlgmv2CFq3CQ67u5lhbCdJLp//gFbxiKgKvHq fxuYzSvgKzGjtYMdYtd2Rokjj7exgOziFAiUePXYA6SGEei476fWQO0Sl7j1ZD4TxNECEkv2 nGeGsEUlXj7+xwphK0pcnb6cCWQMs0C+xId3ChCrBCVOznzCMoFRdBaSSbMQqmYhqYIIa0qs 36UPUa0oMaX7ITuErSHROmcuO7L4Akb2VYzsuYmZOenl5psYgdF1cMtvgx2Mm+6LHWKU5mBR EucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRbGFz2NKkyW3f9Jg/zRZeyzp3zTed TTm5M6JPqz3w9N0/9+Wi5ds2K/1JWK+wSH/aD5t2f1NB66uBcw4/t/r4vnTCofJ8j6mfLj5N qLp9qOy46JIzXFcX8czdJO+1dN/pe5ee80ZreuaLMPnxqEXWmjydy3CC/5jDlg9xdxZ926z4 ctVOqzUfUpRYijMSDbWYi4oTAWtYsRB8AgAA Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] Confirming consensus on way forward with 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: Wed, 17 Apr 2013 06:37:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3257F3ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZvciBvYnZpb3VzIHJlYXNvbnMgSSBhbHNvIHN1cHBvcnQgdXNpbmcgdGhlIGN1cnJl bnQgQlVORExFIGRvY3VtZW50IGFzIGJhc2lzLg0KDQpUaGVyZSBmb3Igc3VyZSBhcmUgaXNzdWVz IHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZC4gQnV0LCBvbmNlIHdlIGFncmVlIG9uIHRoZSBiYXNp cywgd2Ugd2lsbCBiZSBhYmxlIHRvIHB1dCBhbGwgZm9jdXMgb24gdGhvc2UgaXNzdWVzIDopDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRp DQpTZW50OiAxNy4gaHVodGlrdXV0YSAyMDEzIDk6MTINClRvOiBIdXR0b24sIEFuZHJldw0KQ2M6 IEFyaSBLZXLDpG5lbjsgbW11c2ljDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gQ29uZmlybWluZyBj b25zZW5zdXMgb24gd2F5IGZvcndhcmQgd2l0aCBCdW5kbGUNCg0KSSBzdXBwb3J0IHVzaW5nIHRo ZSBjdXJyZW50IEJVTkRMRSBkb2N1bWVudCBhcyB0aGUgYmFzaXMgb2YgZnV0dXJlIG11bHRpcGxl eGluZyB3b3JrLg0KDQpIb3dldmVyLCBJIGFncmVlIHRoZXJlIGFyZSBhIG51bWJlciBvZiBvdXRz dGFuZGluZyBkZXRhaWxzIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZCBiZWZvcmUgdGhpcyBzcGVj aWZpY2F0aW9uIGlzIGltcGxlbWVudGFibGUuDQoNCk9uIFR1ZSwgQXByIDE2LCAyMDEzIGF0IDY6 MjggQU0sIEh1dHRvbiwgQW5kcmV3IDxhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50ZXJwcmlzZS5j b208bWFpbHRvOmFuZHJldy5odXR0b25Ac2llbWVucy1lbnRlcnByaXNlLmNvbT4+IHdyb3RlOg0K SGksDQoNCkkgc3RhdGVkIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiBpbiBPcmxhbmRvIHRoYXQgSSBi ZWxpZXZlIHRoZSBXRyBuZWVkcyB0byBkbyBhIGRlZXBlciBkaXZlIGluIHRvIHNvbWUgb2YgdGhl IG1vcmUgY29tcGxleCBzY2VuYXJpb3MgaW52b2x2aW5nIG11bHRpcGxlIElDRSBjYW5kaWRhdGVz IChFLmcuIER1YWwgU3RhY2ssIHJlbGF5IGNhbmRpZGF0ZXMgZXRjLikuDQoNCkFmdGVyIHRoZSBt ZWV0aW5nIEkgdGhvdWdodCBhYm91dCB0aGlzIHNvbWUgbW9yZSBhbmQgc3VibWl0dGVkIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1tbXVzaWMtYnVuZGxlZC1pY2UtY2Fu ZGlkYXRlcy0wMCB3aGljaCBtYWtlcyBhIHNtYWxsIHN0YXJ0IG9uIHRoaXMuIEkgd2lsbCBzcGVu ZCBzb21lIHRpbWUgb3ZlciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MgdGhpbmtpbmcgdGhpcyBv dXQgYSBiaXQgbW9yZSBhbmQgd2lsbCBwcm9iYWJseSB1cGRhdGUgdGhlIGRyYWZ0IGJ1dCBhbnkg Y29tbWVudHMgZnJvbSB0aGUgd29ya2luZyBncm91cCBhcyB0byB3aGV0aGVyIHRoaXMgaXMgdmFs dWFibGUgb3Igbm90IHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KDQpNeSB0aGlua2luZyBpcyB0aGF0 IHRoaXMgbWlnaHQgYmUgYW4gZXh0ZW5zaW9uIHRvIHRoZSBjdXJyZW50IGFwcHJvYWNoIHJhdGhl ciB0aGFuIGFuIGFsdGVybmF0aXZlLg0KDQpSZWdhcmRzDQpBbmR5DQoNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbg0KPiBCZWhhbGYgT2YgQXJpIEtl csOkbmVuDQo+IFNlbnQ6IDE1IEFwcmlsIDIwMTMgMTQ6NTcNCj4gVG86IG1tdXNpYw0KPiBTdWJq ZWN0OiBbTU1VU0lDXSBDb25maXJtaW5nIGNvbnNlbnN1cyBvbiB3YXkgZm9yd2FyZCB3aXRoIEJ1 bmRsZQ0KPg0KPiBBdCB0aGUgT3JsYW5kbyBtZWV0aW5nIHdlIGhhZCBhIGNhbGwgZm9yIGNvbnNl bnN1cyAoc2VlIHRoZSBtaW51dGVzIG9mDQo+IHRoZSBtZWV0aW5nIGF0IFsxXSkgb24gdXNpbmcg dGhlIGN1cnJlbnQgU0RQIGJ1bmRsZSBXRyBkb2N1bWVudCBbMl0gYXMNCj4gdGhlIGJhc2VsaW5l IG9mIHRoZSBidW5kbGUgd29yay4gVGhhdCBpcywgdXNpbmcgdGhlIG9mZmVyL2Fuc3dlcg0KPiBl eGNoYW5nZSBhcyBvdXRsaW5lZCBpbiB0aGUgZHJhZnQgKHN1YmplY3QgdG8gY2xhcmlmeWluZyBj b21tZW50cyBtYWRlDQo+IGR1cmluZyB0aGUgbWVldGluZykgYW5kIHVzaW5nIHRoZSBwb3J0IG51 bWJlcnMgYXMgZGVzY3JpYmVkIGluIHRoZQ0KPiBkcmFmdC4NCj4NCj4gVGhlIG90aGVyIG9wdGlv biB3b3VsZCBiZSB0byBub3QgdXNlIHRoaXMgYXMgdGhlIGJhc2VsaW5lIGJ1dCB0bw0KPiBjb250 aW51ZSBkaXNjdXNzaW5nIHRoZSBhbHRlcm5hdGl2ZSBtZXRob2RzLg0KPg0KPiBUaGUgc2hvdy1v Zi1oYW5kcyBhdCB0aGUgbWVldGluZyB3YXMgYXJvdW5kIDMwIGZvciAoZ29pbmcgZm9yd2FyZCB3 aXRoDQo+IHRoZSBtZXRob2QgZGVzY3JpYmVkIGluIHRoZSBXRyBidW5kbGUgZG9jKSBhbmQgNCBh Z2FpbnN0LiBUaGUgTU1VU0lDDQo+IGNoYWlycyB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhlIGNv bnNlbnN1cyBvbiB0aGlzLg0KPg0KPiBUaG9zZSB3aG8gd2VyZSBub3QgcHJlc2VudCBhdCB0aGUg bWVldGluZyB0byBjb21tZW50IG9uIHRoaXMsIHBsZWFzZSBkbw0KPiBzbyBub3cuDQo+DQo+DQo+ IENoZWVycywNCj4gQXJpDQo+DQo+IFsxXSBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzg2L21pbnV0ZXMvbWludXRlcy04Ni1tbXVzaWMNCj4gWzJdIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1idW5kbGUtDQo+IG5lZ290aWF0aW9uLTAzDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNp YyBtYWlsaW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcg bGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1C3257F3ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rm9yIG9idmlvdXMgcmVhc29ucyBJIGFsc28gc3VwcG9ydCB1c2luZyB0aGUgY3VycmVu dCBCVU5ETEUgZG9jdW1lbnQgYXMgYmFzaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBmb3Igc3VyZSBhcmUg aXNzdWVzIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZC4gQnV0LCBvbmNlIHdlIGFncmVlIG9uIHRo ZSBiYXNpcywgd2Ugd2lsbCBiZSBhYmxlIHRvIHB1dCBhbGwgZm9jdXMgb24gdGhvc2UgaXNzdWVz IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBV YmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gMTcuIGh1aHRpa3V1dGEgMjAxMyA5OjEyPGJyPg0KPGI+ VG86PC9iPiBIdXR0b24sIEFuZHJldzxicj4NCjxiPkNjOjwvYj4gQXJpIEtlcsOkbmVuOyBtbXVz aWM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIENvbmZpcm1pbmcgY29uc2Vuc3Vz IG9uIHdheSBmb3J3YXJkIHdpdGggQnVuZGxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzdXBwb3J0IHVzaW5nIHRoZSBjdXJyZW50IEJVTkRMRSBkb2N1bWVudCBhcyB0 aGUgYmFzaXMgb2YgZnV0dXJlIG11bHRpcGxleGluZyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSSBhZ3JlZSB0aGVyZSBhcmUgYSBu dW1iZXIgb2Ygb3V0c3RhbmRpbmcgZGV0YWlscyB0aGF0IG5lZWQgdG8gYmUgcmVzb2x2ZWQgYmVm b3JlIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbXBsZW1lbnRhYmxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgQXByIDE2LCAyMDEzIGF0IDY6MjggQU0sIEh1dHRvbiwgQW5kcmV3 ICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVudGVycHJpc2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+YW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVudGVycHJpc2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+ DQo8YnI+DQpJIHN0YXRlZCBkdXJpbmcgdGhlIGRpc2N1c3Npb24gaW4gT3JsYW5kbyB0aGF0IEkg YmVsaWV2ZSB0aGUgV0cgbmVlZHMgdG8gZG8gYSBkZWVwZXIgZGl2ZSBpbiB0byBzb21lIG9mIHRo ZSBtb3JlIGNvbXBsZXggc2NlbmFyaW9zIGludm9sdmluZyBtdWx0aXBsZSBJQ0UgY2FuZGlkYXRl cyAoRS5nLiBEdWFsIFN0YWNrLCByZWxheSBjYW5kaWRhdGVzIGV0Yy4pLjxicj4NCjxicj4NCkFm dGVyIHRoZSBtZWV0aW5nIEkgdGhvdWdodCBhYm91dCB0aGlzIHNvbWUgbW9yZSBhbmQgc3VibWl0 dGVkIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1tbXVz aWMtYnVuZGxlZC1pY2UtY2FuZGlkYXRlcy0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLW1tdXNpYy1idW5kbGVkLWljZS1jYW5kaWRh dGVzLTAwPC9hPiB3aGljaCBtYWtlcyBhIHNtYWxsIHN0YXJ0IG9uIHRoaXMuIEkgd2lsbCBzcGVu ZCBzb21lIHRpbWUgb3ZlciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MgdGhpbmtpbmcgdGhpcyBv dXQgYSBiaXQgbW9yZSBhbmQgd2lsbCBwcm9iYWJseSB1cGRhdGUgdGhlIGRyYWZ0IGJ1dCBhbnkg Y29tbWVudHMgZnJvbSB0aGUgd29ya2luZw0KIGdyb3VwIGFzIHRvIHdoZXRoZXIgdGhpcyBpcyB2 YWx1YWJsZSBvciBub3Qgd291bGQgYmUgYXBwcmVjaWF0ZWQuPGJyPg0KPGJyPg0KTXkgdGhpbmtp bmcgaXMgdGhhdCB0aGlzIG1pZ2h0IGJlIGFuIGV4dGVuc2lvbiB0byB0aGUgY3VycmVudCBhcHBy b2FjaCByYXRoZXIgdGhhbiBhbiBhbHRlcm5hdGl2ZS48YnI+DQo8YnI+DQpSZWdhcmRzPGJyPg0K QW5keTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1i b3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNl c0BpZXRmLm9yZyI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbjxicj4NCiZndDsgQmVo YWxmIE9mIEFyaSBLZXLDpG5lbjxicj4NCiZndDsgU2VudDogMTUgQXByaWwgMjAxMyAxNDo1Nzxi cj4NCiZndDsgVG86IG1tdXNpYzxicj4NCiZndDsgU3ViamVjdDogW01NVVNJQ10gQ29uZmlybWlu ZyBjb25zZW5zdXMgb24gd2F5IGZvcndhcmQgd2l0aCBCdW5kbGU8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBBdCB0aGUgT3JsYW5kbyBtZWV0aW5nIHdlIGhhZCBhIGNhbGwgZm9yIGNvbnNlbnN1cyAoc2Vl IHRoZSBtaW51dGVzIG9mPGJyPg0KJmd0OyB0aGUgbWVldGluZyBhdCBbMV0pIG9uIHVzaW5nIHRo ZSBjdXJyZW50IFNEUCBidW5kbGUgV0cgZG9jdW1lbnQgWzJdIGFzPGJyPg0KJmd0OyB0aGUgYmFz ZWxpbmUgb2YgdGhlIGJ1bmRsZSB3b3JrLiBUaGF0IGlzLCB1c2luZyB0aGUgb2ZmZXIvYW5zd2Vy PGJyPg0KJmd0OyBleGNoYW5nZSBhcyBvdXRsaW5lZCBpbiB0aGUgZHJhZnQgKHN1YmplY3QgdG8g Y2xhcmlmeWluZyBjb21tZW50cyBtYWRlPGJyPg0KJmd0OyBkdXJpbmcgdGhlIG1lZXRpbmcpIGFu ZCB1c2luZyB0aGUgcG9ydCBudW1iZXJzIGFzIGRlc2NyaWJlZCBpbiB0aGU8YnI+DQomZ3Q7IGRy YWZ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBvdGhlciBvcHRpb24gd291bGQgYmUgdG8gbm90 IHVzZSB0aGlzIGFzIHRoZSBiYXNlbGluZSBidXQgdG88YnI+DQomZ3Q7IGNvbnRpbnVlIGRpc2N1 c3NpbmcgdGhlIGFsdGVybmF0aXZlIG1ldGhvZHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHNo b3ctb2YtaGFuZHMgYXQgdGhlIG1lZXRpbmcgd2FzIGFyb3VuZCAzMCBmb3IgKGdvaW5nIGZvcndh cmQgd2l0aDxicj4NCiZndDsgdGhlIG1ldGhvZCBkZXNjcmliZWQgaW4gdGhlIFdHIGJ1bmRsZSBk b2MpIGFuZCA0IGFnYWluc3QuIFRoZSBNTVVTSUM8YnI+DQomZ3Q7IGNoYWlycyB3b3VsZCBsaWtl IHRvIGNvbmZpcm0gdGhlIGNvbnNlbnN1cyBvbiB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRo b3NlIHdobyB3ZXJlIG5vdCBwcmVzZW50IGF0IHRoZSBtZWV0aW5nIHRvIGNvbW1lbnQgb24gdGhp cywgcGxlYXNlIGRvPGJyPg0KJmd0OyBzbyBub3cuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IENoZWVycyw8YnI+DQomZ3Q7IEFyaTxicj4NCiZndDs8YnI+DQomZ3Q7IFsxXSA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L21pbnV0ZXMvbWludXRlcy04Ni1t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv ODYvbWludXRlcy9taW51dGVzLTg2LW1tdXNpYzwvYT48YnI+DQomZ3Q7IFsyXSA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLWJ1bmRsZS08L2E+PGJyPg0KJmd0OyBuZWdvdGlhdGlvbi0wMzxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IG1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0 Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C3257F3ESESSMB208erics_-- From magnus.westerlund@ericsson.com Wed Apr 17 00:55: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 1DC5021F85BC for ; Wed, 17 Apr 2013 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.450, 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 qPWQ6dQQQA-3 for ; Wed, 17 Apr 2013 00:55:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2219E21F85A2 for ; Wed, 17 Apr 2013 00:55:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-ca-516e55761b9a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.86.19728.6755E615; Wed, 17 Apr 2013 09:55:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Apr 2013 09:55:34 +0200 Message-ID: <516E5575.1050704@ericsson.com> Date: Wed, 17 Apr 2013 09:55:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304161549.r3GFnui72796125@shell01.TheWorld.com> In-Reply-To: <201304161549.r3GFnui72796125@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vrc8NC/Q4EA/t8XU5Y9ZLF6eKHNg 8pi8/yuzx5IlP5kCmKK4bFJSczLLUov07RK4Mn7snsZc8Eeg4vXe86wNjOt5uxg5OSQETCQm X97IAmGLSVy4t56ti5GLQ0jgFKPEl8u3mUESQgLLGSX+dKmA2LwC2hLv/rxkArFZBFQlJk9Y xQhiswlYSNz80QjUzMEhKhAssbU1BqJcUOLkzCcsIGERAU2JjgU5IGFmAWGJC+ePg00RBurs +/WIDWKTvcSCU09ZQWxOAQeJq7PusEKcJimx5UU7O0SvnsSUqy2MELa8RPPW2VBXaks0NHWw TmAUmoVk8ywkLbOQtCxgZF7FyJ6bmJmTXm60iREYpAe3/FbdwXjnnMghRmkOFiVx3nDXCwFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGHnCZ7swvJizbPYxXc3YDm1bwZ9md2d9tRA9HqvZ +/jo8W3qdxijfQKPSn9OsVmTy/HSap52kCRT+6Qp88Nvrdpa5hi1q2WG8CkxpjqVnfuSSzmu lapG7ThcGWGo+uXZk+0tL22at66YaNng9FqkV3+6iLa9YVt1DYOFSftdgQNzP7RXMgoHKbEU ZyQaajEXFScCAEQOOF4gAgAA Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 17 Apr 2013 07:55:37 -0000 On 2013-04-16 17:49, Dale R. Worley wrote: > DES F11 It must be possible to add and remove one way video flows > within the bundle without requiring an additional offer/answer > cycle. I think this is desirable and possible to support in certain types of applications. Some do require additional information that needs to be signalled somewhere. If one have chose O/A for that transport then this requirement can't be meet. However, I do agree with the intention that it should be possible. > > DES F12 Bundling must not interfere with ICE usage, and in > particular, ICE's ability to negotiate both IPv4 and IPv6 > addresses simultaneously. I believe the intention is right here, but I stumble on the word "negotiate". To my understanding the usage of two address families are not really negotiated. It is more, here are my candidates, create candidate pairs within each family and then follow the check-board algorithm. > > DES F13 It is desirable for RTP media to appear on the wire as > (encrypted) SRTP packets and for RTCP reports to appear on the > wire as (authenticated but not encrypted) SRTCP packets. Thus, > encryption of RTP/RTCP via DTLS and encapsulation of multiplexed > packets is not desirable. I am not certain I understand the motivations for this requirement. Is the need to having unencrypted RTCP for third party monitors? From a security point of view I see issues with such blanket statements. There can be information in the RTCP that is sensitive for privacy reasons. For the last sentence are you really meaning DTLS or DTLS-SRTP. There is a big difference here. -- 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 magnus.westerlund@ericsson.com Wed Apr 17 01:01: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 B0B0021F86A5 for ; Wed, 17 Apr 2013 01:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 B0UlI+kYYS8b for ; Wed, 17 Apr 2013 01:01:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BEBA921F8691 for ; Wed, 17 Apr 2013 01:01:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-99-516e56bfc1da Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C0.2F.03253.FB65E615; Wed, 17 Apr 2013 10:01:03 +0200 (CEST) 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, 17 Apr 2013 10:01:03 +0200 Message-ID: <516E56BE.2040606@ericsson.com> Date: Wed, 17 Apr 2013 10:01:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> In-Reply-To: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vnd/WF6gwZxTFhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyni/ZQ97wUyuit0fbzA2MHZxdDFyckgImEgc fbSUBcIWk7hwbz1bFyMXh5DAKUaJEyf/MUI4yxklTs1fBVbFK6At8ePBJaAEBweLgKrEjmum IGE2AQuJmz8a2UDCogLBEltbYyCqBSVOznzCAhIWEdCU6FiQAxJmFhCWuHD+OBOILQzU2ffr ERuILSRgL/H4zEKwOKeAg8TlDf/ZIE6TlNjyop0doldPYsrVFkYIW16ieetsZohebYmGpg7W CYxCs5BsnoWkZRaSlgWMzKsY2XMTM3PSy803MQKD9OCW3wY7GDfdFzvEKM3BoiTOG+56IUBI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo1/2Ecsy4cv/tv53ETT6PSvwU9XcxW/XCu99lb68 P106oPKW1IXNNxfvlzn1b5VbusWpSqMP4T26HN/a1Zc+4O7TjrP/Z6Mg5Cl3QvV7j/OtFBl2 OyUnnUkzPvoG7btktivU8GOJze9GDtNzGk8ZDHhvv0isy3xy7tNt/bQfCzoNAwubZb6JKrEU ZyQaajEXFScCAKN+vrYgAgAA Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 17 Apr 2013 08:01:06 -0000 On 2013-04-09 17:39, Dale R. Worley wrote: > 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. If you with "constituent RTP session within it" where it is a bundle means the RTP media streams resulting from that particular SDP media description (m= block) then I believe I agree with 1). When it comes to 2) what makes this different from rejecting each m= block within the bundle? 3) is required if legacy fallback at all going to be available. 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 Apr 17 02:51: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 228FD21F8E06 for ; Wed, 17 Apr 2013 02:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 WutSoW1i65ud for ; Wed, 17 Apr 2013 02:51:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBD921F8BA6 for ; Wed, 17 Apr 2013 02:51:36 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-1e-516e70a74d5d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EC.75.03253.7A07E615; Wed, 17 Apr 2013 11:51:35 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 11:51:35 +0200 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F5 Thread-Index: Ac47UNPVHN0oCIYkTN6Zu5Ich9PnuA== Date: Wed, 17 Apr 2013 09:51:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325E18@ESESSMB208.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+Jvre7ygrxAg/UfbCymLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfH15Q/Wgt3MFW/n9bM0MF5k6mLk5JAQMJF4 t+0/O4QtJnHh3nq2LkYuDiGBw4wSH9bfZIdwFjNKzJj3Fsjh4GATsJDo/qcN0iAi4CexftUH sGZhAUeJTW/62CHiThJ/Fm5hBCkXEdCTeLrFHyTMIqAqMevoHmYQm1fAV+LRtNmMIDYj0N7v p9aA3cMsIC5x68l8qNsEJJbsOc8MYYtKvHz8jxXCVpS4On05VL2OxILdn9ggbG2JZQtfQ80X lDg58wnLBEbhWUjGzkLSMgtJyywkLQsYWVYxsucmZuakl5tvYgSG9cEtvw12MG66L3aIUZqD RUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRlMlI27hKTq+ebNFQpZONd3e4fX6 t1978twpF6YJ/dk1X7agYMoE7u8aQfP2ByddEjrXEKvX+tvkqMMaBd/Dl2MMTuari3vpvf3V FxbVlbKZ9eQbaZarIrzON64r3TXoX7GoaMXtittfdpz6teZD8tV/VrsXadhuKf51lntG4eTK Gf4mtyUuKiqxFGckGmoxFxUnAgDXqLVKOQIAAA== Subject: Re: [MMUSIC] Feedback requested on requirements - DES F5 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, 17 Apr 2013 09:51:42 -0000 Hi, > 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.) I am not sure I understand this. Why would a bundle need to contain other b= undle(s)? Regards, Christer From christer.holmberg@ericsson.com Wed Apr 17 02:53: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 3A6DD21F8D02 for ; Wed, 17 Apr 2013 02:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 79IldBgeIxEU for ; Wed, 17 Apr 2013 02:53:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4314921F8D03 for ; Wed, 17 Apr 2013 02:53:32 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-5f-516e711bace7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 48.CD.19728.B117E615; Wed, 17 Apr 2013 11:53:31 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 11:53:30 +0200 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F4 Thread-Index: Ac47UTAd0vzD54rARoOQI+zDT8aWIQ== Date: Wed, 17 Apr 2013 09:53:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325E2B@ESESSMB208.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+Jvra50YV6gwb6XEhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyujvXc5Y8JGxYv9NmwbGbYxdjJwcEgImEocv f2KBsMUkLtxbz9bFyMUhJHCYUaLvUh87hLOYUeLSlCagKg4ONgELie5/2iANIgJ+EutXfWAH sYUFHCUufOlnhYg7SWxtboOy9SSeTVgHZrMIqEqsurQOrJ5XwFfi5MaPYDYj0OLvp9YwgdjM AuISt57MZ4I4SEBiyZ7zzBC2qMTLx/9YIWxFiavTl0PV60gs2P2JDcLWlli28DUzxHxBiZMz n7BMYBSehWTsLCQts5C0zELSsoCRZRUje25iZk56udEmRmBYH9zyW3UH451zIocYpTlYlMR5 w10vBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgrFrLkhR8K8zhyZ2Xfmv/v4r8ff4ef/aJ yyc21/Scy5Zm3rSAbz3Dwvnc7SUn+BpeLi3lEl4w4+/v13t+3VoW9qZQqir96NNFEWyp/A23 N9250vt0tmC7cu5834dmq2W3qK5gvS+Y2LLJc/3Uui8zf9z67HlxwmfuDam3mDZf+3ZD1ryU pfY48z4lluKMREMt5qLiRAC//P2AOQIAAA== Subject: Re: [MMUSIC] Feedback requested on requirements - DES F4 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, 17 Apr 2013 09:53:33 -0000 Hi, > DES F4 Multiple separate bundles within one SDP must be supported. I am ok with this, as long as we talk about bundles separated from each oth= er, instead of bundles inside other bundles (DES F5). Regards, Christer From christer.holmberg@ericsson.com Wed Apr 17 03:28: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 609D221F890D for ; Wed, 17 Apr 2013 03:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Lzuoi+mWFpSo for ; Wed, 17 Apr 2013 03:28:08 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 743DB21F88DB for ; Wed, 17 Apr 2013 03:28:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-f5-516e7934719d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 90.4D.03253.4397E615; Wed, 17 Apr 2013 12:28:04 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 12:28:01 +0200 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F6 Thread-Index: Ac47UYHKfE2J6FsfQl6wP7ygguvkCQ== Date: Wed, 17 Apr 2013 10:27:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325E93@ESESSMB208.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+Jvra5JZV6gQX+3sMXU5Y9ZLF6eKHNg 8pi8/yuzx5IlP5kCmKK4bFJSczLLUov07RK4Mi51n2Qp+Mpe8Wn7L/YGxm62LkZODgkBE4ne uxuZIWwxiQv31gPFuTiEBA4zSrTMfMQO4SxmlDiydQOQw8HBJmAh0f1PG6RBRMBPYv2qD+wg trCAo8SCuceZQEpEBJwkJs6IhzD1JE5M1gCpYBFQlfiz/CkjiM0r4Cvx9sl6JhCbEWjt91Nr wGxmAXGJW0/mM0GcIyCxZM95qNNEJV4+/scKYStKXJ2+HKpeR2LB7k9sELa2xLKFr5kh5gtK nJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLzTcxAoP64JbfBjsYN90XO8QozcGi JM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjkcxfv7cBk8JmcLbwf3Z4tONCGf/V OawcohY7iliSWZ9qlhUweu3lvFn9Qdnp7Td5pltdcgZno3yvePKLTja1d7a5JtH240+KQfRk Xx+NSMfURSc6DecfsG08lOI9NeitTKjnptO9Z6/mvSm6tPNjxyLlv713/i3uaJgXFee7izX8 moykVZYSS3FGoqEWc1FxIgCH+F2DOAIAAA== Subject: Re: [MMUSIC] Feedback requested on requirements - DES F6 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, 17 Apr 2013 10:28:09 -0000 Hi, > 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=3D 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=3D 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=3D > lines.) After a first look, I guess it looks ok. Keep in mind, however, that (as far as I remember) an SDP offer/answer must= contain at least one m- line, and bundle doesn't change that. But, that m-= line can of course be outside an bundle group. Regards, Christer From mohamed.boucadair@orange.com Wed Apr 17 04:08: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 6959C21F8D2E for ; Wed, 17 Apr 2013 04:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=0.001] 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 gtJpNgbSwz8m for ; Wed, 17 Apr 2013 04:08:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0B21F8D29 for ; Wed, 17 Apr 2013 04:08:30 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 07DAF2DC389; Wed, 17 Apr 2013 13:08:29 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B08AB23805C; Wed, 17 Apr 2013 13:08:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 17 Apr 2013 13:08:25 +0200 From: To: Flemming Andreasen Date: Wed, 17 Apr 2013 13:08:24 +0200 Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: Ac4332TSMK37vz3wTEi9XIobpQdqaQDcJMYA Message-ID: <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> In-Reply-To: <5168A94B.20608@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 17 Apr 2013 11:08:32 -0000 Hi Felmming, Because it does not allow to indicate an alternate port number. This makes = it a no working solution for various scenarios. The text which triggered this discussion was confusing. I hope the updated = version will be much more clear and reflect what have been discussion so fa= r in this thread. Cheers, Med >-----Message d'origine----- >De : Flemming Andreasen [mailto:fandreas@cisco.com] >Envoy=E9 : samedi 13 avril 2013 02:40 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com; >HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >christer.holmberg@ericsson.com >Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >(draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > >On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >> Hi Simo, >> >> I'm in favor of restricting the alternative address to PSTN. >Can you elaborate on why ? > >We have defined a generic connection data capability as part of a >general capability negotiation framework. What's the point of that if >the only value it can convey is PSTN ? > >Thanks > >-- Flemming > > >> This is coherent whit your first bullet below. >> >> If you share the text changes you are proposing, this would be more >easier to review. >> >> Thanks for taking care of this issue. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la par= t >de >>> Simo.Veikkolainen@nokia.com >>> Envoy=E9 : lundi 8 avril 2013 08:35 >>> =C0 : fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.com >>> Cc : jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.co= m >>> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> Recapping the discussion so far: >>> >>> >>> - ICE is the way to negotiate between different IP addresses. There >seems >>> to be no disagreement here. >>> >>> - since no alternative port number can be expressed, in practice the IN >>> address needs to go to the actual configuration (address in the c=3D li= ne >and >>> port number in the m=3D line), and the alternative PSTN address in the >>> potential configurations. Also here, there seems to be no disagreement. >>> >>> - then, whether the "ccap" attribute should be limited to carry only >PSTN >>> addresses, or also other types. I'm with Flemming on this one; SDP >capneg >>> framework is already fragmented enough, and limiting the connection >address >>> capability to PSTN addresses only would again be targeted for a single >use >>> case only, whereas we should strive for general solutions. >>> >>> Simo >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f >Of >>> ext Flemming Andreasen >>> Sent: 25. maaliskuuta 2013 3:32 >>> To: Andrew Allen >>> Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresse= s >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> >>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>> There is also nothing that prevents people from defining their own >>> proprietary attributes to do such a thing but that is not part of an >IETF >>> standard and is not approved usage. >>> Agreed. >>> >>>> If we really feel the need to discourage further such usage I suppose >we >>> could add some text stating that if CCAP s received containing an IN ne= t >>> type and an IN net type is present in the corresponding Connection >>> Attribute then the CCAP attribute MUST be ignored. >>> I think that gets complicated quickly for a questionable gain. I'd >>> prefer the "MUST NOT" described below with an explanation as to why it'= s >>> there; as you note, ultimately people either decide to be spec complian= t >>> or not. >>> >>> -- Flemming >>>> That way compliant implementations would not perfom the discouraged >>> behavior. >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>> To: Christer Holmberg >>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>> >>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> In general I agree that having multiple ways of doing the same thing >is >>> not a good thing, and I don't have any strong feelings regarding the >ccap >>> usage. >>>>> But, no matter what we say, what would actually prevent people from >>> using ccap, in the same way they are using ANAT and altc? :) >>>> There's no port signaling capability with ccap, but other than that, >the >>>> only thing that prevents people from using this to signal alternative >>>> IP-addresses is the existence of a "MUST NOT" in the spec. >>>> >>>> -- Flemming >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> ________________________________________ >>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of >>> Jonathan Lennox [jonathan@vidyo.com] >>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>> To: Flemming Andreasen >>>>> Cc: mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> Currently, the deployed SIP world has three mechanisms to allow some >>> flavor of negotiation among multiple IP addresses: ICE, altc (despite >the >>> general disapproval of the working group), and ANAT (despite its >>> deprecation). >>>>> I think that adding ccap as a fourth member of this set would be a >>> terrible idea; and as far as I can tell, no one wants to do that. So w= e >>> need to make it clear that that it MUST NOT be used for that purpose. >>>>> In the formulation below, I think I'd say that a given media >description >>> MUST NOT indicate more than one address with an IN network type, across >all >>> its configurations (actual and potential). >>>>> Obviously, different media descriptions (m=3D line blocks) can have >>> different addresses. >>>>> In practice, given the port number issue that started this thread, I >>> suspect this means that the SDP offer will need to put the IN address i= n >>> the actual configuration (in the c=3D line), and the PSTN address(es) w= ill >be >>> in the potential configurations. >>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>> >>>>>> Still waiting for more comments on this, especially from the people >>> that >>>>>> were very vocal in their complaints previously: Now is the time to >>> speak up. >>>>>> Regardless, a few comments on the below: >>>>>> 1) It allows the use of "ccap" to be used to indicate one or more >"IP4" >>>>>> addresses in a given SDP. >>>>>> 2) It allows the use of "ccap" to be used to indicate one or more >"IP6" >>>>>> addresses in a given SDP. >>>>>> >>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>> The "ccap" attribute is not what is being to select between differen= t >>>>>> IP-addresses; the use of a "ccap" attribute in a potential >>> configuration >>>>>> ("pcfg") is what is being used for this. Is the restriction that we >>> want >>>>>> here: >>>>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>>>> attribute with a network type of "IN" ? >>>>>> b) All potential configurations for a particular media description >MUST >>>>>> NOT reference more than one "ccap" attribute with a network type of >>> "IN" ? >>>>>> c) Something else ? >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>> I am OK with either of these proposals >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> I went through the discussion, and my reading is that there is >>> agreement on not allowing ccap to be used for alternative IP address >>> negotiation. >>>>>>> That could be made clear in the text e.g. by modifying the second >>> sentence Flemming quoted to read: >>>>>>> >>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>> between different IP connection addresses (e.g. between >>>>>>> "IP4" and "IP6" address families or different IP addresses >>>>>>> within the same IP address family). >>>>>>> >>>>>>> >>>>>>> The ccap attribute should be able to carry either an IP or PSTN >>> address; that way either a PSTN or an IP bearer could be offered as the >>> highest priority configuration (in the "m=3D" line). However, if we wa= nt >to >>> clarify the intended use of ccap, we could modify the first sentence to >>> read: >>>>>>> >>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>> alternative connection addresses where the >>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>> bearer or a circuit-switched bearer. >>>>>>> >>>>>>> >>>>>>> Simo >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of ext Flemming Andreasen >>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>> To: mmusic >>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresse= s >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> Greetings >>>>>>> >>>>>>> As you may have seen, there has recently been some list discussion >on >>> the "connection data capability" defined in >>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>>>>> >>>>>>> To recap, the connection data capability ("ccap") provides >capability >>> negotiation capabilities for what amounts to the "c=3D" line in regular >SDP, >>> and as such enables negotiation of network type (such as "IN") and IP- >>> address information (v4 and v6 addresses). The Standards Track mechanis= m >>> for negotiating and determining alternative IP-address information toda= y >is >>> ICE, and hence the draft currently includes the following wording: >>>>>>> >>>>>>> The 'ccap' capability attribute is intended to >>>>>>> be used only when there is no other mechanism available for >>>>>>> negotiating alternative connection address information, such >as >>> when >>>>>>> the is different among the alternative addresses >(e.g. >>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>>>> situations where an existing mechanism (such as Interactive >>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to >>> select >>>>>>> between different connection addresses (e.g. "IP4" and "IP6= " >or >>>>>>> different IP addresses within the same IP address family). >>>>>>> >>>>>>> >>>>>>> The above text has led to some confusion as to exactly when and wha= t >>> "ccap" can be used for. More specifically, is it/should it ever be >allowed >>> to use "ccap" to convey an IP4 or IP6 address, and if so, under what >>> circumstances ? >>>>>>> If you have an opinion, please let us know. >>>>>>> >>>>>>> A couple of points to keep in mind: >>>>>>> - The current document has been WGLC'ed without comment ~6 months >ago. >>>>>>> - 3GPP has a dependency on the document (however I'm not sure if >that >>> dependency includes the above "IN" feature) >>>>>>> - The connection data capability is defined in a general manner to >be >>> generally useful in line with the overall capability negotiation >framework >>> (as opposed to targeted at one specific use case with one specific >value) >>>>>>> - There are scenarios where ICE cannot be used, even if implemented >>> (e.g. ice-mismatch). >>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >absence >>> of ICE support >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- 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 >>>>>>> >>>>>>> -------------------------------------------------------------------= - >- >>>>>>> This transmission (including any attachments) may contain >confidential >>> information, privileged material (including material protected by the >>> solicitor-client or other applicable privileges), or constitute non- >public >>> information. Any use of this information by anyone other than the >intended >>> recipient is prohibited. If you have received this transmission in >error, >>> please immediately reply to the sender and delete this information from >>> your system. Use, dissemination, distribution, or reproduction of this >>> transmission by unintended recipients is not authorized and may be >>> unlawful. >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> -- >>>>> Jonathan Lennox >>>>> jonathan@vidyo.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential >>> information, privileged material (including material protected by the >>> solicitor-client or other applicable privileges), or constitute non- >public >>> information. Any use of this information by anyone other than the >intended >>> recipient is prohibited. If you have received this transmission in >error, >>> please immediately reply to the sender and delete this information from >>> your system. Use, dissemination, distribution, or reproduction of this >>> transmission by unintended recipients is not authorized and may be >>> unlawful. >>>> . >>>> >>> _______________________________________________ >>> 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 Wed Apr 17 04:22: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 9435421F8DD6 for ; Wed, 17 Apr 2013 04:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 JuzRmHi6O37p for ; Wed, 17 Apr 2013 04:22:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3221F8AE7 for ; Wed, 17 Apr 2013 04:22:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-42-516e85de8562 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FA.F7.03253.ED58E615; Wed, 17 Apr 2013 13:22:06 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 13:22:06 +0200 From: Christer Holmberg To: Magnus Westerlund , "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F7 Thread-Index: Ac47XPdNc1cfo1BQSw+P0DFHVeanVg== Date: Wed, 17 Apr 2013 11:22:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325F6C@ESESSMB208.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+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvre691rxAgxmH9S2mLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfG/8w9jwS+Oiuk/qhsYP7N1MXJySAiYSOzv ecsEYYtJXLi3HijOxSEkcJhRYk3TblYIZzGjxLbdd4EcDg42AQuJ7n/aIA0iAvESM7s3MIKE mQXUJa4uDgIJCws4Slw7e50ZosRJ4t2dd2wQtp7Ezx+7GEFsFgFViW07V4HV8Ar4SixetwSs hhHohu+n1oDdwywgLnHryXyo2wQkluw5zwxhi0q8fPyPFcJWlLg6fTlUvY7Egt2f2CBsbYll C19DzReUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXm29iBAb7wS2/DXYwbrov dohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGvxt+W1g2vlE6aqA1seFx 6awKZ/7CX46P/Xb86LptzOpd4LN8pVJj1/IfNw+tjjITubJuWxT/5Zu3WafXqfZPk2Rdff+b 8UVmnX7L1Llpc/IuXfm6Ofzfgb0JJY0J7JfjAvtTV3jFL1FYKGh0cebOprRnnTcqvrEZq5yf dTvETD3uoMvmpmv6SizFGYmGWsxFxYkASGKh2kQCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements - DES F7 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, 17 Apr 2013 11:22:13 -0000 Hi, >> 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. > > If you with "constituent RTP session within it" where it is a bundle mean= s the RTP media streams resulting from that particular SDP media descriptio= n (m=3D block) then I believe I agree with 1). Agree. It shall be possible to reject/accept each m- line individually. > When it comes to 2) what makes this different from rejecting each m=3D bl= ock within the bundle? Agree. Putting the port to zero is the SDP offer/answer mechanism for rejec= ting an m- line, and bundle doesn't change that.=20 > 3) is required if legacy fallback at all going to be available. As currently specified, this is achieved by sending a "legacy" SDP answer, = without bundle. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 17 04:26: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 3DC2121F8E04 for ; Wed, 17 Apr 2013 04:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 QSIO9lZNqJq0 for ; Wed, 17 Apr 2013 04:26:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7498F21F8DE4 for ; Wed, 17 Apr 2013 04:26:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-fa-516e86f6661a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 27.92.10459.6F68E615; Wed, 17 Apr 2013 13:26:46 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 13:26:45 +0200 From: Christer Holmberg To: Magnus Westerlund , "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F11 Thread-Index: Ac47XdMZ5nejwfrkTXS9HizSQez/1w== Date: Wed, 17 Apr 2013 11:26:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325F83@ESESSMB208.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+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvre63trxAg/3flC2mLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTHpwR3mgvlsFUfPNLI2ML5n6WLk5JAQMJFY 830tM4QtJnHh3nq2LkYuDiGBw4wSJ/bfYIRwFjNKzPzXB9TBwcEmYCHR/U8bpEFEIF5iZvcG RpAws4C6xNXFQSBhYQEnicbWuSwQJc4Sz3a+YoWw9SS2PXrEDmKzCKhKXH8yiwnE5hXwlXg5 dTmYzQh0w/dTa8BsZgFxiVtP5jNB3CYgsWTPeag7RSVePv7HCmErSlydvhyqXkdiwe5PbBC2 tsSyha+ZIeYLSpyc+YRlAqPILCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSyw03MQLD/eCW37o7 GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo3Cm0blIxvOThaPc T65/vvN3lc63vSF1GdE1adavNk/nuFEQwM8UWln9PX3ak6CaF3qmAhyT/NkMV3BJPOVLXi7V l8SW/nipX4I5f8A5gYSTzO9PLBB26Uw/3P/9uV++ZbiugVJOvEhsjJyKh/ruAy9WJYTXbznM +YD/5evCXzkbnfjrjCcrsRRnJBpqMRcVJwIAvwi50kUCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements - DES F11 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, 17 Apr 2013 11:26:48 -0000 Hi, >> DES F11 It must be possible to add and remove one way video flows >> within the bundle without requiring an additional offer/answer >> cycle. > > I think this is desirable and possible to support in certain types of app= lications. Some do require=20 > additional information that needs to be signalled somewhere. If one have = chose O/A for that transport=20 > then this requirement can't be meet. However, I do agree with the intenti= on that it should be possible. It has been said that, if e.g. sending multiple media streams/flows per m- = line, then adding/removing of flows "within" that m- line may not require o= ffer/answer cycles. However, how streams/flows are added/removed is, in my opinion, not a bundl= e issue. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 17 04:29: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 AE9AB21F8BC7 for ; Wed, 17 Apr 2013 04:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 T9facCw6KR7N for ; Wed, 17 Apr 2013 04:29:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA76D21F8721 for ; Wed, 17 Apr 2013 04:29:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-56-516e877e949b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 05.20.19728.E778E615; Wed, 17 Apr 2013 13:29:02 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 13:29:01 +0200 From: Christer Holmberg To: Magnus Westerlund , "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F12 Thread-Index: Ac47XndkcAKKkofMSpSnF1VtDqW7xw== Date: Wed, 17 Apr 2013 11:29:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325FA2@ESESSMB208.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+NgFtrELMWRmVeSWpSXmKPExsUyM+JvrW5de16gQctxA4upyx+zWLw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZZxvvcpWsJu1YsLKk+wNjLNZuhg5OSQETCTm fe9nhLDFJC7cW8/WxcjFISRwmFHi7cLvjBDOYkaJv593A2U4ONgELCS6/2mDNIgIxEvM7N7A CBJmFlCXuLo4CCQsLOAk8e/hcyaIEmeJRX9WskHYehJtX9rBdrEIqEqsbnjPDGLzCvhKfH20 GOweRqAbvp9aA9bLLCAucevJfCaI2wQkluw5zwxhi0q8fPyPFcJWlLg6fTlUvY7Egt2f2CBs bYllC19DzReUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG21iBIb7wS2/VXcw 3jkncohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGyUuTu+IOnDufdl10 9w2meF72O66Rty8cblgyzT5oZcGqBWwmCsY+ChV5Szn3MHS0RM6yNziwIL1UonxNxWn27/sZ 7PkDqvuPqkcWdFa+CVi0kXHfyaR4rokay5kYeiKdZA/u/vW8KLjfffMcpspV5RaZrJuS/X/6 X9wf5mX8+OPJrrvHV6cqsRRnJBpqMRcVJwIA3j8EMEUCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements - DES F12 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, 17 Apr 2013 11:29:04 -0000 Hi, >> DES F12 Bundling must not interfere with ICE usage, and in >> particular, ICE's ability to negotiate both IPv4 and IPv6 >> addresses simultaneously. > > I believe the intention is right here, but I stumble on the word "negotia= te". To my=20 > understanding the usage of two address families are not really negotiated= . It is more,=20 > here are my candidates, create candidate pairs within each family and the= n follow the=20 > check-board algorithm. Agree. I don't think bundle restricts the usage of ICE - it only allows you= to use the same set of candidates (IPv4, IPv6, or whatever) for every m- l= ine within the bundle. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 17 04:39: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 C2D6F21F8C30 for ; Wed, 17 Apr 2013 04:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 2I4I3IEalDNm for ; Wed, 17 Apr 2013 04:39:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDB21F8C23 for ; Wed, 17 Apr 2013 04:39:58 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-e5-516e8a0d5fa8 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 73.32.19728.D0A8E615; Wed, 17 Apr 2013 13:39:57 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 13:39:56 +0200 From: Christer Holmberg To: Magnus Westerlund , "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements - DES F13 Thread-Index: Ac47XwvLqAipBdx+TBOrEzZ479qZhg== Date: Wed, 17 Apr 2013 11:39:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C325FB9@ESESSMB208.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+NgFtrALMWRmVeSWpSXmKPExsUyM+JvrS5vV16gQc98HYupyx+zWLw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZbSs/MBYsIW94tKJOSwNjFdYuxg5OSQETCRO LVjCCGGLSVy4t56ti5GLQ0jgMKPEl20H2SGcxYwSU6YvYupi5OBgE7CQ6P6nDdIgIhAvMbN7 AyNImFlAXeLq4iAQU1jASeLyi0qICmeJKZfuMkHYehIzjp4CW8UioCpx5OhyZpByXgFfidn/ LUDCjEAXfD+1BqycWUBc4taT+UwQlwlILNlznhnCFpV4+fgf1PWKElenL4eq15FYsPsTG4St LbFs4Wuwel4BQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernRJkZgqB/c8lt1 B+OdcyKHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYPRyyNt9bvFL020t R9RTVMQSY/duufjLO8txZXvShlLtTo9ME9GXb/2c+V6kJrGLRKqeO3PrptnW94VTpup379Hm j66x7OZzr/HMe39rl8K2R+tenPKyWMedfqTtuHoui9zMBXFHRH7KyE+U2PFOLsO9IzJZ/rM7 n/qVQnd9zs3Su/2CY7l2K7EUZyQaajEXFScCAEatfAxDAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements - DES F13 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, 17 Apr 2013 11:39:59 -0000 Hi, >> DES F13 It is desirable for RTP media to appear on the wire as >> (encrypted) SRTP packets and for RTCP reports to appear on the >> wire as (authenticated but not encrypted) SRTCP packets. Thus, >> encryption of RTP/RTCP via DTLS and encapsulation of multiplexed >> packets is not desirable. > > I am not certain I understand the motivations for this requirement. Is th= e need to having unencrypted RTCP for=20 > third party monitors? From a security point of view I see issues with suc= h blanket statements. There can be information=20 > in the RTCP that is sensitive for privacy reasons. > > For the last sentence are you really meaning DTLS or DTLS-SRTP. There is = a big difference here. I am not sure I understand why this is bundle specific. If you are talking about a case where RTP and RTCP use the same 5-tuple, th= at is an rtcpmux (RFC 5761) issue. Regards, Christer From fandreas@cisco.com Wed Apr 17 07:32: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 3355021F8615 for ; Wed, 17 Apr 2013 07:32:55 -0700 (PDT) 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_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 tRJMEKqOsNYj for ; Wed, 17 Apr 2013 07:32:53 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D96EB21F8614 for ; Wed, 17 Apr 2013 07:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16280; q=dns/txt; s=iport; t=1366209173; x=1367418773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lCMajeV5SiKN+2kXejD5Sq+AMmC5ouicoNYCEzapNEs=; b=XFJneh8kgBqH4rzwCK11btDLfgKrl+UPD1jkInD+AIt/EbgfhGtq4E6n n5N846gaEipbG5u4N1z2a/WU8Wcim36acExJDuGZfhu1DaUh2/9Cb/+a+ 7IieTRMjCPYZac7sLyv9IkdhA3zWgENOMH9TJNK8LeGz63hzMhZzPIY3R E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFixblGrRDoG/2dsb2JhbABQgwY2wQyBAxZ0gh8BAQEDAQEBAS8BBTQCCAIBBQcECxEEAQEBCRYEBAcJAwIBAgEVHwkIEwEFAgEBBRKHcwUNvUuNYgaBJwsHBoNAA5cGkRSBVYFSIIEuCRc X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="75798384" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Apr 2013 14:32:53 +0000 Received: from Flemmings-MacBook-Pro.local (che-vpn-cluster-2-15.cisco.com [10.86.242.15]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HEWhcj018511; Wed, 17 Apr 2013 14:32:44 GMT Message-ID: <516EB28A.1050003@cisco.com> Date: Wed, 17 Apr 2013 10:32:42 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 17 Apr 2013 14:32:55 -0000 On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: > Hi Felmming, > > Because it does not allow to indicate an alternate port number. Correct - a connection address does not provide a port number; a different capability would be needed for that. > This makes it a no working solution for various scenarios. No - it simply means that you would need to define another capability to convey port numbers if you wanted such a solution (however we have ICE as the complete solution for that and the WG has not indicated a desire to change that). > The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread. I have asked Simo to update the draft. Thanks -- Flemming > Cheers, > Med > >> -----Message d'origine----- >> De : Flemming Andreasen [mailto:fandreas@cisco.com] >> Envoyé : samedi 13 avril 2013 02:40 >> À : BOUCADAIR Mohamed OLNC/OLN >> Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com; >> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >> christer.holmberg@ericsson.com >> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>> Hi Simo, >>> >>> I'm in favor of restricting the alternative address to PSTN. >> Can you elaborate on why ? >> >> We have defined a generic connection data capability as part of a >> general capability negotiation framework. What's the point of that if >> the only value it can convey is PSTN ? >> >> Thanks >> >> -- Flemming >> >> >>> This is coherent whit your first bullet below. >>> >>> If you share the text changes you are proposing, this would be more >> easier to review. >>> Thanks for taking care of this issue. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part >> de >>>> Simo.Veikkolainen@nokia.com >>>> Envoyé : lundi 8 avril 2013 08:35 >>>> À : fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.com >>>> Cc : jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >>>> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> Recapping the discussion so far: >>>> >>>> >>>> - ICE is the way to negotiate between different IP addresses. There >> seems >>>> to be no disagreement here. >>>> >>>> - since no alternative port number can be expressed, in practice the IN >>>> address needs to go to the actual configuration (address in the c= line >> and >>>> port number in the m= line), and the alternative PSTN address in the >>>> potential configurations. Also here, there seems to be no disagreement. >>>> >>>> - then, whether the "ccap" attribute should be limited to carry only >> PSTN >>>> addresses, or also other types. I'm with Flemming on this one; SDP >> capneg >>>> framework is already fragmented enough, and limiting the connection >> address >>>> capability to PSTN addresses only would again be targeted for a single >> use >>>> case only, whereas we should strive for general solutions. >>>> >>>> Simo >>>> >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of >>>> ext Flemming Andreasen >>>> Sent: 25. maaliskuuta 2013 3:32 >>>> To: Andrew Allen >>>> Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com >>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> >>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>> There is also nothing that prevents people from defining their own >>>> proprietary attributes to do such a thing but that is not part of an >> IETF >>>> standard and is not approved usage. >>>> Agreed. >>>> >>>>> If we really feel the need to discourage further such usage I suppose >> we >>>> could add some text stating that if CCAP s received containing an IN net >>>> type and an IN net type is present in the corresponding Connection >>>> Attribute then the CCAP attribute MUST be ignored. >>>> I think that gets complicated quickly for a questionable gain. I'd >>>> prefer the "MUST NOT" described below with an explanation as to why it's >>>> there; as you note, ultimately people either decide to be spec compliant >>>> or not. >>>> >>>> -- Flemming >>>>> That way compliant implementations would not perfom the discouraged >>>> behavior. >>>>> Andrew >>>>> >>>>> ----- Original Message ----- >>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>> To: Christer Holmberg >>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>> >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> In general I agree that having multiple ways of doing the same thing >> is >>>> not a good thing, and I don't have any strong feelings regarding the >> ccap >>>> usage. >>>>>> But, no matter what we say, what would actually prevent people from >>>> using ccap, in the same way they are using ANAT and altc? :) >>>>> There's no port signaling capability with ccap, but other than that, >> the >>>>> only thing that prevents people from using this to signal alternative >>>>> IP-addresses is the existence of a "MUST NOT" in the spec. >>>>> >>>>> -- Flemming >>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of >>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>> To: Flemming Andreasen >>>>>> Cc: mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> Currently, the deployed SIP world has three mechanisms to allow some >>>> flavor of negotiation among multiple IP addresses: ICE, altc (despite >> the >>>> general disapproval of the working group), and ANAT (despite its >>>> deprecation). >>>>>> I think that adding ccap as a fourth member of this set would be a >>>> terrible idea; and as far as I can tell, no one wants to do that. So we >>>> need to make it clear that that it MUST NOT be used for that purpose. >>>>>> In the formulation below, I think I'd say that a given media >> description >>>> MUST NOT indicate more than one address with an IN network type, across >> all >>>> its configurations (actual and potential). >>>>>> Obviously, different media descriptions (m= line blocks) can have >>>> different addresses. >>>>>> In practice, given the port number issue that started this thread, I >>>> suspect this means that the SDP offer will need to put the IN address in >>>> the actual configuration (in the c= line), and the PSTN address(es) will >> be >>>> in the potential configurations. >>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>> >>>>>>> Still waiting for more comments on this, especially from the people >>>> that >>>>>>> were very vocal in their complaints previously: Now is the time to >>>> speak up. >>>>>>> Regardless, a few comments on the below: >>>>>>> 1) It allows the use of "ccap" to be used to indicate one or more >> "IP4" >>>>>>> addresses in a given SDP. >>>>>>> 2) It allows the use of "ccap" to be used to indicate one or more >> "IP6" >>>>>>> addresses in a given SDP. >>>>>>> >>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>> The "ccap" attribute is not what is being to select between different >>>>>>> IP-addresses; the use of a "ccap" attribute in a potential >>>> configuration >>>>>>> ("pcfg") is what is being used for this. Is the restriction that we >>>> want >>>>>>> here: >>>>>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>>>>> attribute with a network type of "IN" ? >>>>>>> b) All potential configurations for a particular media description >> MUST >>>>>>> NOT reference more than one "ccap" attribute with a network type of >>>> "IN" ? >>>>>>> c) Something else ? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>> I am OK with either of these proposals >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>> I went through the discussion, and my reading is that there is >>>> agreement on not allowing ccap to be used for alternative IP address >>>> negotiation. >>>>>>>> That could be made clear in the text e.g. by modifying the second >>>> sentence Flemming quoted to read: >>>>>>>> >>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>> between different IP connection addresses (e.g. between >>>>>>>> "IP4" and "IP6" address families or different IP addresses >>>>>>>> within the same IP address family). >>>>>>>> >>>>>>>> >>>>>>>> The ccap attribute should be able to carry either an IP or PSTN >>>> address; that way either a PSTN or an IP bearer could be offered as the >>>> highest priority configuration (in the "m=" line). However, if we want >> to >>>> clarify the intended use of ccap, we could modify the first sentence to >>>> read: >>>>>>>> >>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>> alternative connection addresses where the >>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>> bearer or a circuit-switched bearer. >>>>>>>> >>>>>>>> >>>>>>>> Simo >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of ext Flemming Andreasen >>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>> To: mmusic >>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>> Greetings >>>>>>>> >>>>>>>> As you may have seen, there has recently been some list discussion >> on >>>> the "connection data capability" defined in >>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>>>>>>> >>>>>>>> To recap, the connection data capability ("ccap") provides >> capability >>>> negotiation capabilities for what amounts to the "c=" line in regular >> SDP, >>>> and as such enables negotiation of network type (such as "IN") and IP- >>>> address information (v4 and v6 addresses). The Standards Track mechanism >>>> for negotiating and determining alternative IP-address information today >> is >>>> ICE, and hence the draft currently includes the following wording: >>>>>>>> >>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>> be used only when there is no other mechanism available for >>>>>>>> negotiating alternative connection address information, such >> as >>>> when >>>>>>>> the is different among the alternative addresses >> (e.g. >>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>>>>> situations where an existing mechanism (such as Interactive >>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to >>>> select >>>>>>>> between different connection addresses (e.g. "IP4" and "IP6" >> or >>>>>>>> different IP addresses within the same IP address family). >>>>>>>> >>>>>>>> >>>>>>>> The above text has led to some confusion as to exactly when and what >>>> "ccap" can be used for. More specifically, is it/should it ever be >> allowed >>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under what >>>> circumstances ? >>>>>>>> If you have an opinion, please let us know. >>>>>>>> >>>>>>>> A couple of points to keep in mind: >>>>>>>> - The current document has been WGLC'ed without comment ~6 months >> ago. >>>>>>>> - 3GPP has a dependency on the document (however I'm not sure if >> that >>>> dependency includes the above "IN" feature) >>>>>>>> - The connection data capability is defined in a general manner to >> be >>>> generally useful in line with the overall capability negotiation >> framework >>>> (as opposed to targeted at one specific use case with one specific >> value) >>>>>>>> - There are scenarios where ICE cannot be used, even if implemented >>>> (e.g. ice-mismatch). >>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >> absence >>>> of ICE support >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- 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 >>>>>>>> >>>>>>>> -------------------------------------------------------------------- >> - >>>>>>>> This transmission (including any attachments) may contain >> confidential >>>> information, privileged material (including material protected by the >>>> solicitor-client or other applicable privileges), or constitute non- >> public >>>> information. Any use of this information by anyone other than the >> intended >>>> recipient is prohibited. If you have received this transmission in >> error, >>>> please immediately reply to the sender and delete this information from >>>> your system. Use, dissemination, distribution, or reproduction of this >>>> transmission by unintended recipients is not authorized and may be >>>> unlawful. >>>>>>>> . >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>> -- >>>>>> Jonathan Lennox >>>>>> jonathan@vidyo.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential >>>> information, privileged material (including material protected by the >>>> solicitor-client or other applicable privileges), or constitute non- >> public >>>> information. Any use of this information by anyone other than the >> intended >>>> recipient is prohibited. If you have received this transmission in >> error, >>>> please immediately reply to the sender and delete this information from >>>> your system. Use, dissemination, distribution, or reproduction of this >>>> transmission by unintended recipients is not authorized and may be >>>> unlawful. >>>>> . >>>>> >>>> _______________________________________________ >>>> 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 Wed Apr 17 14:07: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 3B87C21E80A8 for ; Wed, 17 Apr 2013 14:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.039, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf-Y7Cm-WN0c for ; Wed, 17 Apr 2013 14:07:08 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A82B321E80B0 for ; Wed, 17 Apr 2013 14:07:08 -0700 (PDT) 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 r3HL6wQN011966 for ; Wed, 17 Apr 2013 17:07:00 -0400 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 r3HL6w7p2893725 for ; Wed, 17 Apr 2013 17:06:58 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3HL6wir2892699; Wed, 17 Apr 2013 17:06:58 -0400 (EDT) Date: Wed, 17 Apr 2013 17:06:58 -0400 (EDT) Message-Id: <201304172106.r3HL6wir2892699@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <516C071B.5050204@ericsson.com> (ari.keranen@ericsson.com) References: <516C071B.5050204@ericsson.com> Subject: Re: [MMUSIC] Confirming consensus on way forward with 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: Wed, 17 Apr 2013 21:07:09 -0000 > From: Ari KerC$nen > > At the Orlando meeting we had a call for consensus (see the minutes of > the meeting at [1]) on using the current SDP bundle WG document [2] as > the baseline of the bundle work. That is, using the offer/answer > exchange as outlined in the draft (subject to clarifying comments made > during the meeting) and using the port numbers as described in the draft. I am not convinced that draft-ietf-mmusic-sdp-bundle-negotiation-03 is the best approach. In particular, I think the approach in the MMT proposal would be an improvement, where there is a separate m= line to describe the bundle as a whole, as opposed to just specifying that certain flows are to share a port. Unfortunately, I've not seen some of the earlier parts of the discussion, and there may have been a discussion why having a bundle m= line is undesirable. Dale From worley@shell01.TheWorld.com Wed Apr 17 14: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 100CE21F8201 for ; Wed, 17 Apr 2013 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SUBJECT_FUZZY_TION=0.156] 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 uKRXpRI2FbfN for ; Wed, 17 Apr 2013 14:08:11 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 14F1121E80D3 for ; Wed, 17 Apr 2013 14:08:09 -0700 (PDT) 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 r3HL7Gpv023961 for ; Wed, 17 Apr 2013 17:07:18 -0400 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 r3HL7G1q2887859 for ; Wed, 17 Apr 2013 17:07:16 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3HL7Fdt2897721; Wed, 17 Apr 2013 17:07:15 -0400 (EDT) Date: Wed, 17 Apr 2013 17:07:15 -0400 (EDT) Message-Id: <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com) References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-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: Wed, 17 Apr 2013 21:08:12 -0000 It seems to me that the essence of draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE candidates to effectively specify two address/ports that is available for the remote UA to contact this UA. One address/port is the standard ICE address/port and the other is the "bundleport", and indicates an address/port that the remote UA can contact using bundled/multiplexed media. If the candidates for two different m= lines specify the same bundleport, it would be useful to define the ICE procedures to ensure that connectivity to that address/port is tested only once for any remote address/port. If the remote UA is not bundling/multiplexing, this does not change anything, as connectivity has to be tested separately for each transport association (5-tuple). But if both ends are using bundling, we could have 3 m= lines for each UA, but only effectively one set of candidate address/ports at each end. We wouldn't want to repeat the connectivity checks 3 times over. Also, what is the order of testing of ICE candidates if bundleport is present? My understanding is that ICE was carefully designed so that both UAs test each candidate pair simultaneously. What is the timing/sequencing rules when bundleport is present to ensure that (1) both UAs test each pair simultaneously, (2) the bundleport address/ports are tested first if both ends support bundling, and (3) the timing of "baseline" candidate testing is unchanged if either UA does not support bundling? It seems like we need a careful specification of the changes to the candidate testing algorithm. Dale From mohamed.boucadair@orange.com Thu Apr 18 02:27: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 83A2F21F8E9E for ; Thu, 18 Apr 2013 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=0.001] 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 GLA-zVbB5SWs for ; Thu, 18 Apr 2013 02:27:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B8B8421F8E8E for ; Thu, 18 Apr 2013 02:27:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 26EE522C3A5; Thu, 18 Apr 2013 11:27:55 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 02D8A35C065; Thu, 18 Apr 2013 11:27:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 18 Apr 2013 11:27:54 +0200 From: To: Flemming Andreasen Date: Thu, 18 Apr 2013 11:27:53 +0200 Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: Ac47eHShPmuTxsmGRnCY1BJU1UASmwAhXKmg Message-ID: <94C682931C08B048B7A8645303FDC9F36EC73F1950@PUEXCB1B.nanterre.francetelecom.fr> References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> In-Reply-To: <516EB28A.1050003@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.18.90020 Cc: "jonathan@vidyo.com" , "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 18 Apr 2013 09:27:57 -0000 Hi Fleming, Please see inline. Cheers, Med >-----Message d'origine----- >De : Flemming Andreasen [mailto:fandreas@cisco.com] >Envoy=E9 : mercredi 17 avril 2013 16:33 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com; >HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >christer.holmberg@ericsson.com >Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >(draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > >On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: >> Hi Felmming, >> >> Because it does not allow to indicate an alternate port number. >Correct - a connection address does not provide a port number; a >different capability would be needed for that. >> This makes it a no working solution for various scenarios. >No - it simply means that you would need to define another capability to >convey port numbers if you wanted such a solution (however we have ICE >as the complete solution for that and the WG has not indicated a desire >to change that). [Med] Yes, I understood the wg does not want to change and extend the capab= ility to cover more than the PSTN case. > >> The text which triggered this discussion was confusing. I hope the >updated version will be much more clear and reflect what have been >discussion so far in this thread. >I have asked Simo to update the draft. [Med] Ok, thanks. > >Thanks > >-- Flemming > > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Flemming Andreasen [mailto:fandreas@cisco.com] >>> Envoy=E9 : samedi 13 avril 2013 02:40 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com; >>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >>> christer.holmberg@ericsson.com >>> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> >>> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Simo, >>>> >>>> I'm in favor of restricting the alternative address to PSTN. >>> Can you elaborate on why ? >>> >>> We have defined a generic connection data capability as part of a >>> general capability negotiation framework. What's the point of that if >>> the only value it can convey is PSTN ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> This is coherent whit your first bullet below. >>>> >>>> If you share the text changes you are proposing, this would be more >>> easier to review. >>>> Thanks for taking care of this issue. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la >part >>> de >>>>> Simo.Veikkolainen@nokia.com >>>>> Envoy=E9 : lundi 8 avril 2013 08:35 >>>>> =C0 : fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.c= om >>>>> Cc : jonathan@vidyo.com; mmusic@ietf.org; >christer.holmberg@ericsson.com >>>>> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Recapping the discussion so far: >>>>> >>>>> >>>>> - ICE is the way to negotiate between different IP addresses. There >>> seems >>>>> to be no disagreement here. >>>>> >>>>> - since no alternative port number can be expressed, in practice the >IN >>>>> address needs to go to the actual configuration (address in the c=3D >line >>> and >>>>> port number in the m=3D line), and the alternative PSTN address in th= e >>>>> potential configurations. Also here, there seems to be no >disagreement. >>>>> >>>>> - then, whether the "ccap" attribute should be limited to carry only >>> PSTN >>>>> addresses, or also other types. I'm with Flemming on this one; SDP >>> capneg >>>>> framework is already fragmented enough, and limiting the connection >>> address >>>>> capability to PSTN addresses only would again be targeted for a singl= e >>> use >>>>> case only, whereas we should strive for general solutions. >>>>> >>>>> Simo >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >Behalf >>> Of >>>>> ext Flemming Andreasen >>>>> Sent: 25. maaliskuuta 2013 3:32 >>>>> To: Andrew Allen >>>>> Cc: jonathan@vidyo.com; mmusic@ietf.org; >christer.holmberg@ericsson.com >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> >>>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>>> There is also nothing that prevents people from defining their own >>>>> proprietary attributes to do such a thing but that is not part of an >>> IETF >>>>> standard and is not approved usage. >>>>> Agreed. >>>>> >>>>>> If we really feel the need to discourage further such usage I suppos= e >>> we >>>>> could add some text stating that if CCAP s received containing an IN >net >>>>> type and an IN net type is present in the corresponding Connection >>>>> Attribute then the CCAP attribute MUST be ignored. >>>>> I think that gets complicated quickly for a questionable gain. I'd >>>>> prefer the "MUST NOT" described below with an explanation as to why >it's >>>>> there; as you note, ultimately people either decide to be spec >compliant >>>>> or not. >>>>> >>>>> -- Flemming >>>>>> That way compliant implementations would not perfom the discouraged >>>>> behavior. >>>>>> Andrew >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>>> To: Christer Holmberg >>>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>>> >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and >IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In general I agree that having multiple ways of doing the same thin= g >>> is >>>>> not a good thing, and I don't have any strong feelings regarding the >>> ccap >>>>> usage. >>>>>>> But, no matter what we say, what would actually prevent people from >>>>> using ccap, in the same way they are using ANAT and altc? :) >>>>>> There's no port signaling capability with ccap, but other than that, >>> the >>>>>> only thing that prevents people from using this to signal alternativ= e >>>>>> IP-addresses is the existence of a "MUST NOT" in the spec. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf o= f >>>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>>> To: Flemming Andreasen >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> Currently, the deployed SIP world has three mechanisms to allow som= e >>>>> flavor of negotiation among multiple IP addresses: ICE, altc (despite >>> the >>>>> general disapproval of the working group), and ANAT (despite its >>>>> deprecation). >>>>>>> I think that adding ccap as a fourth member of this set would be a >>>>> terrible idea; and as far as I can tell, no one wants to do that. So >we >>>>> need to make it clear that that it MUST NOT be used for that purpose. >>>>>>> In the formulation below, I think I'd say that a given media >>> description >>>>> MUST NOT indicate more than one address with an IN network type, >across >>> all >>>>> its configurations (actual and potential). >>>>>>> Obviously, different media descriptions (m=3D line blocks) can have >>>>> different addresses. >>>>>>> In practice, given the port number issue that started this thread, = I >>>>> suspect this means that the SDP offer will need to put the IN address >in >>>>> the actual configuration (in the c=3D line), and the PSTN address(es) >will >>> be >>>>> in the potential configurations. >>>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> Still waiting for more comments on this, especially from the peopl= e >>>>> that >>>>>>>> were very vocal in their complaints previously: Now is the time to >>>>> speak up. >>>>>>>> Regardless, a few comments on the below: >>>>>>>> 1) It allows the use of "ccap" to be used to indicate one or more >>> "IP4" >>>>>>>> addresses in a given SDP. >>>>>>>> 2) It allows the use of "ccap" to be used to indicate one or more >>> "IP6" >>>>>>>> addresses in a given SDP. >>>>>>>> >>>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>>> The "ccap" attribute is not what is being to select between >different >>>>>>>> IP-addresses; the use of a "ccap" attribute in a potential >>>>> configuration >>>>>>>> ("pcfg") is what is being used for this. Is the restriction that w= e >>>>> want >>>>>>>> here: >>>>>>>> a) A potential configuration MUST NOT reference more than one >"ccap" >>>>>>>> attribute with a network type of "IN" ? >>>>>>>> b) All potential configurations for a particular media description >>> MUST >>>>>>>> NOT reference more than one "ccap" attribute with a network type o= f >>>>> "IN" ? >>>>>>>> c) Something else ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>>> I am OK with either of these proposals >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> I went through the discussion, and my reading is that there is >>>>> agreement on not allowing ccap to be used for alternative IP address >>>>> negotiation. >>>>>>>>> That could be made clear in the text e.g. by modifying the second >>>>> sentence Flemming quoted to read: >>>>>>>>> >>>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>>> between different IP connection addresses (e.g. between >>>>>>>>> "IP4" and "IP6" address families or different IP addresse= s >>>>>>>>> within the same IP address family). >>>>>>>>> >>>>>>>>> >>>>>>>>> The ccap attribute should be able to carry either an IP or PSTN >>>>> address; that way either a PSTN or an IP bearer could be offered as >the >>>>> highest priority configuration (in the "m=3D" line). However, if we >want >>> to >>>>> clarify the intended use of ccap, we could modify the first sentence >to >>>>> read: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>>> alternative connection addresses where the >>>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>>> bearer or a circuit-switched bearer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Simo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>>> Behalf Of ext Flemming Andreasen >>>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>>> To: mmusic >>>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and IP- >addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> As you may have seen, there has recently been some list discussio= n >>> on >>>>> the "connection data capability" defined in >>>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html= ) >>>>>>>>> >>>>>>>>> To recap, the connection data capability ("ccap") provides >>> capability >>>>> negotiation capabilities for what amounts to the "c=3D" line in regul= ar >>> SDP, >>>>> and as such enables negotiation of network type (such as "IN") and IP= - >>>>> address information (v4 and v6 addresses). The Standards Track >mechanism >>>>> for negotiating and determining alternative IP-address information >today >>> is >>>>> ICE, and hence the draft currently includes the following wording: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>>> be used only when there is no other mechanism available >for >>>>>>>>> negotiating alternative connection address information, >such >>> as >>>>> when >>>>>>>>> the is different among the alternative addresse= s >>> (e.g. >>>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used >in >>>>>>>>> situations where an existing mechanism (such as >Interactive >>>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used t= o >>>>> select >>>>>>>>> between different connection addresses (e.g. "IP4" and >"IP6" >>> or >>>>>>>>> different IP addresses within the same IP address family)= . >>>>>>>>> >>>>>>>>> >>>>>>>>> The above text has led to some confusion as to exactly when and >what >>>>> "ccap" can be used for. More specifically, is it/should it ever be >>> allowed >>>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under what >>>>> circumstances ? >>>>>>>>> If you have an opinion, please let us know. >>>>>>>>> >>>>>>>>> A couple of points to keep in mind: >>>>>>>>> - The current document has been WGLC'ed without comment ~6 months >>> ago. >>>>>>>>> - 3GPP has a dependency on the document (however I'm not sure if >>> that >>>>> dependency includes the above "IN" feature) >>>>>>>>> - The connection data capability is defined in a general manner t= o >>> be >>>>> generally useful in line with the overall capability negotiation >>> framework >>>>> (as opposed to targeted at one specific use case with one specific >>> value) >>>>>>>>> - There are scenarios where ICE cannot be used, even if >implemented >>>>> (e.g. ice-mismatch). >>>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >>> absence >>>>> of ICE support >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- 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 >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= - >-- >>> - >>>>>>>>> This transmission (including any attachments) may contain >>> confidential >>>>> information, privileged material (including material protected by the >>>>> solicitor-client or other applicable privileges), or constitute non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information >from >>>>> your system. Use, dissemination, distribution, or reproduction of thi= s >>>>> transmission by unintended recipients is not authorized and may be >>>>> unlawful. >>>>>>>>> . >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> -- >>>>>>> Jonathan Lennox >>>>>>> jonathan@vidyo.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> --------------------------------------------------------------------= - >>>>>> This transmission (including any attachments) may contain >confidential >>>>> information, privileged material (including material protected by the >>>>> solicitor-client or other applicable privileges), or constitute non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information >from >>>>> your system. Use, dissemination, distribution, or reproduction of thi= s >>>>> transmission by unintended recipients is not authorized and may be >>>>> unlawful. >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> 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 mallinath@google.com Thu Apr 18 07:23: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 A4C0621F8F68 for ; Thu, 18 Apr 2013 07:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.306, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf5wwTihZKfa for ; Thu, 18 Apr 2013 07:23:03 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9733E21F8F63 for ; Thu, 18 Apr 2013 07:23:01 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id q19so1702033qeb.26 for ; Thu, 18 Apr 2013 07:23:01 -0700 (PDT) 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=gg59QtfCOvWErecpIy3T3Q3fVcSQ+M0stCv7sYRr0l0=; b=IbTeVXaqttzZwqTOVExzOGln9NpUpxgm4HU32EF+Npx2NGL42oR9Plp5oXhZGYk1+R H8iI2LTB+1aphzH0GulJke4KdqcyN+Rc1smn6fIRHHmuW3kUkLfBZzdnljB3wxHWbpaq Bh9X5mGaStME1wgZpCc0ErNYOGcaiHmfrdQyx8yAoloqCd0UBTOgjraddvoyw7DXO3g2 +KzNzKG1QaolKe6xvCJmrE7shU+lRdVMQkGxgDDTwqln6T7qj6RdDBW0evQYe2uJySKI gjPq2IK5TUhj0MAcO+ADKp+8FU05iXVD3a+Tg9ZAzqAqdsuSu99CqtZ1NfpzPsN8Tr6m Pb/g== 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=gg59QtfCOvWErecpIy3T3Q3fVcSQ+M0stCv7sYRr0l0=; b=LJ2BtdPwhsdHfPtlmCePjAnQHCqsSf1kt03zBzN07w4bqQMrXKHlrYEEZJ8O54eQDb PjA4Tafs7OFnK1SItGcANtNdkqhKIZ10hO5uZ5SyJke8MZPZSc11x2YZROh3V9btlpWR iD15EAbH98djxvPoSX5nm6ipfDNq9uk44L4laE3zHrtsUauD3XTFEMf9J7fT5c8bE4/i PrUPgBgiKOVLhMBKyWcpzO6zlWThn88+gxecpullIIr2qwewbpK63ItT5wXN6Zvttl4O 0eVkS25Cvwk6LFm74HTjbvcfh8pevFMBpWssP4rMtiiFu3HzhAjT85PeXdJFYnxZxaI7 9j+g== X-Received: by 10.224.192.196 with SMTP id dr4mr10363699qab.80.1366294981021; Thu, 18 Apr 2013 07:23:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.112.75 with HTTP; Thu, 18 Apr 2013 07:22:38 -0700 (PDT) From: Mallinath Bareddy Date: Thu, 18 Apr 2013 07:22:38 -0700 Message-ID: To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=20cf300fb30500a20d04daa3576a X-Gm-Message-State: ALoCoQnMZtTWI+9gfMFuowOeAMyAAvGrSwmux20z49CbTCBLW2Vm+pQiVgs3YyYujM9J5qdeXL+/D3a8UeYZAQyfykD0OiGtDjqBrBcYeMW2C9sD3KmsKe36KYUeU+j0bj7HTNO9ADeSJStK5n1oHozbg4+UDNPxW+dH3yIxvp+dxXen/GUvxGG8+JYsrMOh5/K0METwMs33 Subject: [MMUSIC] TURN candidates priority 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, 18 Apr 2013 14:23:05 -0000 --20cf300fb30500a20d04daa3576a Content-Type: text/plain; charset=ISO-8859-1 What should be the TURN candidate priority when obtained over TCP/TLS vs UDP? If same candidate priority used, this could lead to a undesired candidate paring, even though better option may be available. Regards, Mallinath --20cf300fb30500a20d04daa3576a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What should be the TURN candidate priority when obtained over TCP/TL= S vs UDP?=A0
If same candidate priority used, this could lead to a undesired candidate p= aring, even though better option may be available.

Regards,
Mallinath
--20cf300fb30500a20d04daa3576a-- From xavier.marjou@gmail.com Thu Apr 18 08:06: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 55F7321F8F02 for ; Thu, 18 Apr 2013 08:06:44 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ3Qil00jWGd for ; Thu, 18 Apr 2013 08:06:43 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8921F8EBF for ; Thu, 18 Apr 2013 08:06:42 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w20so2776249lbh.4 for ; Thu, 18 Apr 2013 08:06:41 -0700 (PDT) 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:content-type; bh=H+4VMnnTGxuV+6K1K7StKGLZ/OdmSSi8oF3UV10LAOI=; b=ESy8beR9/iW9xOOlxgsAjNhNd9z0cvcGoLWN2iK4YObUL49Vi38SVDvldTrb8DQG6c WEsGVshyIOjYBfE/w8BSe0U0CCmvQFXuPxAlEXlyJVQxnuNgy96Ce7U8HIzvwxIDY/vl m4805HMUFpAJ86A3b2SOvqGFjjZJ8O3XZ+qmts3ZCOiopooQxR0ZJ/n6zGuqD8u1glNo YR3+Iru0GA0myi6PTFMZqr7HbATOYil6istDsUIdq3rjSVQRewEjfucsdxz1I69ganZV fe/9HpdOWTwtvot5OtbzZIOa0o974WScSgWTtGV8cK6UK7OhQOK2HICkOKOJwwa6Uhpr JcLw== MIME-Version: 1.0 X-Received: by 10.112.146.34 with SMTP id sz2mr6035095lbb.4.1366297601702; Thu, 18 Apr 2013 08:06:41 -0700 (PDT) Received: by 10.114.177.212 with HTTP; Thu, 18 Apr 2013 08:06:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Apr 2013 17:06:41 +0200 Message-ID: From: Xavier Marjou To: IETF MMUSIC WG Content-Type: multipart/alternative; boundary=047d7b3a85c835044504daa3f395 Subject: [MMUSIC] Fwd: TURN candidates priority 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, 18 Apr 2013 15:06:44 -0000 --047d7b3a85c835044504daa3f395 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Xavier Marjou Date: Thu, Apr 18, 2013 at 5:03 PM Subject: Re: [MMUSIC] TURN candidates priority To: Mallinath Bareddy Hi, There are some recommendations in http://tools.ietf.org/html/rfc6544#section-4.2. Cheers, Xavier On Thu, Apr 18, 2013 at 4:22 PM, Mallinath Bareddy wrote: > What should be the TURN candidate priority when obtained over TCP/TLS vs > UDP? > If same candidate priority used, this could lead to a undesired candidate > paring, even though better option may be available. > > Regards, > Mallinath > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --047d7b3a85c835044504daa3f395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: Xavier Marjou <= span dir=3D"ltr"><xavier.mar= jou@orange.com>
Date: Thu, Apr 18, 2013 at 5:03 PM
Subject: Re: [MMUSIC] TURN candidates= priority
To: Mallinath Bareddy <mallinath@google.com>


Hi,=A0

There are some recommendations in=A0http://tools.ietf.org/= html/rfc6544#section-4.2.

Cheers,
Xavier


On Thu, Apr 18, 2013 at 4:22 = PM, Mallinath Bareddy <mallinath@google.com> wrote:
W= hat should be the TURN candidate priority when obtained over TCP/TLS vs UDP= ?=A0
If same candidate priority used, this could lead to a undesired candidate p= aring, even though better option may be available.

Regards,
Mallinath

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



--047d7b3a85c835044504daa3f395-- From andrew.hutton@siemens-enterprise.com Thu Apr 18 09:57: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 9DB5C21F9020 for ; Thu, 18 Apr 2013 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 Lg7qkU1Q+wYv for ; Thu, 18 Apr 2013 09:57:15 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A121F8FF8 for ; Thu, 18 Apr 2013 09:57:14 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9159A1EB844C; Thu, 18 Apr 2013 18:57:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Thu, 18 Apr 2013 18:57:13 +0200 From: "Hutton, Andrew" To: "Dale R. Worley" Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 Thread-Index: AQHOO6+unN/mV6b67keOupOlzSkFyZjcHzTA Date: Thu, 18 Apr 2013 16:57:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> In-Reply-To: <201304172107.r3HL7Fdt2897721@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 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-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: Thu, 18 Apr 2013 16:57:15 -0000 Hi Dale, Thanks for the comments see some responses below. Andy > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Dale R. Worley > Sent: 17 April 2013 22:07 > To: mmusic@ietf.org > Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 >=20 > It seems to me that the essence of > draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE > candidates to effectively specify two address/ports that is available > for the remote UA to contact this UA. One address/port is the > standard ICE address/port and the other is the "bundleport", and > indicates an address/port that the remote UA can contact using > bundled/multiplexed media. [AndyH] - Yes. I am thinking that there are advantages to explicitly state = the bundle address rather than relying on rules to determine which port to = use.=20 >=20 > If the candidates for two different m=3D lines specify the same > bundleport, it would be useful to define the ICE procedures to ensure > that connectivity to that address/port is tested only once for any > remote address/port. If the remote UA is not bundling/multiplexing, > this does not change anything, as connectivity has to be tested > separately for each transport association (5-tuple). But if both ends > are using bundling, we could have 3 m=3D lines for each UA, but only > effectively one set of candidate address/ports at each end. We > wouldn't want to repeat the connectivity checks 3 times over. >=20 [AndyH] This is covered in the existing bundle draft which states that conn= ectivity checks are performed on the bundle group rather than each m=3D lin= e.=20 > Also, what is the order of testing of ICE candidates if bundleport is > present? =20 [AndyH] I don't think there is any change to existing procedures here. > My understanding is that ICE was carefully designed so that > both UAs test each candidate pair simultaneously. What is the > timing/sequencing rules when bundleport is present to ensure that (1) > both UAs test each pair simultaneously, (2) the bundleport > address/ports are tested first if both ends support bundling, and (3) > the timing of "baseline" candidate testing is unchanged if either UA > does not support bundling? It seems like we need a careful > specification of the changes to the candidate testing algorithm. >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Markus.Isomaki@nokia.com Thu Apr 18 10:12: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 010D121F9298 for ; Thu, 18 Apr 2013 10:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 htgeXK6VuBgE for ; Thu, 18 Apr 2013 10:12:21 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2018C21F9057 for ; Thu, 18 Apr 2013 10:12:20 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r3IHC0Zv001111; Thu, 18 Apr 2013 20:12:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Apr 2013 20:12:00 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.144]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0328.011; Thu, 18 Apr 2013 17:11:59 +0000 From: To: , Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 Thread-Index: AQHOO6+vefbP06o5Tkic2DoyUomz45jcKHXA Date: Thu, 18 Apr 2013 17:11:58 +0000 Message-ID: References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> In-Reply-To: <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoYMcJNapax88YqtSTqn3/B378sCyjk6EEB2ropie4xs3n0MGhn2i9mzzX+wfZ1ifI9o9C0Qk0dDdSOYCMAFmfYWYjrF9IAyS/EfZNisUSjUINBq8D/ginjTn5ou8UgS1+6MgcdvNybMxp/BJ4NdY0ID8SfOPf9GjUuIEEsRYYYVKqfRHVonsbbiHiS7n+DiNePEaGCUWx3uUvDeMAm7dBMmAL57OAyJ8ESyXG71+F+mDrLG8TbaMrlhzbySH2pqLw== x-originating-ip: [10.163.165.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Apr 2013 17:12:00.0510 (UTC) FILETIME=[D6DF41E0:01CE3C57] X-Nokia-AV: Clean Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-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: Thu, 18 Apr 2013 17:12:22 -0000 Hi, I also reviewed the draft and was trying to understand what problems it is = trying to solve. It is easier to find a solution if we agree on the require= ments. From the draft I gathered that it tries to address at least these tw= o limitations in [1]: 1.) A problem with the existing bundling proposals is that it does not appear possible to create a single initial offer that will allow bundle to be negotiated but maintain interworking with bundle unaware implementations and therefore it is necessary to perform an initial offer/answer exchange which does not fully describe or at least only implicitly describes what the offerer really wants to offer. The existing bundle proposals also don't take account of the fact that when both parties support ICE [RFC5245] the port in the m-line of the initial offer may not be used at all, for example due to a dual stack offer endpoint offering IPv4 and IPv6 addresses in parallel. Markus: This is a relevant point if indeed call setup time or even the numb= er of messages can somehow be reduced in some of the situations. But is tha= t the case here? I think that if both peers support bundle (as in [1]), the= y can start bundle-related connectivity checks immediately, and do not need= to do any other connectivity checks. Is there a substantial difference in = this regard? 2.) Also the existing bundle proposals have not considered some of the more complex ICE scenarios involving multiple candidates. For example when an SDP m-line contains multiple ICE host candidates during dual stack negotiation, the candidates cannot be considered equivalent with regard to bundling with candidates on in another m-line and therefore some way of indicating which candidates can be bundled seems to be desirable. This could be achieved by including the complete bundle transport address (IP and Port) in the candidate or by providing some kind of bundle linkage within the ICE candidate lines. Markus: This seems to support exotic situations like that the offerer would= be willing to bundle over IPv6, but not over IPv4. Personally I'm not sure= if there are good real use cases for this type of capability. Any concrete= ideas where this would be useful? [1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiatio= n/ Regards, Markus -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Dale R. Worley Sent: 18 April, 2013 00:07 To: mmusic@ietf.org Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 It seems to me that the essence of draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE candidates t= o effectively specify two address/ports that is available for the remote UA= to contact this UA. One address/port is the standard ICE address/port and= the other is the "bundleport", and indicates an address/port that the remo= te UA can contact using bundled/multiplexed media. If the candidates for two different m=3D lines specify the same bundleport,= it would be useful to define the ICE procedures to ensure that connectivit= y to that address/port is tested only once for any remote address/port. If= the remote UA is not bundling/multiplexing, this does not change anything,= as connectivity has to be tested separately for each transport association= (5-tuple). But if both ends are using bundling, we could have 3 m=3D line= s for each UA, but only effectively one set of candidate address/ports at e= ach end. We wouldn't want to repeat the connectivity checks 3 times over. Also, what is the order of testing of ICE candidates if bundleport is prese= nt? My understanding is that ICE was carefully designed so that both UAs t= est each candidate pair simultaneously. What is the timing/sequencing rule= s when bundleport is present to ensure that (1) both UAs test each pair sim= ultaneously, (2) the bundleport address/ports are tested first if both ends= support bundling, and (3) the timing of "baseline" candidate testing is un= changed if either UA does not support bundling? It seems like we need a ca= reful specification of the changes to the candidate testing algorithm. Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mallinath@google.com Thu Apr 18 10:27: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 88C4321F93B3 for ; Thu, 18 Apr 2013 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 JvG-SLQpBTBz for ; Thu, 18 Apr 2013 10:27:41 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B31BA21F93BE for ; Thu, 18 Apr 2013 10:27:40 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id t2so423958qcq.28 for ; Thu, 18 Apr 2013 10:27:32 -0700 (PDT) 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=Nj5VWTWXUd8z0q2/vyQG/lL6qyLxOjrSt4TVPDsM38I=; b=Bco7+7lpeo7unRCxtnJ7NPat8fahgKyVINVpgmBt1B1ProWAIsGFlijdxbck7+QohV H3az3SyH/w7pTX8YzzMTFGuYzzQ257AJ2DOHQgx9kx4oDA4fWsgROChKASY7eOkJZ4hm /9oc0DBiR+JEl0/3Xg0yjwt8M9VTZEXgiGPrteiZVRDU6psUdkXfPqEtkVBUHSaBOfXN E5x8TaiFYTBm/yfCPuNGQ3L0qYpEk3o3B8ulV78IS+Af4bIxl2gnJiOe1PneRXnl0FMD i7ZZrkH5Cl3fyxQ+d+3lP+92fyXZMThIaMgZ8plR0FOFwJ5R++P1ATr6108mJz1RPBUU uFPA== 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=Nj5VWTWXUd8z0q2/vyQG/lL6qyLxOjrSt4TVPDsM38I=; b=WC5VPq4pg/4obO0LgJQnVmfZ3pGS73nknbcRZZGuoPn3Y+i5V8/B1EDHgXYwPvp2df H1sl3QYLgqpuR5PAhbsv0TZMV0BKNk+UXHysiI7dhd7AXSvEJb4V2Ttk+FekBdcNFmwz h4y+zUqY78cZBPTwZ4yFqoh04NbroDyJe2J9QwhQEdx5IBBeBmFfXpfYlRb5x0AS7QSJ i0OQ7zKUcywp6URmddsQwPrTbXp63opB+pl8zyLBWwqVLdGRrURNLT8r7jTlYzBzp2il B9UzMj4+o95y3DHYh8KTyfs7rXREKfThbtAtqumKjqTZg1lKhIlqjDoa54tcj6TOHP++ UwHQ== X-Received: by 10.49.127.8 with SMTP id nc8mr12753983qeb.31.1366306052693; Thu, 18 Apr 2013 10:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.112.75 with HTTP; Thu, 18 Apr 2013 10:27:12 -0700 (PDT) In-Reply-To: References: From: Mallinath Bareddy Date: Thu, 18 Apr 2013 10:27:12 -0700 Message-ID: To: Xavier Marjou Content-Type: multipart/alternative; boundary=047d7b672e26ecf26104daa5ea86 X-Gm-Message-State: ALoCoQlelFPJQmRXeU38pyFzq1DYogaimcFg/y0Wp8+yp3h0+ElBFSppZCcLVvHV7xfPc8kOri3du0IKhwUtPbIpGlFd5ugM/QW41LIA+IaLoqy+eEHR133Ly+hFMJOWOYmzbIKXcIp6/5+gXtkHk8CTcndAHcpJCMQjfAxAU2FLsJUc8WwGQC7nU1HRQmTyFCFxumRYC5Yp Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Fwd: TURN candidates priority 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, 18 Apr 2013 17:27:41 -0000 --047d7b672e26ecf26104daa5ea86 Content-Type: text/plain; charset=ISO-8859-1 I am not sure http://tools.ietf.org/html/rfc6544#section-4.2 addresses the problem, as the candidate is still a relay candidate and allocation is UDP. Only difference here is that transport protocol between client and server is changed from UDP to TCP. On Thu, Apr 18, 2013 at 8:06 AM, Xavier Marjou wrote: > > > ---------- Forwarded message ---------- > From: Xavier Marjou > Date: Thu, Apr 18, 2013 at 5:03 PM > Subject: Re: [MMUSIC] TURN candidates priority > To: Mallinath Bareddy > > > Hi, > > There are some recommendations in > http://tools.ietf.org/html/rfc6544#section-4.2. > > Cheers, > Xavier > > > On Thu, Apr 18, 2013 at 4:22 PM, Mallinath Bareddy wrote: > >> What should be the TURN candidate priority when obtained over TCP/TLS vs >> UDP? >> If same candidate priority used, this could lead to a undesired >> candidate paring, even though better option may be available. >> >> Regards, >> Mallinath >> >> _______________________________________________ >> 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 > > --047d7b672e26ecf26104daa5ea86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not sure=A0=A0http://tools.ietf.org/html/rfc6544#section-4.2=A0addresses the problem, as the candidate is still a rela= y candidate and allocation is UDP. Only difference here is that transport p= rotocol between client and server is changed from UDP to TCP.





On Thu, Apr 18, 2013 at 8:06 AM, Xavier Marjou <xavier.marjou@gma= il.com> wrote:


---------- Forwarded messag= e ----------
From: Xavier Marjou <= ;xavier.marjo= u@orange.com>
Date: Thu, Apr 18, 2013 at 5:03 PM
Subject: Re: [MMUSIC] TURN candidates= priority
To: Mallinath Bareddy <mallinath@google.com>


Hi,=A0

There are some recommendations in=A0http://tools.ietf.org/= html/rfc6544#section-4.2.

Cheers,
Xavier


On Thu, Apr 18, 2013 at 4:22 PM, Mallinath= Bareddy <mallinath@google.com> wrote:
= What should be = the TURN candidate priority when obtained over TCP/TLS vs UDP?=A0
If same candidate priority used, this could lead to a undesired candidate p= aring, even though better option may be available.

Regards,
Mallinath

_______________________________________________
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


--047d7b672e26ecf26104daa5ea86-- From ari.keranen@ericsson.com Thu Apr 18 10:29: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 0AABE21F91B2 for ; Thu, 18 Apr 2013 10:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ZquqkVSfewj6 for ; Thu, 18 Apr 2013 10:29:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0F13A21F91B1 for ; Thu, 18 Apr 2013 10:29:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-b0-51702d67b052 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E3.F8.03253.76D20715; Thu, 18 Apr 2013 19:29:12 +0200 (CEST) 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, 18 Apr 2013 19:29:11 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A6FF324D0; Thu, 18 Apr 2013 20:29:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 445D154A1E; Thu, 18 Apr 2013 20:29:11 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F2D255113A; Thu, 18 Apr 2013 20:29:10 +0300 (EEST) Message-ID: <51702D66.3010200@ericsson.com> Date: Thu, 18 Apr 2013 20:29:10 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <1373AC9C23D80E44856F5CF6F883ACAB11379413@xmb-rcd-x06.cisco.com> In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB11379413@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvrW6GbkGgwd9PXBZTlz9msXh/fSWL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxpnk5U0Erf8XJNxvZGxibeboYOTkkBEwk /n2/wwxhi0lcuLeerYuRi0NI4BSjxJ9pV6GcDYwSM6begXJ2M0rMubcerEVIYB2jRN+8EIjE CkaJ0ytusHQxcnDwCmhLrG0IBTFZBFQlLmwpAylnE7CXuDnhOjtIWFQgWeL/Dm+QMK+AoMTJ mU9YQGwRAWOJ5iNH2UFsZgEZiRlnG5lAbGEBb4n+/zfYIbb6SJw71A9mcwr4Sly7f5IJot5W 4sKc6ywQtrxE89bZUI+pSVw9twnqYlWJq/9eMU5gFJ2FZPUsJO2zkLQvYGRexciem5iZk15u vokRGPIHt/w22MG46b7YIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi5 /L+az9y+SvYvw/qNmh92Lu4WWCT1OWzud/boytZ5SjK7lSJ1/1SWWETGy1jKfgyI8Fp7WGVu b8V/ZSWDqU7XsjyNmf0+ZW46dHhVpNnZr37xyWEbblkcy37ksiieK3lNsfC9LRHFMQ3xa7b/ itrn/Pz/hZlsZ2NTdhRbiHGU6ps3rljjdUuJpTgj0VCLuag4EQBFMiLvRwIAAA== Cc: mmusic Subject: Re: [MMUSIC] ICEbis: INTEGRITY attribute in Binding Responses clarification 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, 18 Apr 2013 17:29:14 -0000 Hi Pål-Erik, I agree that making this more explicit makes sense. The second paragraph of 7.2 starts now with: The agent MUST use the short-term credential mechanism (i.e., the MESSAGE-INTEGRITY attribute) to authenticate the request and perform a message integrity check. Likewise, the short-term credential mechanism MUST be used for the response. Unless someone sees some problem with this (in that case, please comment), I'll make this change for the next revision. Cheers, Ari On 4/2/13 12:59 PM, Pal Martinsen (palmarti) wrote: > Hi, > > I was reading through the ICE RFC and trying to figure out if Binding > Responses needed the INTEGRITY attribute. Usually the ICE RFC is very > descriptive in what to include in the messages, but I could not find > any text clearly stating that the INTEGRITY attribute must be > included in the Binding Responses. > > When reading the STUN RFC it states in section 7.3.1.1: "If the > server authenticated the request using an authentication mechanism, > then the server SHOULD add the appropriate authentication attributes > to the response (see Section 10)." > > Is this SHOULD strong enough for the connectivity checks performed by > ICE? Should it be changed to a MUST? > > To spell it out for readers like me, I propose the following changes > to section 7.2 the second paragraph of the ICE RFC > (http://tools.ietf.org/html/draft-keranen-mmusic-rfc5245bis-01#section-7.2) > > The agent MUST use a short-term credential (i.e., the > MESSAGE-INTEGRITY attribute) to authenticate and perform a message > integrity check on the request and any response to that request. > > Adding the following to section 7.1.3.1 might also help to remind the > implementors: > > The agent MUST use the INTEGRITY-MESSAGE attribute in the Binding > Response to authenticate the message. > > > .-. Pål-Erik Martinsen > From worley@shell01.TheWorld.com Thu Apr 18 11:33: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 EC94C21F9356 for ; Thu, 18 Apr 2013 11:33:54 -0700 (PDT) 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.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SUBJECT_FUZZY_TION=0.156] 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 SZdSMgc-uUyl for ; Thu, 18 Apr 2013 11:33:54 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 910BC21F92E9 for ; Thu, 18 Apr 2013 11:33:53 -0700 (PDT) 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 r3IIXHAg014536 for ; Thu, 18 Apr 2013 14:33:20 -0400 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 r3IIXHhI2952170 for ; Thu, 18 Apr 2013 14:33:17 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IIXHcr2960017; Thu, 18 Apr 2013 14:33:17 -0400 (EDT) Date: Thu, 18 Apr 2013 14:33:17 -0400 (EDT) Message-Id: <201304181833.r3IIXHcr2960017@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com) References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net> Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-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: Thu, 18 Apr 2013 18:33:55 -0000 > From: "Hutton, Andrew" > > [AndyH] This is covered in the existing bundle draft which states > that connectivity checks are performed on the bundle group rather > than each m= line. What I see in draft-ietf-mmusic-sdp-bundle-negotiation-03 is 8.3. Candidates Once it is known that both endpoints support, and accept to use, the "BUNDLE" grouping extension, ICE connectivity checks and keep-alives only needs to be performed for the whole "BUNDLE" group, instead of for each individual "m=" line associated with the group. which is more a sketch than a description of the algorithm. I suppose what is bothering me is that draft-hutton-mmusic-bundled-ice-candidates modifies the procedures of draft-ietf-mmusic-sdp-bundle-negotiation, and draft-ietf-mmusic-sdp-bundle-negotiation modifies the procedures RFC 5245. Neither modification is large, but stacking two weakly-specified modifications together makes me worry that nobody has a clear understanding of what the combined procedure really is, and it is hard to examine the combined procedure for unintended consequences. Dale From worley@shell01.TheWorld.com Thu Apr 18 13:47: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 AF08021F935D for ; Thu, 18 Apr 2013 13:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 15o42vIMCjX8 for ; Thu, 18 Apr 2013 13:47:45 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0268021F9350 for ; Thu, 18 Apr 2013 13:47:44 -0700 (PDT) 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 r3IKlbeV032477 for ; Thu, 18 Apr 2013 16:47:39 -0400 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 r3IKlaVA2963467 for ; Thu, 18 Apr 2013 16:47:37 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKlaCt2959062; Thu, 18 Apr 2013 16:47:36 -0400 (EDT) Date: Thu, 18 Apr 2013 16:47:36 -0400 (EDT) Message-Id: <201304182047.r3IKlaCt2959062@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <516E5575.1050704@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304161549.r3GFnui72796125@shell01.TheWorld.com> <516E5575.1050704@ericsson.com> Subject: Re: [MMUSIC] Feedback requested on requirements 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, 18 Apr 2013 20:47:46 -0000 > From: Magnus Westerlund > > DES F12 Bundling must not interfere with ICE usage, and in > > particular, ICE's ability to negotiate both IPv4 and IPv6 > > addresses simultaneously. > > I believe the intention is right here, but I stumble on the word > "negotiate". To my understanding the usage of two address families are > not really negotiated. It is more, here are my candidates, create > candidate pairs within each family and then follow the check-board > algorithm. The object of the verb "negotiate" is "addresses": "ICE negotiates addresses". There may be a better word than "negotiate" for what ICE does. In any case, Andy Hutton expressed concern that the bundling mechanism should not limit dual-stack implementations in any way, so I included this desideratum. Dale From worley@shell01.TheWorld.com Thu Apr 18 13:48: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 180BE21F9375 for ; Thu, 18 Apr 2013 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 cKvSpLbTUaTU for ; Thu, 18 Apr 2013 13:48:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8136E21F934B for ; Thu, 18 Apr 2013 13:48:02 -0700 (PDT) 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 r3IKkVRD001819 for ; Thu, 18 Apr 2013 16:46:33 -0400 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 r3IKkVPL2948591 for ; Thu, 18 Apr 2013 16:46:31 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKkUNs2939501; Thu, 18 Apr 2013 16:46:30 -0400 (EDT) Date: Thu, 18 Apr 2013 16:46:30 -0400 (EDT) Message-Id: <201304182046.r3IKkUNs2939501@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 18 Apr 2013 20:48:03 -0000 Here is the start of "compatibility" desiderata, that is, aspects of the protocol needed to interwork well with the existing Internet. 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., the codec set and ICE) are generally designed so that an offerer always offers every facility it is willing to support in the current situation, regardless of whether it was agreed to by the answerer in a preceding exchange. Thus, if the current 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., [RFC3725] and [I-D.worley-service-example]). This desideratum was suggested by Richard Ejzak. Dale From worley@shell01.TheWorld.com Thu Apr 18 13:48: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 6B86421F934B for ; Thu, 18 Apr 2013 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 If2WW619Gkpg for ; Thu, 18 Apr 2013 13:48:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC521F9369 for ; Thu, 18 Apr 2013 13:48:02 -0700 (PDT) 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 r3IKl4BN018249 for ; Thu, 18 Apr 2013 16:47:06 -0400 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 r3IKl48g2947630 for ; Thu, 18 Apr 2013 16:47:04 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKl4gX2959218; Thu, 18 Apr 2013 16:47:04 -0400 (EDT) Date: Thu, 18 Apr 2013 16:47:04 -0400 (EDT) Message-Id: <201304182047.r3IKl4gX2959218@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <516E5575.1050704@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304161549.r3GFnui72796125@shell01.TheWorld.com> <516E5575.1050704@ericsson.com> Subject: Re: [MMUSIC] Feedback requested on requirements - DES F13 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, 18 Apr 2013 20:48:03 -0000 Answering messages from Magnus and Christer regarding DES F13: > From: Magnus Westerlund > > DES F13 It is desirable for RTP media to appear on the wire as > > (encrypted) SRTP packets and for RTCP reports to appear on the > > wire as (authenticated but not encrypted) SRTCP packets. Thus, > > encryption of RTP/RTCP via DTLS and encapsulation of multiplexed > > packets is not desirable. > > I am not certain I understand the motivations for this requirement. Is > the need to having unencrypted RTCP for third party monitors? From a > security point of view I see issues with such blanket statements. There > can be information in the RTCP that is sensitive for privacy reasons. I omitted the discussion of this desideratum: This desideratum was suggested by Martin Thompson (http:// www.ietf.org/mail-archive/web/mmusic/current/msg10400.html) and Dan Wing (http://www.ietf.org/mail-archive/web/mmusic/current/ msg10408.html). The two referenced messages are: From: Martin Thomson Date: Wed, 27 Feb 2013 14:11:21 -0800 Cc: "mmusic at ietf.org" 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. From: "Dan Wing" Date: Thu, 28 Feb 2013 14:51:52 -0800 Delivered-to: mmusic at ietfa.amsl.com 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. The reason I document this as a requirement for bundling is that it excludes certain uses of cryptography and more importantly, it excludes encapsulation techniques. > For the last sentence are you really meaning DTLS or DTLS-SRTP. There is > a big difference here. I may be misusing the terminology, but I believe that "DTLS-SRTP" is "providing keying for SRTP using DTLS", whereas the phrase I used is "encryption of RTP/RTCP via DTLS", which is what I intended. > From: Christer Holmberg > I am not sure I understand why this is bundle specific. This requirement excludes techniques that use encapsulation, so it is a significant constraint on acceptable bundling techniques. Dale From worley@shell01.TheWorld.com Thu Apr 18 13:49: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 256F021F9154 for ; Thu, 18 Apr 2013 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 BxoU2fLXYiwf for ; Thu, 18 Apr 2013 13:49:20 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7C21F9130 for ; Thu, 18 Apr 2013 13:49:20 -0700 (PDT) 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 r3IKmL5h021043 for ; Thu, 18 Apr 2013 16:48:23 -0400 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 r3IKmLij2959301 for ; Thu, 18 Apr 2013 16:48:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKmKE12951312; Thu, 18 Apr 2013 16:48:20 -0400 (EDT) Date: Thu, 18 Apr 2013 16:48:20 -0400 (EDT) Message-Id: <201304182048.r3IKmKE12951312@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <516E56BE.2040606@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516E56BE.2040606@ericsson.com> Subject: Re: [MMUSIC] Feedback requested on requirements 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, 18 Apr 2013 20:49:21 -0000 > From: Magnus Westerlund > > On 2013-04-09 17:39, Dale R. Worley wrote: > > 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. > > If you with "constituent RTP session within it" where it is a bundle > means the RTP media streams resulting from that particular SDP media > description (m= block) then I believe I agree with 1). Ah, yes, I meant "media description" instead of "RTP session". I'll fix that in the next version of the draft. > When it comes to 2) what makes this different from rejecting each m= > block within the bundle? If we allow bundles that contain zero media descriptions, then it is conceptually possible that the bundle is accepted but all of the constituent media descriptions are rejected, leaving the bundle empty. I do not see an immediate use for that, but in the long run, it is desirable that the mechanism is able to express that. > 3) is required if legacy fallback at all going to be available. Dale From worley@shell01.TheWorld.com Thu Apr 18 13:49: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 4ED7E21F935D for ; Thu, 18 Apr 2013 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 wtsPp4rs88mw for ; Thu, 18 Apr 2013 13:49:20 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 84ABE21F912C for ; Thu, 18 Apr 2013 13:49:20 -0700 (PDT) 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 r3IKm6Sj016695 for ; Thu, 18 Apr 2013 16:48:08 -0400 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 r3IKm5MI2963925 for ; Thu, 18 Apr 2013 16:48:05 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IKm5iY2937353; Thu, 18 Apr 2013 16:48:05 -0400 (EDT) Date: Thu, 18 Apr 2013 16:48:05 -0400 (EDT) Message-Id: <201304182048.r3IKm5iY2937353@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C325E18@ESESSMB208.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1C325E18@ESESSMB208.ericsson.se> Subject: Re: [MMUSIC] Feedback requested on requirements - DES F5 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, 18 Apr 2013 20:49:21 -0000 > From: Christer Holmberg > > > 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.) > > I am not sure I understand this. Why would a bundle need to contain > other bundle(s)? When I wrote the original version of this, I thought "I don't see any specific need for this, but I expect that uses for it will develop over time." Later, a question arose about a conflict between bundling and QoS marking of transport flows. If QoS is determined by the transport association (5-tuple), then you may not want to bundle audio and video together -- if you have two audio flows and two video flows, you would bundle the audio flows together and the video flows together. OTOH, if QoS is not an issue, you want to bundle audio and video together. The difficulty is that the offerer may not know which situation is present at the answerer and so the offerer has a problem generating an offer that expresses that either of these possibilities is acceptable in the answer. One solution is hierarchical bundling: Put all the audio into one bundle and all the video into another bundle, and then put those two bundles into one super-bundle. The answerer decides whether to accept the super-bundle (and send everything on one transport 5-tuple) or to reject the super-bundle but accept each component bundle (and thus send audio on one 5-tuple and video on another 5-tuple). (The signaling gets a bit more complicated but the multiplexing and demultiplexing processes remain the same as with one-level bundling.) The original of this discussion is: http://www.ietf.org/mail-archive/web/mmusic/current/msg10516.html > From: "Charles Eckel (eckelcu)" > > > From: Markus.Isomaki at nokia.com > > > > I've seen some drafts claiming that Bundle would be harmful in for instance > > cellular networks for QoS differentiation. Is that the motivation where the > > non-Bundled RTCWeb use comes from, or are there some other good > > reasons? > > Not just for cellular but for any scenario in which QoS is based on > using different 5-tuples for media flows for which different > treatment is desired. The question of QoS differentiation is interesting and probably one we have to address, as mobile devices have bandwidth limitations. If it's possible to mark individual packets within a transport flow for different QoS treatments, then we need to define QoS markings as an "application level" attribute rather than a "transport level" attirbute. If QoS differentiation is done entirely based on transport associations (5-tuples), then the strategy would be to have several bundles of m= lines, one for each QoS type. The naive way to do this, that is, just offering two different bundles, is suboptimal if the offerer doesn't know whether different media types need to be in different transport flows or not, because it prevents the answerer from arranging for all the media to be in one bundle (using one transport association, i.e., port) if the answerer knows that there is no QoS problem. This is a situation where using hierarchical bundling would provide a solution: If the offerer does not have a need for different transport flows for audio and video, but is concerned that the answerer might have such a need, it builds an offer containing a master bundle that contains two subordinate bundles, one containing (e.g.) the audio streams and one containing the video streams. If the answerer does not want to separate audio and video, it accepts all the bundling, and then all media are in one transport flow. If the answerer wants to separate audio and video, it rejects the top-level bundle, but accepts each subordinate bundle individually, thus arranging for two transport flows, one containing audio and one containing video. Dale From christer.holmberg@ericsson.com Fri Apr 19 02:13: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 3365921F9457 for ; Fri, 19 Apr 2013 02:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 bodWjN4JG2Tm for ; Fri, 19 Apr 2013 02:13:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3E21F8746 for ; Fri, 19 Apr 2013 02:13:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-de-51710aa7d525 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 31.01.19728.7AA01715; Fri, 19 Apr 2013 11:13:11 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.70]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 11:13:10 +0200 From: Christer Holmberg To: "Markus.Isomaki@nokia.com" , "worley@ariadne.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 Thread-Index: AQHOO6+0f07p9UcwxEeKXZ4+ipCSTJjcFsQAgAEV1pA= Date: Fri, 19 Apr 2013 09:13:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C327739@ESESSMB208.ericsson.se> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> 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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre5yrsJAg5ePZCzO/13EZjF1+WMW i5cnyhyYPSbv/8rssWTJTyaPu7cuMQUwR3HZpKTmZJalFunbJXBlrD/SylzQq17xc+t91gbG 0/JdjBwcEgImEqdfpnYxcgKZYhIX7q1n62Lk4hASOMwo8f3kSRYIZzGjRMOkY4wgDWwCFhLd /7RB4iICvYwS61smMoF0Cws4S5zb8JcFxBYRcJHYubmPCcK2klh0oocRxGYRUJU4NnsNG4jN K+ArsefMdVYQW0jgC6PE20UpIDanQITEmlWLwOYwAl30/dQasDnMAuISt57MZ4K4VEBiyZ7z zBC2qMTLx/9YIWxFiavTl0PV60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0 zELSsoCRZRUje25iZk56udEmRmB0HNzyW3UH451zIocYpTlYlMR5w10vBAgJpCeWpGanphak FsUXleakFh9iZOLglGpglH19oNKD22j9HGcB/+mnWXR2HYrkX7kxulbi7dH4GgPN3a0bqmf8 XaoV9fhv2+dV4synsxQUjy6RP2bLM0HpepyOspDQir1hk3a89b/polsjceHzNL7FSk+UI38L cAQVN+SX5Hd/jJS+9nDyk4MhtxQiYhkDHy/Xn6XR//pVeDuPR16LY+R3JZbijERDLeai4kQA KFHvjlwCAAA= Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-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, 19 Apr 2013 09:13:15 -0000 Hi, > I also reviewed the draft and was trying to understand what problems it i= s trying to solve. It is easier to find a solution if we=20 > agree on the requirements. From the draft I gathered that it tries to add= ress at least these two limitations in [1]: > >1.) > > A problem with the existing bundling proposals is that it does not > appear possible to create a single initial offer that will allow > bundle to be negotiated but maintain interworking with bundle unaware > implementations and therefore it is necessary to perform an initial > offer/answer exchange which does not fully describe or at least only > implicitly describes what the offerer really wants to offer. The > existing bundle proposals also don't take account of the fact that > when both parties support ICE [RFC5245] the port in the m-line of the > initial offer may not be used at all, for example due to a dual stack > offer endpoint offering IPv4 and IPv6 addresses in parallel. The fact that you may end up not using the port in the m- line is normal IC= E procedures. But, I do agree that we should add some text about that. > Markus: This is a relevant point if indeed call setup time or even the nu= mber of messages can somehow be reduced in some of the=20 > situations. But is that the case here? I think that if both peers support= bundle (as in [1]), they can start bundle-related connectivity checks=20 > immediately, and do not need to do any other connectivity checks. Is ther= e a substantial difference in this regard? > > 2.) > > Also the existing bundle proposals have not considered some of the > more complex ICE scenarios involving multiple candidates. For > example when an SDP m-line contains multiple ICE host candidates > during dual stack negotiation, the candidates cannot be considered > equivalent with regard to bundling with candidates on in another > m-line and therefore some way of indicating which candidates can be > bundled seems to be desirable. This could be achieved by including > the complete bundle transport address (IP and Port) in the candidate > or by providing some kind of bundle linkage within the ICE candidate > lines. > > Markus: This seems to support exotic situations like that the offerer wou= ld be willing to bundle over=20 > IPv6, but not over IPv4. Personally I'm not sure if there are good real u= se cases for this type of capability.=20 > Any concrete ideas where this would be useful? I don't really think we need to consider this. If an endpoint wants to chan= ge its candidates, e.g. based on whether bundle will be used or not, it can= send a new offer, with new candidates. Regards, Christer [1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiatio= n/ -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Dale R. Worley Sent: 18 April, 2013 00:07 To: mmusic@ietf.org Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 It seems to me that the essence of draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE candidates t= o effectively specify two address/ports that is available for the remote UA= to contact this UA. One address/port is the standard ICE address/port and= the other is the "bundleport", and indicates an address/port that the remo= te UA can contact using bundled/multiplexed media. If the candidates for two different m=3D lines specify the same bundleport,= it would be useful to define the ICE procedures to ensure that connectivit= y to that address/port is tested only once for any remote address/port. If= the remote UA is not bundling/multiplexing, this does not change anything,= as connectivity has to be tested separately for each transport association= (5-tuple). But if both ends are using bundling, we could have 3 m=3D line= s for each UA, but only effectively one set of candidate address/ports at e= ach end. We wouldn't want to repeat the connectivity checks 3 times over. Also, what is the order of testing of ICE candidates if bundleport is prese= nt? My understanding is that ICE was carefully designed so that both UAs t= est each candidate pair simultaneously. What is the timing/sequencing rule= s when bundleport is present to ensure that (1) both UAs test each pair sim= ultaneously, (2) the bundleport address/ports are tested first if both ends= support bundling, and (3) the timing of "baseline" candidate testing is un= changed if either UA does not support bundling? It seems like we need a ca= reful specification of the changes to the candidate testing algorithm. 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 fluffy@cisco.com Fri Apr 19 09:19: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 E4AB721F88FB for ; Fri, 19 Apr 2013 09:19:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1D0Qv1BAnBg for ; Fri, 19 Apr 2013 09:19:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9B44F21F88D8 for ; Fri, 19 Apr 2013 09:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3749; q=dns/txt; s=iport; t=1366388354; x=1367597954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lz/kYTm4qaUY4U7t2xUlVVrBPdFxvWLUFYOkpseM+DA=; b=DVL1d7FZHxSJAqvyDIn/v7dKGyRClTTb2tDj5+CeFlHCLBl8/bV1862U arcw3UNdKNzlCWoaxuRdsukCGjOESc+2Fo3wtC5j1737FvXYp98i0F8Aw j5degCPZYY47SGRqc26+MBU+L6NFWNHfr11l9W8/q8YyG/1LyjhJi5ICK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOBtcVGtJV2a/2dsb2JhbABQgwbBHIEGFnSCHwEBAQMBaw4FCwIBCA4UJDIlAgQOBQiIBga9UI5yAjEHgmZhA6glgwyCKA X-IronPort-AV: E=Sophos;i="4.87,510,1363132800"; d="scan'208";a="200856831" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 19 Apr 2013 16:19:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3JGJEfD021527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 16:19:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 11:19:13 -0500 From: "Cullen Jennings (fluffy)" To: Justin Uberti Thread-Topic: [MMUSIC] 10 BUNDLE questions Thread-Index: AQHOPRmhAn/HVdjyoE6L992RtT7hTQ== Date: Fri, 19 Apr 2013 16:19:13 +0000 Message-ID: References: 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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 19 Apr 2013 16:19:16 -0000 On Mar 15, 2013, at 2:51 PM, Justin Uberti wrote: > The list below is a set of questions (some marked as OPEN ISSUE already) = regarding the new BUNDLE proposal. If you agree with my suggested answers, = I'm willing to contribute text accordingly. > =95 Can you create a BUNDLE with a single m=3D line? (assuming yes) yes, have to to add more later=20 > =95 Can you create multiple BUNDLEs? (assuming yes) yes but a given m line can only be in one=20 > =95 When creating an initial offer, how should we deal with the case whe= re a "null" port is to be used with trickle ICE (since 6.1:1 indicates the = ports MUST be different)=20 I think we should change bundle to allow the null port=20 - it really needs to be all the parameters related to transport / crypto ne= ed to be different, or at least as different as they would be required to b= e if you were not doing bundle. Key thing is if other side does not underst= and bundle, this looks like an "normal" offer with no bundle.=20 > =95 From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST us= e same c=3D, add rtcp-mux, same a=3Dfingerprint) on rtcp-mux, I think it simplifies thing to mandate rtcp-mux. So if far sid= e accepts bundle but rejects rtcp-mux, this is a fail.=20 on c=3D, I can't think of any good reason to require this. Need more though= t on this.=20 on fingerprint, I don't think this impacts the bundle but it seems like it = make simplify the code that matches the fingerprint to the DTLS connection.= Be interested in hearing EKR's thoughts.=20 > =95 From 6.1, list 2 - is condition 6 right? Why would we use different = SDES keys for a single RTP session? This is confusing in what you do in first is this, but once you know what y= ou are doing, you put what you are using which will result in same not diff= erent keys. This needs series review from crypto experts.=20 > =95 If you start with a m=3D line with one SDES config (e.g. 32-bit MAC)= , and then BUNDLE with another SDES line with a different (non overlapping)= SDES config (e.g. 80-bit MAC), what happens? (assume fail) Lets say can not do that and if you do it, it is a fail.=20 > =95 If the BUNDLE mids in the answer doesn't match the BUNDLE mids in th= e offer, what happens? (assume fail) fail > =95 If you add a m=3D line to an existing BUNDLE, can the recipient reje= ct that BUNDLEing (assume no) agree it should be no > =95 If m=3D lines are rejected, should their mids show up in the BUNDLE = answer? (assume yes?) don't care but we need to be clear should happen.=20 > =95 If not, how does remote side indicate BUNDLE support if it rejects = the m=3D lines that are BUNDLEd? > =95 Is there any way, in a single PeerConnection, to unBUNDLE m=3D lines= that were previously BUNDLEd (assume no) In SIP terminology, I think we would do this with an "INVITE with replaces"= . If you want to do this, you just start a whole new offer that is not an e= volution of the previous set of offer/answers. So basically I am saying not= to do this at the bundle level but instead support it at the signaling lev= el.=20 > _______________________________________________ Also imagine case where=20 Alice offers A, B, and C and offers to bundle them all=20 Bob wants to accept A and B in a bundle and C separate When I talked to Justin this, I was convinced we don't want to bother to su= pport this as it complicated gathering ports for future offers. So what it = comes down to the device receive the offer can either accept the bundle or = not. (and separate accept or reject each m line in the bundle but can't ref= actor the bundling). From juberti@google.com Fri Apr 19 11:37: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 2131221F92E8 for ; Fri, 19 Apr 2013 11:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuv7qynn5dsU for ; Fri, 19 Apr 2013 11:37:23 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5177821F9298 for ; Fri, 19 Apr 2013 11:37:23 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so734410qea.35 for ; Fri, 19 Apr 2013 11:37:22 -0700 (PDT) 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=VOVSWuZRJogxMf0yGjnnrFsicuUqu0dxM+VqAD2TGFY=; b=keK2DBQitcgixrxFBrTWdZOo7krpLmJ7/xnRDI9FiW0f0cOGraxpeyfwGbNz/+dpsX CwO1CCXAetwnG4gCt50i8UvCh82MTY8UIpmymk2R9Pa3nJo4ztXrfitULL0SembKyxUh c7QpMKDnDsvdrl6ZzrxEHeyJxwTf2e5X/t5DvkDfDg7khvfP86Ip7I5gMSMwugvfEyz2 x9ufpYD8ooxtU0Z6OWIV3jpXh+1jGCEibO61IpNYt0002tBZz1pBag7ZUj4Ghxn84uRO r1bRirX/fl/wcokxjUqstmY0Xsx9gSVfrmWIN9DkOBdNjPmO+IQ3LBiDvLJ7oLzPTGUG cfKA== 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=VOVSWuZRJogxMf0yGjnnrFsicuUqu0dxM+VqAD2TGFY=; b=jk9mEereGGe80WpGOsyUkx4TGDtSFt2aP9AhCuN/aHPQS8VAwb1tIhyrjrawaAsPjL Io1IlPACHI/Dw7xx1psSBG6sKe/2VzNtxfoHWohE3lLGShW8q2MaCxcts6EtDoZjyrQO uppscwuI1/Xvi+izWK6v8dHamYZla0Pth6254W/BN6lqkBcvH0mKc/SEadlOdfAluG5U ckWYmzHt2YdFzoYCvpzJMDeEYdCXvQxvTZJYkaeD1lwbCMYFNg8BHPbustqDx17C4/Ta +t+/rQHIbV7rk4qxh+Ukdp+9G1UwG7ZosQkAnduNKpRavqHTAsnvEnB8dPL2XS6IqVWt OsCw== X-Received: by 10.49.104.6 with SMTP id ga6mr17024321qeb.51.1366396642818; Fri, 19 Apr 2013 11:37:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Fri, 19 Apr 2013 11:37:02 -0700 (PDT) In-Reply-To: <201304182048.r3IKmKE12951312@shell01.TheWorld.com> References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516E56BE.2040606@ericsson.com> <201304182048.r3IKmKE12951312@shell01.TheWorld.com> From: Justin Uberti Date: Fri, 19 Apr 2013 11:37:02 -0700 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b5d617c848f8c04dabb02eb X-Gm-Message-State: ALoCoQnvVFRxS1aFZBjOyLzMntwF70UJ3UoCNYCEuW9OKfkUDkTX44kGav6L+uFCvbg6nPS9B8XymxuAB5zwow66tIrIPAZf4tB5MOjhQezU4DxbwJrvClJjY5q/deOP0szcD4Mk9CbQIIOcuKw/h2eI5sxxiXBtC2dImyGR8RFqpRTRUfecRqNVzQ8PqVRWa/K968IBieLg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 19 Apr 2013 18:37:24 -0000 --047d7b5d617c848f8c04dabb02eb Content-Type: text/plain; charset=UTF-8 On Thu, Apr 18, 2013 at 1:48 PM, Dale R. Worley wrote: > > From: Magnus Westerlund > > > > On 2013-04-09 17:39, Dale R. Worley wrote: > > > 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. > > > > If you with "constituent RTP session within it" where it is a bundle > > means the RTP media streams resulting from that particular SDP media > > description (m= block) then I believe I agree with 1). > > Ah, yes, I meant "media description" instead of "RTP session". I'll > fix that in the next version of the draft. > > > When it comes to 2) what makes this different from rejecting each m= > > block within the bundle? > > If we allow bundles that contain zero media descriptions, then it is > conceptually possible that the bundle is accepted but all of the > constituent media descriptions are rejected, leaving the bundle > empty. I do not see an immediate use for that, but in the long run, > it is desirable that the mechanism is able to express that. > The immediate use is to indicate that BUNDLE is supported by the endpoint, even if the proposed BUNDLEd descriptions are rejected. > > > 3) is required if legacy fallback at all going to be available. > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7b5d617c848f8c04dabb02eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 18, 2013 at 1:48 PM, Dale R. Worley &= lt;worley@ariadne.c= om> wrote:
> From: Magnus Westerlund <magnus.westerlund@= ericsson.com>
>
> On 2013-04-09 17:39, Dale R. Worley wrote:
> > =C2=A0 =C2=A0DES F7 =C2=A0If an answerer that does understand the= bundle mechanism
> > =C2=A0 =C2=A0 =C2=A0 processes an offer that contains a bundle, i= t must be able to (1)
> > =C2=A0 =C2=A0 =C2=A0 accept the bundle and selectively accept or = reject each
> > =C2=A0 =C2=A0 =C2=A0 constituent RTP session within it, (2) rejec= t the bundle as a
> > =C2=A0 =C2=A0 =C2=A0 whole, or (3) reject the bundling and select= ively accept or reject
> > =C2=A0 =C2=A0 =C2=A0 each constituent RTP session as separate RTP= sessions.
>
> If you with "constituent RTP session within it" where it is = a bundle
> means the RTP media streams resulting from that particular SDP media > description (m=3D block) then I believe I agree with 1).

Ah, yes, I meant "media description" instead of "RTP s= ession". =C2=A0I'll
fix that in the next version of the draft.

> When it comes to 2) what makes this different from rejecting each m=3D=
> block within the bundle?

If we allow bundles that contain zero media descriptions, then it is<= br> conceptually possible that the bundle is accepted but all of the
constituent media descriptions are rejected, leaving the bundle
empty. =C2=A0I do not see an immediate use for that, but in the long run, it is desirable that the mechanism is able to express that.

The immediate use is to indicate that BUNDLE is suppor= ted by the endpoint, even if the proposed BUNDLEd descriptions are rejected= .=C2=A0

> 3) is required if legacy fallback at all going to be available.

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

--047d7b5d617c848f8c04dabb02eb-- From aavella77@yahoo.com Fri Apr 19 13: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 A846C21F8FE3 for ; Fri, 19 Apr 2013 13:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.41 X-Spam-Level: ** X-Spam-Status: No, score=2.41 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] 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 SfbujiqNXQsH for ; Fri, 19 Apr 2013 13:11:11 -0700 (PDT) Received: from nm18-vm0.bullet.mail.ne1.yahoo.com (nm18-vm0.bullet.mail.ne1.yahoo.com [98.138.91.37]) by ietfa.amsl.com (Postfix) with ESMTP id A503821F8617 for ; Fri, 19 Apr 2013 13:11:11 -0700 (PDT) Received: from [98.138.90.49] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2013 20:11:10 -0000 Received: from [98.138.86.156] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2013 20:11:10 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 19 Apr 2013 20:11:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 954651.94317.bm@omp1014.mail.ne1.yahoo.com Received: (qmail 39119 invoked by uid 60001); 19 Apr 2013 20:11:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366402270; bh=0uSSY54ggJMmmSClojS6RJg95sNsgYdzko4wM8Sg4S8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=OoANzDRDLOv2p9tiJQNeDCdRP2kvYgDnRIU0dDxIBGSDC0Em+FEDdI1ccmNHQChycBFhW0lK0Y7q9rB7o7OetnQs6BwF2RMFakl8wm8crcnnYLlDfMtJD2b0fMkkojnigTPDNnrPVMq2XVoAAs0oIOWj9kpH/h4gh4uPNLid35o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=kk3W+ftXwqJcfQKgXQzTGPqJVs64xCwEY/RIQ40PNJWb+fDWHYhUr5P0+Ogb+L3nxrcSNjt8te3Q7ASaYvsz4kkyb3JHo/sdI2vAp2hndwF8lTAiw/g2bArj8SbdgdFdI0rWGGddQLJCPG/6GiNe3TUacTXP1d3bLoVn7axrDkE=; X-YMail-OSG: MmmQD3QVM1mnSUdFgNwxUSvQvnzzd7k0Rbi6Ye9Pctsj3.U 6SUXJLRUbb_MwSkSLZPgSDhGGY4CBmEAjeM112d5EuPJd6f0T3LeDYSiRVAt 6R0SERWw_KnPGIVaVFnbGygwg8Q8weiiUXVf6EC6nUoluo3Am_srrFtxU4DG TAraxx3qDpQ.S1dakychwAPpKRd.2xJ1Ms3h_c5ReCeHE5sZphAhLbVQ0Hlv T2WakhVxDU1CTZOvx7iOfElxwhZG0HLd8piK16nBIPV4hZCsiJnmpXYCkWLF TUWUBkOqk3YRWdKbwYzSTGohBaF7FCXrwWyBOllq6uWs_6YbfK.Nuj1oUm8y Apgpme5zwCkXwuVP55zj27KZdOOAoZUgmU2NX7oxUwWRnoTSGl1a6bEt__bU HE8xM6R2OZXCyHia5etTNO9bRnCX62km9P4JahUtR7eDjSguXYwVmGp4BEwR i9s.S2elDoC.iRJ90WcskZo0XZAAGR.9DCTakwxdgSAU2EqYiHWDrSGEj4lO 4uzuydUElKMn4D0QGis8ZDJCUFzWbG.RMEiEaSsvajWxQa9VMFv6CN4gUMHg F6zw7mdCDi6T3baNYqYnqtYL2Hd_AyN9.AA8Y4JLlUb0A0A6IUQ-- Received: from [5.185.252.203] by web122006.mail.ne1.yahoo.com via HTTP; Fri, 19 Apr 2013 13:11:10 PDT X-Rocket-MIMEInfo: 002.001, aHR0cDovL3d3dy5iZWZhcmUuc2svY29tcG9uZW50cy9jb21fY29udGVudC93YXNoaW5ndG9uLnBocD9iaW9mZW03MTVteWRxYgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKPT09PT09PT09PT09PT09PT09PT09PQpXaW5kb3cuIFB1c2guIFBhdmVtZW50LiBTcGxhdC4gUmVsaWVmLiAtLSBTZWluZmVsZAEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.141.536 Message-ID: <1366402270.35512.YahooMailNeo@web122006.mail.ne1.yahoo.com> Date: Fri, 19 Apr 2013 13:11:10 -0700 (PDT) From: aea To: cwarren , floyd , jottlinks , bondest , mmusic , Daniel Simancas , zaroking MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1192396609-1489262013-1366402270=:35512" Subject: [MMUSIC] hello! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aea List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:11:12 -0000 ---1192396609-1489262013-1366402270=:35512 Content-Type: text/plain; charset=us-ascii http://www.befare.sk/components/com_content/washington.php?biofem715mydqb ====================== Window. Push. Pavement. Splat. Relief. -- Seinfeld ---1192396609-1489262013-1366402270=:35512 Content-Type: text/html; charset=us-ascii
http://www.befare.sk/components/com_content/washington.php?biofem715mydqb





































































































































======================
Window. Push. Pavement. Splat. Relief. -- Seinfeld
---1192396609-1489262013-1366402270=:35512-- From martin.thomson@gmail.com Fri Apr 19 14:05: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 2CCD221F8E8E for ; Fri, 19 Apr 2013 14:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] 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 nZXJ-p7LBM+3 for ; Fri, 19 Apr 2013 14:05:55 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 255A121F8E84 for ; Fri, 19 Apr 2013 14:05:54 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id p43so840855wea.14 for ; Fri, 19 Apr 2013 14:05:54 -0700 (PDT) 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=UmFP1EaQP285l4tkMbS0eUHffTNyXs9cR3rzNVNKgqo=; b=Axs1ovcdHqP8jdIVSRvHcTK0wSWdyvFYIw9p6zVDrHU6mUzcBbLnGuzln9dnzKmoOu JNbsfPtLIE2DW4QE6sP/KfYTKXEpSkvZ6kz0Xc95erkBbIRG+hf+PbuzmxbBGXT9tB4m dz3Ns51k6w1cyzXJGqxHbaXiieuyZ/LqIMBdz767o7LDAD1zO0aLNbkCC90hCndGo4pK V/TpjLNmtMiO/P/+75G+CjmQcX4XcWuiYvmDTMAXzuXNvqathkmqpDb9WKuaGdqfSuJQ X9opr4PJeZ4A2rpwGeNui19Dxw+yOzK7O/h4PwAEvNLBb43RCmljL8zS0DRSssVqhKAz lwGQ== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr4835058wiy.19.1366405554285; Fri, 19 Apr 2013 14:05:54 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 19 Apr 2013 14:05:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 14:05:54 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 19 Apr 2013 21:05:56 -0000 This clarifies things for me. I hope that these are captured effectively. On 19 April 2013 09:19, Cullen Jennings (fluffy) wrote: > On Mar 15, 2013, at 2:51 PM, Justin Uberti wrote: >> =E2=80=A2 From 6.1, list 1 - are conditions 2, 5, 7 really necessa= ry? (MUST use same c=3D, add rtcp-mux, same a=3Dfingerprint) > > on fingerprint, I don't think this impacts the bundle but it seems like i= t make simplify the code that matches the fingerprint to the DTLS connectio= n. Be interested in hearing EKR's thoughts. I'm not EKR, but I don't see any way that having multiple sets of credentials would be useful. That implies multiple handshakes. a=3Dfingerprint pertains to the transport and as such needs to be the same. You *could* add fingerprints from different lines as alternative valid (in the same way that two a=3Dfingerprint can be added to a single line). Since this is more likely to be mistake than something intentional, better to require that every block in a bundle have the same a=3Dfingerprint. >> =E2=80=A2 From 6.1, list 2 - is condition 6 right? Why would we us= e different SDES keys for a single RTP session? > > This is confusing in what you do in first is this, but once you know what= you are doing, you put what you are using which will result in same not di= fferent keys. This needs series review from crypto experts. In theory you can use multiple keys. And it doesn't have any real consequences. That's not necessarily a useful property though. >> =E2=80=A2 If you start with a m=3D line with one SDES config (e.g.= 32-bit MAC), and then BUNDLE with another SDES line with a different (non = overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume fail) > > Lets say can not do that and if you do it, it is a fail. See above - it's *possible* to have this particular example work. But not useful and therefore inadvisable. I think that a good requirement is that new m=3D lines are entered into a bundle when they are added to the session and that bundle can't change. That means you can't move m=3D lines in and out of bundles. That also keeps the rules with respect to properties constant for any given m=3D line. Sure, you could make a complicated system where this was possible, but it probably wouldn't interoperate. >> =E2=80=A2 If you add a m=3D line to an existing BUNDLE, can the re= cipient reject that BUNDLEing (assume no) > > agree it should be no On first impressions, I was inclined to agree that it makes no sense to allow for unbundling on new m=3D lines, but this is exactly the same sort of scenario that an initial offer has to deal with. Offer the addition of a stream in a bundle, but allow for the fact that peer might not support bundling. So, I'm actually inclined to disagree here. That said, without a use case, such a capability complicates things. I'll get to the use case below. > Also imagine case where > > Alice offers A, B, and C and offers to bundle them all > > Bob wants to accept A and B in a bundle and C separate > > When I talked to Justin this, I was convinced we don't want to bother to = support this as it complicated gathering ports for future offers. So what i= t comes down to the device receive the offer can either accept the bundle o= r not. (and separate accept or reject each m line in the bundle but can't r= efactor the bundling). This is actually the same sort of problem as the above. The question is whether the bundle is negotiated as a whole, or whether answers can differentiate on per-line basis. I can appreciate the desire to simplify, but you have to examine use cases. Example: Alice offers A and B bundled, Bob accepts the bundling. Later, Alice adds C to the bundle. How can Bob get that m=3D line routed over a different path? Do we require that Bob reject the line and offer the same line, potentially inverted, without bundling in a subsequent offer? I'm thinking here about a case where a session escalates from audio to audio+video and there might be a middlebox involved. I guess in that case the middlebox needs to drive the addition. I can probably live with the simplification, but this needs to be crystal clear. A more complete discussion of the implications of this particular choice would be really helpful. From ekr@rtfm.com Sat Apr 20 09:14: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 81B0E21F8765 for ; Sat, 20 Apr 2013 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzSAPPBZpBQE for ; Sat, 20 Apr 2013 09:14:50 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF5B21F86E4 for ; Sat, 20 Apr 2013 09:14:49 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id s14so3349567qeb.13 for ; Sat, 20 Apr 2013 09:14:49 -0700 (PDT) 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=aE2ZrvNKQrg+WnsurwCY16nV/qfyhjY5encPNLuKPZI=; b=GcndN9YN9ZAUfQFTDaoMplFX3nhI0Mm1lG+Ho0HGYt/RveBPoukYeaNP3/aswoHIGB x8JwbfWwoos/39i9dQ4JuaK65SJiQoYaXK/Bp0JRByMeX4n73Owz9whQAAQAtxgUKFZv iMAhDOJ43M2rfJv+gZ22ODxE3aUKU6a3D+bbP67p1QcTlmwUvWjeCQaJTo1TC3/jLe5N wF9tzH7JRcBVgfE3Zb0AJniw438iMsBjN5dNfzTuWG0EUaCszgerDnElecmMSIdbdCU7 0a5e7YvvmTJJyoDaxFIuxvgyCfTCnbUKNn2vlFApEHDUMpl4JP3AO+p2CyWqQ8R597sr 3lPQ== X-Received: by 10.49.76.101 with SMTP id j5mr19558130qew.34.1366474489519; Sat, 20 Apr 2013 09:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.47.13 with HTTP; Sat, 20 Apr 2013 09:14:08 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> From: Eric Rescorla Date: Sat, 20 Apr 2013 09:14:08 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bea2e348af55904dacd22bc X-Gm-Message-State: ALoCoQnmscgHuMMGIiACb64LNNBgO/NtXngHS2EBArkM7NxZfH2vuaGhGKueGDffBsquxBDuFFoa Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] Confirming consensus on way forward with 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: Sat, 20 Apr 2013 16:14:51 -0000 --047d7bea2e348af55904dacd22bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed. On Tue, Apr 16, 2013 at 11:12 PM, Justin Uberti wrote: > I support using the current BUNDLE document as the basis of future > multiplexing work. > > However, I agree there are a number of outstanding details that need to b= e > resolved before this specification is implementable. > > > On Tue, Apr 16, 2013 at 6:28 AM, Hutton, Andrew < > andrew.hutton@siemens-enterprise.com> wrote: > >> Hi, >> >> I stated during the discussion in Orlando that I believe the WG needs to >> do a deeper dive in to some of the more complex scenarios involving >> multiple ICE candidates (E.g. Dual Stack, relay candidates etc.). >> >> After the meeting I thought about this some more and submitted >> http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00= which makes a small start on this. I will spend some time over the next >> couple of weeks thinking this out a bit more and will probably update th= e >> draft but any comments from the working group as to whether this is >> valuable or not would be appreciated. >> >> My thinking is that this might be an extension to the current approach >> rather than an alternative. >> >> Regards >> Andy >> >> >> >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> > Behalf Of Ari Ker=E4nen >> > Sent: 15 April 2013 14:57 >> > To: mmusic >> > Subject: [MMUSIC] Confirming consensus on way forward with Bundle >> > >> > At the Orlando meeting we had a call for consensus (see the minutes of >> > the meeting at [1]) on using the current SDP bundle WG document [2] as >> > the baseline of the bundle work. That is, using the offer/answer >> > exchange as outlined in the draft (subject to clarifying comments made >> > during the meeting) and using the port numbers as described in the >> > draft. >> > >> > The other option would be to not use this as the baseline but to >> > continue discussing the alternative methods. >> > >> > The show-of-hands at the meeting was around 30 for (going forward with >> > the method described in the WG bundle doc) and 4 against. The MMUSIC >> > chairs would like to confirm the consensus on this. >> > >> > Those who were not present at the meeting to comment on this, please d= o >> > so now. >> > >> > >> > Cheers, >> > Ari >> > >> > [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic >> > [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle- >> > negotiation-03 >> > _______________________________________________ >> > 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 > > --047d7bea2e348af55904dacd22bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed.

On Tue, Apr 16, 2013 at 11:12 PM= , Justin Uberti <juberti@google.com> wrote:
I support using the current BUNDLE document as the basis o= f future multiplexing work.

However, I agree there are a= number of outstanding details that need to be resolved before this specifi= cation is implementable.

On Tue, Apr 16, 2013 at 6:28 AM, Hutton, A= ndrew <andrew.hutton@siemens-enterprise.com> wrote:
Hi,

I stated during the discussion in Orlando that I believe the WG needs to do= a deeper dive in to some of the more complex scenarios involving multiple = ICE candidates (E.g. Dual Stack, relay candidates etc.).

After the meeting I thought about this some more and submitted http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-= candidates-00 which makes a small start on this. I will spend some time= over the next couple of weeks thinking this out a bit more and will probab= ly update the draft but any comments from the working group as to whether t= his is valuable or not would be appreciated.

My thinking is that this might be an extension to the current approach rath= er than an alternative.

Regards
Andy



> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Ari Ker=E4nen
> Sent: 15 April 2013 14:57
> To: mmusic
> Subject: [MMUSIC] Confirming consensus on way forward with Bundle
>
> At the Orlando meeting we had a call for consensus (see the minutes of=
> the meeting at [1]) on using the current SDP bundle WG document [2] as=
> the baseline of the bundle work. That is, using the offer/answer
> exchange as outlined in the draft (subject to clarifying comments made=
> during the meeting) and using the port numbers as described in the
> draft.
>
> The other option would be to not use this as the baseline but to
> continue discussing the alternative methods.
>
> The show-of-hands at the meeting was around 30 for (going forward with=
> the method described in the WG bundle doc) and 4 against. The MMUSIC > chairs would like to confirm the consensus on this.
>
> Those who were not present at the meeting to comment on this, please d= o
> so now.
>
>
> Cheers,
> Ari
>
> [1] http://www.ietf.org/proceedings/86/minutes/minutes= -86-mmusic
> [2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundl= e-
> negotiation-03
> _______________________________________________
> 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


--047d7bea2e348af55904dacd22bc-- From ron.even.tlv@gmail.com Sun Apr 21 00:00: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 1F26A21F8B3A for ; Sun, 21 Apr 2013 00:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SUB_6CONS_WORD=0.356] 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 JOBQ6tT40nyv for ; Sun, 21 Apr 2013 00:00:41 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12F21F85B3 for ; Sun, 21 Apr 2013 00:00:41 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id m6so2714754wiv.13 for ; Sun, 21 Apr 2013 00:00:40 -0700 (PDT) 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:x-mailer:thread-index:content-language; bh=83LNEWSb85LB39JMCZJtXNLLmz80Dgkf2B0a3MxCcho=; b=r5Wn91iaeVpIPUC7R+5zh47OpkwN5lOebPGmU9tFuu3IFH8ndGfsyoKb4KIYpmai6U 5dq5GrPm+7TGa+sC+mG2WwExZpEpX40zorjqXDXLjvu+tWfn/vAS1SNNPe5H//nTnfHQ 8PqaXyjzVlXHXG/e9IL9Fd0cBxqxPk1LM3C1azU3YS3s91pbXgeFOlfK9qlNv8edpQB9 A4dlBmtFXHYu+CINVFRoIp8BfjahKJiR5iXLUWW3OR4wwO+ojX8LZLE63WrSrkVyLZuB fT39YjLci5k5sEpK+NqVz6Skgerf8QtSQTh/kcZ4voicEINzi81eNbsbeMDYjEUBbXA9 z38g== X-Received: by 10.194.109.136 with SMTP id hs8mr40673774wjb.8.1366527640293; Sun, 21 Apr 2013 00:00:40 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id a41sm33116251eei.4.2013.04.21.00.00.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 21 Apr 2013 00:00:39 -0700 (PDT) From: "Roni Even" To: , "'Flemming Andreasen'" Date: Sun, 21 Apr 2013 10:00:05 +0300 Message-ID: <014901ce3e5d$dc9ab490$95d01db0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014A_01CE3E77.01E888D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4+XVphiro19/2RT6u9MF3HQ6vEaA== Content-Language: en-us Cc: mmusic@ietf.org Subject: [MMUSIC] SDP review of draft-ietf-avtcore-clksrc-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: Sun, 21 Apr 2013 07:00:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014A_01CE3E77.01E888D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have just started a WGLC of the following AVTCORE draft http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 This draft defines new SDP attribute and have some usage examples, I would like somebody from the SDP directorate to have a look at it to make sure all SDPs in the draft are correct. Could you please get someone to do this? http://www.ietf.org/iesg/directorate/sdp.html I am cc:ing the MMUSIC list in case somebody else also wants to have a look at the draft. Thanks Roni Even AVTCore co-chair ------=_NextPart_000_014A_01CE3E77.01E888D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have = just started a WGLC of the following AVTCORE draft

 

http://t= ools.ietf.org/html/draft-ietf-avtcore-clksrc-03

 

This = draft defines new SDP attribute and have some usage examples, I would = like somebody from the SDP directorate to have a look at it to make sure = all SDPs in the draft are correct.

Could you please get someone to do = this?

 

http://www.ietf.or= g/iesg/directorate/sdp.html

 

I am = cc:ing the MMUSIC list in case somebody else also wants to have a look = at the draft.

 

Thanks

Roni = Even

AVTCore = co-chair

 

 

------=_NextPart_000_014A_01CE3E77.01E888D0-- From fluffy@cisco.com Mon Apr 22 08:25: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 7640F21F88A9 for ; Mon, 22 Apr 2013 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_55=0.6, 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 LYZq1EGHVt4m for ; Mon, 22 Apr 2013 08:25:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10221F86D9 for ; Mon, 22 Apr 2013 08:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5738; q=dns/txt; s=iport; t=1366644357; x=1367853957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2aQsk69TfwOyjhmPkdW4kWtAtXZlnIIxCYzw8zltrUk=; b=cqTxgeKaFCarAQpgiO/VfnOJwmP4JjRvI/sdWO8Hbs//F/A18vfU2Oo5 A9P5hcv7tcZXiL5Xg09d7vaARxad7vApCHTwvDbJwhQCQjZ4uJDf18wdZ F9ZIKe7Tb6xICDSK7zV10GI/5vpxompaQrBZoeVjeELFT/vcNVKuM2Pm5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAC9WdVGtJV2a/2dsb2JhbABPgwY2wQKBBhZ0gh8BAQEDAQEBAWgDCwULAgEIGAokIQYLJQIEDgUIh3oDCQYMslINiEAEjGiCJAIxB4JmYQOVMY1ghR6DDIIo X-IronPort-AV: E=Sophos;i="4.87,527,1363132800"; d="scan'208";a="201539104" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 22 Apr 2013 15:25:55 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3MFPtbn018592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 15:25:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 10:25:55 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [MMUSIC] 10 BUNDLE questions Thread-Index: AQHOP22ubRWWkZ0c50GtvuAkRDHaxg== Date: Mon, 22 Apr 2013 15:25:55 +0000 Message-ID: References: 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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 22 Apr 2013 15:25:58 -0000 On Apr 19, 2013, at 3:05 PM, Martin Thomson wrot= e: > This clarifies things for me. I hope that these are captured effectively= . >=20 > On 19 April 2013 09:19, Cullen Jennings (fluffy) wrote= : >> On Mar 15, 2013, at 2:51 PM, Justin Uberti wrote: >>> =95 From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (M= UST use same c=3D, add rtcp-mux, same a=3Dfingerprint) >>=20 >> on fingerprint, I don't think this impacts the bundle but it seems like = it make simplify the code that matches the fingerprint to the DTLS connecti= on. Be interested in hearing EKR's thoughts. >=20 > I'm not EKR, but I don't see any way that having multiple sets of > credentials would be useful. That implies multiple handshakes. well, this would only be for the initial offer and if bundle is not selecte= d, there will be multiple handshakes. I can't think of a reason that the mu= ltiple handshakes can't have the same certificate so I think I agree with y= ou >=20 > a=3Dfingerprint pertains to the transport and as such needs to be the sam= e. >=20 > You *could* add fingerprints from different lines as alternative valid > (in the same way that two a=3Dfingerprint can be added to a single > line). Since this is more likely to be mistake than something > intentional, better to require that every block in a bundle have the > same a=3Dfingerprint. >=20 >>> =95 From 6.1, list 2 - is condition 6 right? Why would we use diff= erent SDES keys for a single RTP session? >>=20 >> This is confusing in what you do in first is this, but once you know wha= t you are doing, you put what you are using which will result in same not d= ifferent keys. This needs series review from crypto experts. >=20 > In theory you can use multiple keys. And it doesn't have any real > consequences. That's not necessarily a useful property though. I just want to make sure there is not chance for a two time pad problem but= I assume that will not be a problem and we can use the same sdes key when = bundle does not get negotiated=20 >=20 >>> =95 If you start with a m=3D line with one SDES config (e.g. 32-bi= t MAC), and then BUNDLE with another SDES line with a different (non overla= pping) SDES config (e.g. 80-bit MAC), what happens? (assume fail) >>=20 >> Lets say can not do that and if you do it, it is a fail. >=20 > See above - it's *possible* to have this particular example work. But > not useful and therefore inadvisable. >=20 > I think that a good requirement is that new m=3D lines are entered into > a bundle when they are added to the session and that bundle can't > change. That means you can't move m=3D lines in and out of bundles. > That also keeps the rules with respect to properties constant for any > given m=3D line. >=20 > Sure, you could make a complicated system where this was possible, but > it probably wouldn't interoperate. +1 >=20 >=20 >>> =95 If you add a m=3D line to an existing BUNDLE, can the recipien= t reject that BUNDLEing (assume no) >>=20 >> agree it should be no >=20 > On first impressions, I was inclined to agree that it makes no sense > to allow for unbundling on new m=3D lines, but this is exactly the same > sort of scenario that an initial offer has to deal with. Offer the > addition of a stream in a bundle, but allow for the fact that peer > might not support bundling. So, I'm actually inclined to disagree > here. >=20 > That said, without a use case, such a capability complicates things. > I'll get to the use case below. >=20 >> Also imagine case where >>=20 >> Alice offers A, B, and C and offers to bundle them all >>=20 >> Bob wants to accept A and B in a bundle and C separate >>=20 >> When I talked to Justin this, I was convinced we don't want to bother to= support this as it complicated gathering ports for future offers. So what = it comes down to the device receive the offer can either accept the bundle = or not. (and separate accept or reject each m line in the bundle but can't = refactor the bundling). >=20 > This is actually the same sort of problem as the above. The question > is whether the bundle is negotiated as a whole, or whether answers can > differentiate on per-line basis. I can appreciate the desire to > simplify, but you have to examine use cases. >=20 > Example: Alice offers A and B bundled, Bob accepts the bundling. > Later, Alice adds C to the bundle. How can Bob get that m=3D line > routed over a different path? Do we require that Bob reject the line > and offer the same line, potentially inverted, without bundling in a > subsequent offer? >=20 > I'm thinking here about a case where a session escalates from audio to > audio+video and there might be a middlebox involved. I guess in that > case the middlebox needs to drive the addition. >=20 > I can probably live with the simplification, but this needs to be > crystal clear. A more complete discussion of the implications of this > particular choice would be really helpful. +1 on we need to be crystal clear.=20 I think I am leaning towards once a bundle is set up, a new update to it ca= n offer things in the bundle or not it the bundle. And if offered in the bu= ndle, the answer can choose to put it in the bundle or not. But I want to a= void all things like the answer can move a m-line from one one bundle to an= other bundle or something like that. It's too complicated and I don't see t= he need for it.=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Mon Apr 22 08:55: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 92D1021F9075 for ; Mon, 22 Apr 2013 08:55:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPBRJj9Uv-oD for ; Mon, 22 Apr 2013 08:55:19 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ECB5621F9318 for ; Mon, 22 Apr 2013 08:55:12 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1491299wib.11 for ; Mon, 22 Apr 2013 08:55:12 -0700 (PDT) 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=yUuDb+AnrqL53jq9h3WtvX+zMaFKtLYCAGlrkKAwPns=; b=BWK8E2C/hKo4svNSYesinehXkhFIWKUJpwAotFfYe3v7n5UKq/WMLA0i27ABEpmUAJ CoDKkLPIhgfpopaz9q5oeJngJ5FJku1yejdsAI0MDOTFohIY+TxU3VQ0IG3rAIz3rKBJ t1TpLaxeGB6/3j7c8CFynrAFFRpMH6g1xOavq019NvmkyfefZa/EiWVCTUzm3BSlbDmY FH1iPqqXjpdNNquxNsQQzH5O8TTYuQmBoY5JaC0u3iBH5iYwoQIeM1nruj43+4bJ2AsS rkhaW0fYYQt4dNltv5Fj5zsb7bGf1ryKkmtGFf4mU1WSICPinaExsBnD4slNkpV/DkqG G5pg== MIME-Version: 1.0 X-Received: by 10.194.235.196 with SMTP id uo4mr53675704wjc.30.1366646111858; Mon, 22 Apr 2013 08:55:11 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 22 Apr 2013 08:55:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Apr 2013 08:55:11 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 22 Apr 2013 15:55:20 -0000 On 22 April 2013 08:25, Cullen Jennings (fluffy) wrote: >> In theory you can use multiple keys. And it doesn't have any real >> consequences. That's not necessarily a useful property though. > > I just want to make sure there is not chance for a two time pad problem b= ut I assume that will not be a problem and we can use the same sdes key whe= n bundle does not get negotiated The two time pad problem only arises if you have the same SSRC. That's only possible with a shim, not if you have streams sharing the same session. There is a problem with SSRC collisions (in SSRC space only, even if the collision isn't contemporaneous). SRTP has always had that problem and it's rare enough that no attacker could rely on it happening. > I think I am leaning towards once a bundle is set up, a new update to it = can offer things in the bundle or not it the bundle. And if offered in the = bundle, the answer can choose to put it in the bundle or not. But I want to= avoid all things like the answer can move a m-line from one one bundle to = another bundle or something like that. It's too complicated and I don't see= the need for it. That was my thought too. That means that bundling is negotiated in two ways: one to turn bundling on or off as a whole. The second is the choice to add a new stream - or allow a new stream to be added - to a bundle, or not. Once negotiated, you can't move them around. If you need that, drop the line and make another one. That's not especially difficult. From pkyzivat@alum.mit.edu Mon Apr 22 09:47: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 2C61521F93BA for ; Mon, 22 Apr 2013 09:47:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaF8tje5NcUk for ; Mon, 22 Apr 2013 09:47:11 -0700 (PDT) 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 4CF7621F93B7 for ; Mon, 22 Apr 2013 09:47:05 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id T1pX1l0091YDfWL514n5CT; Mon, 22 Apr 2013 16:47:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id T4n51l0093ZTu2S3g4n5TT; Mon, 22 Apr 2013 16:47:05 +0000 Message-ID: <51756988.9040805@alum.mit.edu> Date: Mon, 22 Apr 2013 12:47:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: 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=1366649225; bh=Eyg/tEU7lXZIH6xsQtLcJx8oBiFDwluukmgfTcf/ZOM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YsPNG7OWIfy29GQ+XpPBB/WC8r/8Yzfz+/SZCY8TIn8ymgYjHvQrjxkqzGMItR0KA Cg9BNDPdhjp1O8sT7T52v0twLlmYppBo/E2KbQfoDFZmZYe+VYJNEi6XRaYPWbw+0H lrXCHKKtPbiYeSPrSzbrv+dB7sSK8ZWcSzbQ9qpj7KipNHgPNGXjxWd2Dt9l73N6RU ZI7+RlCWnzdQGERTP/L+SdPBTayhJGXoFzVcrhtdzrI8HSIbWRas0h6TbB5yUk4F1/ HeGez5z2sl/RNvu4VltvZlERA0rKunF6ayPu05d43Y7s+LgA3PDSTfQKFzFa3/vB2S 8iVr3cMzRGgiQ== Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 22 Apr 2013 16:47:12 -0000 On 4/19/13 12:19 PM, Cullen Jennings (fluffy) wrote: > > On Mar 15, 2013, at 2:51 PM, Justin Uberti wrote: > >> The list below is a set of questions (some marked as OPEN ISSUE already) regarding the new BUNDLE proposal. If you agree with my suggested answers, I'm willing to contribute text accordingly. >> • Can you create a BUNDLE with a single m= line? (assuming yes) > > yes, have to to add more later > >> • Can you create multiple BUNDLEs? (assuming yes) > > yes but a given m line can only be in one > >> • When creating an initial offer, how should we deal with the case where a "null" port is to be used with trickle ICE (since 6.1:1 indicates the ports MUST be different) > > I think we should change bundle to allow the null port > - it really needs to be all the parameters related to transport / crypto need to be different, or at least as different as they would be required to be if you were not doing bundle. Key thing is if other side does not understand bundle, this looks like an "normal" offer with no bundle. When you say "null" port, do you mean *zero* port? There is a technical problem with this. RFC5888, section 9.2, says: SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero. This means you can't initially establish a bundle group including m-lines with zero ports and then negotiate a non-zero port later. To work around this we would either need to use some other port (e.g. 9 - discard) to indicate no media is initially to be sent, or else change RFC5888. Even then it would be necessary to change allow bundle to allow multiple bundled m-lines to have the same port in this case. >> • If m= lines are rejected, should their mids show up in the BUNDLE answer? (assume yes?) > > don't care but we need to be clear should happen. See above. This is currently specified by 5888. IMO what is specified by 5888 is unfortunate. I'm undecided whether its better to try to work around it or change it. >> • If not, how does remote side indicate BUNDLE support if it rejects the m= lines that are BUNDLEd? >> • Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no) > > In SIP terminology, I think we would do this with an "INVITE with replaces". If you want to do this, you just start a whole new offer that is not an evolution of the previous set of offer/answers. So basically I am saying not to do this at the bundle level but instead support it at the signaling level. IMO it would be better to allow bundling to be changed in a subsequent O/A, just as anything else it. >> _______________________________________________ > > Also imagine case where > > Alice offers A, B, and C and offers to bundle them all > > Bob wants to accept A and B in a bundle and C separate > > When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling). This is a subcase of "splitting" a bundle, which I posted on earlier: http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html IMO it *must* be permissible to accomplish this in some way. For the case of splitting one bundle into two bundles, I concluded that it will take another O/A. Just leaving some of the proposed bundle candidates out of single bundle seems to be acceptable to 5888. I see no reason to circumvent that for bundle groups. Thanks, Paul From andrew.hutton@siemens-enterprise.com Mon Apr 22 14:22: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 51BAC21F8E6E for ; Mon, 22 Apr 2013 14:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 DGc-V9ZCBoth for ; Mon, 22 Apr 2013 14:22:29 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id CC94921E80A3 for ; Mon, 22 Apr 2013 14:22:09 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5EB7123F0596; Mon, 22 Apr 2013 23:22:06 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 23:22:06 +0200 From: "Hutton, Andrew" To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 Thread-Index: AQHOPGMxnN/mV6b67keOupOlzSkFyZjixYkw Date: Mon, 22 Apr 2013 21:22:04 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6BBDA8@MCHP04MSX.global-ad.net> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net> <201304181833.r3IIXHcr2960017@shell01.TheWorld.com> In-Reply-To: <201304181833.r3IIXHcr2960017@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] draft-hutton-mmusic-bundled-ice-candidates-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, 22 Apr 2013 21:22:30 -0000 On: 18 April 2013 19:33 Dale R. Worley Wrote: >=20 > I suppose what is bothering me is that > draft-hutton-mmusic-bundled-ice-candidates modifies the procedures of > draft-ietf-mmusic-sdp-bundle-negotiation, and > draft-ietf-mmusic-sdp-bundle-negotiation modifies the procedures RFC > 5245. Neither modification is large, but stacking two > weakly-specified modifications together makes me worry that nobody has > a clear understanding of what the combined procedure really is, and it > is hard to examine the combined procedure for unintended consequences. >=20 [AndyH] I agree which is why I thought that if we decided draft-hutton-mmus= ic-bundled-ice-candidates was useful it would be incorporated in to the bun= dle draft. > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From andrew.hutton@siemens-enterprise.com Mon Apr 22 14:46: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 8936221E80AF for ; Mon, 22 Apr 2013 14:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 VACiNGUM8g2L for ; Mon, 22 Apr 2013 14:46:11 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E565C21E809C for ; Mon, 22 Apr 2013 14:46:10 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5B18C23F059A; Mon, 22 Apr 2013 23:46:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 22 Apr 2013 23:46:10 +0200 From: "Hutton, Andrew" To: Christer Holmberg , "Markus.Isomaki@nokia.com" , "worley@ariadne.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 Thread-Index: AQHOO6+0nN/mV6b67keOupOlzSkFyZjcFsQAgAEV1pCABZuhcA== Date: Mon, 22 Apr 2013 21:46:08 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0E6BBDE5@MCHP04MSX.global-ad.net> References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C327739@ESESSMB208.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C327739@ESESSMB208.ericsson.se> 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] draft-hutton-mmusic-bundled-ice-candidates-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, 22 Apr 2013 21:46:13 -0000 Comments below. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 19 April 2013 10:13 > To: Markus.Isomaki@nokia.com; worley@ariadne.com; mmusic@ietf.org > Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 >=20 > Hi, >=20 > > I also reviewed the draft and was trying to understand what problems > it is trying to solve. It is easier to find a solution if we > > agree on the requirements. From the draft I gathered that it tries to > address at least these two limitations in [1]: > > > >1.) > > > > A problem with the existing bundling proposals is that it does not > > appear possible to create a single initial offer that will allow > > bundle to be negotiated but maintain interworking with bundle > unaware > > implementations and therefore it is necessary to perform an initial > > offer/answer exchange which does not fully describe or at least > only > > implicitly describes what the offerer really wants to offer. The > > existing bundle proposals also don't take account of the fact that > > when both parties support ICE [RFC5245] the port in the m-line of > the > > initial offer may not be used at all, for example due to a dual > stack > > offer endpoint offering IPv4 and IPv6 addresses in parallel. >=20 > The fact that you may end up not using the port in the m- line is > normal ICE procedures. But, I do agree that we should add some text > about that. [AndyH] - I agree. >=20 > > Markus: This is a relevant point if indeed call setup time or even > the number of messages can somehow be reduced in some of the > > situations. But is that the case here? I think that if both peers > support bundle (as in [1]), they can start bundle-related connectivity > checks > > immediately, and do not need to do any other connectivity checks. Is > there a substantial difference in this regard? [AndyH] - No. The difference is only that everything relating to the candid= ate is explicit within the candidate line which makes it more readable and = less prone to errors. > > > > 2.) > > > > Also the existing bundle proposals have not considered some of the > > more complex ICE scenarios involving multiple candidates. For > > example when an SDP m-line contains multiple ICE host candidates > > during dual stack negotiation, the candidates cannot be considered > > equivalent with regard to bundling with candidates on in another > > m-line and therefore some way of indicating which candidates can be > > bundled seems to be desirable. This could be achieved by including > > the complete bundle transport address (IP and Port) in the > candidate > > or by providing some kind of bundle linkage within the ICE > candidate > > lines. > > > > Markus: This seems to support exotic situations like that the offerer > would be willing to bundle over > > IPv6, but not over IPv4. Personally I'm not sure if there are good > real use cases for this type of capability. > > Any concrete ideas where this would be useful? >=20 > I don't really think we need to consider this. If an endpoint wants to > change its candidates, e.g. based on whether bundle will be used or > not, it can send a new offer, with new candidates. [AndyH] I am not so convinced and not sure I understand the comment about c= hanging the candidates with a new offer. If anybody wants to specify a bund= le where it is only possible to bundle some candidates and not others then = we would not have a way of doing this. The bundle over IPv6 but not IPv4 is= one case but more likely it could be that say host candidates can be bundl= ed but not relay candidates.=20 >=20 > Regards, >=20 > Christer >=20 >=20 > [1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle- > negotiation/ >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Dale R. Worley > Sent: 18 April, 2013 00:07 > To: mmusic@ietf.org > Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00 >=20 > It seems to me that the essence of > draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE > candidates to effectively specify two address/ports that is available > for the remote UA to contact this UA. One address/port is the standard > ICE address/port and the other is the "bundleport", and indicates an > address/port that the remote UA can contact using bundled/multiplexed > media. >=20 > If the candidates for two different m=3D lines specify the same > bundleport, it would be useful to define the ICE procedures to ensure > that connectivity to that address/port is tested only once for any > remote address/port. If the remote UA is not bundling/multiplexing, > this does not change anything, as connectivity has to be tested > separately for each transport association (5-tuple). But if both ends > are using bundling, we could have 3 m=3D lines for each UA, but only > effectively one set of candidate address/ports at each end. We > wouldn't want to repeat the connectivity checks 3 times over. >=20 > Also, what is the order of testing of ICE candidates if bundleport is > present? My understanding is that ICE was carefully designed so that > both UAs test each candidate pair simultaneously. What is the > timing/sequencing rules when bundleport is present to ensure that (1) > both UAs test each pair simultaneously, (2) the bundleport > address/ports are tested first if both ends support bundling, and (3) > the timing of "baseline" candidate testing is unchanged if either UA > does not support bundling? It seems like we need a careful > specification of the changes to the candidate testing algorithm. >=20 > 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 Simo.Veikkolainen@nokia.com Tue Apr 23 01:37: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 3D2D021F91B7 for ; Tue, 23 Apr 2013 01:37:31 -0700 (PDT) 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.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 UYlVNmj++41T for ; Tue, 23 Apr 2013 01:37:29 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 217DB21F894E for ; Tue, 23 Apr 2013 01:37:28 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r3N8bDYC021198; Tue, 23 Apr 2013 11:37:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Apr 2013 11:37:14 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.240]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0328.011; Tue, 23 Apr 2013 08:37:13 +0000 From: To: , Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: AQHOO3h4GI1XUw+H1UKVjshlEllXf5jjVzIg Date: Tue, 23 Apr 2013 08:37:12 +0000 Message-ID: References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> In-Reply-To: <516EB28A.1050003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJ6f+e0jPWCKW7SGpJea1HxF1+/yLcs1+3lx3oszWyEpFv854jwBDNm5uGBrLhHEq2uJVa1v3Zy3IaDHnDpP8YdeWJoIxth58+K+iDrSfX6VQ02aQvlegHvqg5/RXW70sT2gWMegB3w4ZokmZ6TonQusO76vvQMHR/vQU0QPUC11SVb40uqfcnkx/QGq/+rxh6PjGmIEYoBsFtbNHhKJpsDCi2sWHkj6c1vywSqwUPIuCiLtKIL2Gu8XWL0WJgw3GKD0xnlqe8LYUvX+UUenTVQQ== x-originating-ip: [10.236.9.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2013 08:37:14.0295 (UTC) FILETIME=[C1519C70:01CE3FFD] X-Nokia-AV: Clean Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 23 Apr 2013 08:37:31 -0000 Below the original and proposed text on the usage of ccap attribute in Sect= ion 3.1.2. of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneou= s-caps-04=20 This is pretty much the same text I proposed earlier, including Jonathan's = wording on IN address families.=20 --- begin original text --- The 'ccap' capability attribute allows for expressing alternative connection address ('c=3D') lines in SDP as part of the SDP capability negotiation process. The 'ccap' capability attribute is intended to be used only when there is no other mechanism available for negotiating alternative connection address information, such as when the is different among the alternative addresses (e.g. "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in situations where an existing mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245]) can be used to select between different connection addresses (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). --- end original text --- --- begin proposed text --- The 'ccap' capability attribute is intended for offering alternative connection addresses where the is "IN" or "PSTN", i.e. selecting between an IP based bearer or a circuit-switched bearer. The 'ccap' attribute MUST NOT be used to indicate more=20 than one address with an IN network type in actual=20 or potential configurations for any given media description=20 (e.g. between "IP4" and "IP6" address families or different=20 IP addresses within the same IP address family). --- end proposed text--- Also, since no alternative port numbers can be offered, add this sentence a= t the end the of the last paragraph to clarify how alternative IP and PSTN = media descriptions are offered: This document does not define any mechanism for negotiating or describing different port numbers and hence the port number from the "m=3D" line MUST be used by default. Exceptions to this default can be provided by extension mechanisms or network type specific rules. This draft defines an exception when the network type is "PSTN", in which case the port number is replaced with 9 (the "discard" port) as described in Session Decription Protocol (SDP) Extension For Setting Up Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. --- begin new text --- An endpoint offering alternative IP and PSTN bearers MUST include the=20 IP media description in the actual configuration (IP address in the "c= =3D" line and port number in the "m=3D" line), and the PSTN media descriptions in = the=20 potential configuration. --- end new text --- Regards, Simo -----Original Message----- From: ext Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: 17. huhtikuuta 2013 17:33 To: mohamed.boucadair@orange.com Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com; HKaplan@acm= epacket.com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsso= n.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (d= raft-ietf-mmusic-sdp-miscellaneous-caps-04) On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: > Hi Felmming, > > Because it does not allow to indicate an alternate port number. Correct - a connection address does not provide a port number; a different = capability would be needed for that. > This makes it a no working solution for various scenarios. No - it simply means that you would need to define another capability to co= nvey port numbers if you wanted such a solution (however we have ICE as the= complete solution for that and the WG has not indicated a desire to change= that). > The text which triggered this discussion was confusing. I hope the update= d version will be much more clear and reflect what have been discussion so = far in this thread. I have asked Simo to update the draft. Thanks -- Flemming > Cheers, > Med > >> -----Message d'origine----- >> De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy=E9 : samedi=20 >> 13 avril 2013 02:40 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc :=20 >> Simo.Veikkolainen@nokia.com; aallen@blackberry.com;=20 >> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;=20 >> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data=20 >> Capability (ccap) and IP-addresses >> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> >> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>> Hi Simo, >>> >>> I'm in favor of restricting the alternative address to PSTN. >> Can you elaborate on why ? >> >> We have defined a generic connection data capability as part of a=20 >> general capability negotiation framework. What's the point of that if=20 >> the only value it can convey is PSTN ? >> >> Thanks >> >> -- Flemming >> >> >>> This is coherent whit your first bullet below. >>> >>> If you share the text changes you are proposing, this would be more >> easier to review. >>> Thanks for taking care of this issue. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la=20 >>>> part >> de >>>> Simo.Veikkolainen@nokia.com >>>> Envoy=E9 : lundi 8 avril 2013 08:35 >>>> =C0 : fandreas@cisco.com; aallen@blackberry.com;=20 >>>> HKaplan@acmepacket.com Cc : jonathan@vidyo.com; mmusic@ietf.org;=20 >>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data=20 >>>> Capability (ccap) and IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> Recapping the discussion so far: >>>> >>>> >>>> - ICE is the way to negotiate between different IP addresses. There >> seems >>>> to be no disagreement here. >>>> >>>> - since no alternative port number can be expressed, in practice=20 >>>> the IN address needs to go to the actual configuration (address in=20 >>>> the c=3D line >> and >>>> port number in the m=3D line), and the alternative PSTN address in=20 >>>> the potential configurations. Also here, there seems to be no disagree= ment. >>>> >>>> - then, whether the "ccap" attribute should be limited to carry=20 >>>> only >> PSTN >>>> addresses, or also other types. I'm with Flemming on this one; SDP >> capneg >>>> framework is already fragmented enough, and limiting the connection >> address >>>> capability to PSTN addresses only would again be targeted for a=20 >>>> single >> use >>>> case only, whereas we should strive for general solutions. >>>> >>>> Simo >>>> >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>>> Behalf >> Of >>>> ext Flemming Andreasen >>>> Sent: 25. maaliskuuta 2013 3:32 >>>> To: Andrew Allen >>>> Cc: jonathan@vidyo.com; mmusic@ietf.org;=20 >>>> christer.holmberg@ericsson.com >>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 >>>> IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>> >>>> >>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>> There is also nothing that prevents people from defining their own >>>> proprietary attributes to do such a thing but that is not part of=20 >>>> an >> IETF >>>> standard and is not approved usage. >>>> Agreed. >>>> >>>>> If we really feel the need to discourage further such usage I=20 >>>>> suppose >> we >>>> could add some text stating that if CCAP s received containing an=20 >>>> IN net type and an IN net type is present in the corresponding=20 >>>> Connection Attribute then the CCAP attribute MUST be ignored. >>>> I think that gets complicated quickly for a questionable gain. I'd=20 >>>> prefer the "MUST NOT" described below with an explanation as to why=20 >>>> it's there; as you note, ultimately people either decide to be spec=20 >>>> compliant or not. >>>> >>>> -- Flemming >>>>> That way compliant implementations would not perfom the=20 >>>>> discouraged >>>> behavior. >>>>> Andrew >>>>> >>>>> ----- Original Message ----- >>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>> To: Christer Holmberg >>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>> >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP= - >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> In general I agree that having multiple ways of doing the same=20 >>>>>> thing >> is >>>> not a good thing, and I don't have any strong feelings regarding=20 >>>> the >> ccap >>>> usage. >>>>>> But, no matter what we say, what would actually prevent people=20 >>>>>> from >>>> using ccap, in the same way they are using ANAT and altc? :) >>>>> There's no port signaling capability with ccap, but other than=20 >>>>> that, >> the >>>>> only thing that prevents people from using this to signal=20 >>>>> alternative IP-addresses is the existence of a "MUST NOT" in the spec= . >>>>> >>>>> -- Flemming >>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf=20 >>>>>> of >>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>> To: Flemming Andreasen >>>>>> Cc: mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> Currently, the deployed SIP world has three mechanisms to allow=20 >>>>>> some >>>> flavor of negotiation among multiple IP addresses: ICE, altc=20 >>>> (despite >> the >>>> general disapproval of the working group), and ANAT (despite its=20 >>>> deprecation). >>>>>> I think that adding ccap as a fourth member of this set would be=20 >>>>>> a >>>> terrible idea; and as far as I can tell, no one wants to do that. =20 >>>> So we need to make it clear that that it MUST NOT be used for that pur= pose. >>>>>> In the formulation below, I think I'd say that a given media >> description >>>> MUST NOT indicate more than one address with an IN network type,=20 >>>> across >> all >>>> its configurations (actual and potential). >>>>>> Obviously, different media descriptions (m=3D line blocks) can have >>>> different addresses. >>>>>> In practice, given the port number issue that started this=20 >>>>>> thread, I >>>> suspect this means that the SDP offer will need to put the IN=20 >>>> address in the actual configuration (in the c=3D line), and the PSTN=20 >>>> address(es) will >> be >>>> in the potential configurations. >>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>> >>>>>>> Still waiting for more comments on this, especially from the=20 >>>>>>> people >>>> that >>>>>>> were very vocal in their complaints previously: Now is the time=20 >>>>>>> to >>>> speak up. >>>>>>> Regardless, a few comments on the below: >>>>>>> 1) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>> more >> "IP4" >>>>>>> addresses in a given SDP. >>>>>>> 2) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>> more >> "IP6" >>>>>>> addresses in a given SDP. >>>>>>> >>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>> The "ccap" attribute is not what is being to select between=20 >>>>>>> different IP-addresses; the use of a "ccap" attribute in a=20 >>>>>>> potential >>>> configuration >>>>>>> ("pcfg") is what is being used for this. Is the restriction that=20 >>>>>>> we >>>> want >>>>>>> here: >>>>>>> a) A potential configuration MUST NOT reference more than one "ccap= " >>>>>>> attribute with a network type of "IN" ? >>>>>>> b) All potential configurations for a particular media=20 >>>>>>> description >> MUST >>>>>>> NOT reference more than one "ccap" attribute with a network type=20 >>>>>>> of >>>> "IN" ? >>>>>>> c) Something else ? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>> I am OK with either of these proposals >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>> On >>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>> I went through the discussion, and my reading is that there is >>>> agreement on not allowing ccap to be used for alternative IP=20 >>>> address negotiation. >>>>>>>> That could be made clear in the text e.g. by modifying the=20 >>>>>>>> second >>>> sentence Flemming quoted to read: >>>>>>>> >>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>> between different IP connection addresses (e.g. between >>>>>>>> "IP4" and "IP6" address families or different IP addresses >>>>>>>> within the same IP address family). >>>>>>>> >>>>>>>> >>>>>>>> The ccap attribute should be able to carry either an IP or PSTN >>>> address; that way either a PSTN or an IP bearer could be offered as=20 >>>> the highest priority configuration (in the "m=3D" line). However, if= =20 >>>> we want >> to >>>> clarify the intended use of ccap, we could modify the first=20 >>>> sentence to >>>> read: >>>>>>>> >>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>> alternative connection addresses where the >>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>> bearer or a circuit-switched bearer. >>>>>>>> >>>>>>>> >>>>>>>> Simo >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>> On >>>> Behalf Of ext Flemming Andreasen >>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>> To: mmusic >>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>>>>> IP-addresses >>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>> Greetings >>>>>>>> >>>>>>>> As you may have seen, there has recently been some list=20 >>>>>>>> discussion >> on >>>> the "connection data capability" defined in >>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.ht >>>>>>>> ml) >>>>>>>> >>>>>>>> To recap, the connection data capability ("ccap") provides >> capability >>>> negotiation capabilities for what amounts to the "c=3D" line in=20 >>>> regular >> SDP, >>>> and as such enables negotiation of network type (such as "IN") and=20 >>>> IP- address information (v4 and v6 addresses). The Standards Track=20 >>>> mechanism for negotiating and determining alternative IP-address=20 >>>> information today >> is >>>> ICE, and hence the draft currently includes the following wording: >>>>>>>> >>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>> be used only when there is no other mechanism available fo= r >>>>>>>> negotiating alternative connection address information,=20 >>>>>>>> such >> as >>>> when >>>>>>>> the is different among the alternative=20 >>>>>>>> addresses >> (e.g. >>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used i= n >>>>>>>> situations where an existing mechanism (such as Interactiv= e >>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used=20 >>>>>>>> to >>>> select >>>>>>>> between different connection addresses (e.g. "IP4" and "I= P6" >> or >>>>>>>> different IP addresses within the same IP address family). >>>>>>>> >>>>>>>> >>>>>>>> The above text has led to some confusion as to exactly when and=20 >>>>>>>> what >>>> "ccap" can be used for. More specifically, is it/should it ever be >> allowed >>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under=20 >>>> what circumstances ? >>>>>>>> If you have an opinion, please let us know. >>>>>>>> >>>>>>>> A couple of points to keep in mind: >>>>>>>> - The current document has been WGLC'ed without comment ~6=20 >>>>>>>> months >> ago. >>>>>>>> - 3GPP has a dependency on the document (however I'm not sure=20 >>>>>>>> if >> that >>>> dependency includes the above "IN" feature) >>>>>>>> - The connection data capability is defined in a general manner=20 >>>>>>>> to >> be >>>> generally useful in line with the overall capability negotiation >> framework >>>> (as opposed to targeted at one specific use case with one specific >> value) >>>>>>>> - There are scenarios where ICE cannot be used, even if=20 >>>>>>>> implemented >>>> (e.g. ice-mismatch). >>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >> absence >>>> of ICE support >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- 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 >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- >> - >>>>>>>> This transmission (including any attachments) may contain >> confidential >>>> information, privileged material (including material protected by=20 >>>> the solicitor-client or other applicable privileges), or constitute=20 >>>> non- >> public >>>> information. Any use of this information by anyone other than the >> intended >>>> recipient is prohibited. If you have received this transmission in >> error, >>>> please immediately reply to the sender and delete this information=20 >>>> from your system. Use, dissemination, distribution, or reproduction=20 >>>> of this transmission by unintended recipients is not authorized and=20 >>>> may be unlawful. >>>>>>>> . >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>> -- >>>>>> Jonathan Lennox >>>>>> jonathan@vidyo.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- This transmission (including any attachments) may contain=20 >>>>> confidential >>>> information, privileged material (including material protected by=20 >>>> the solicitor-client or other applicable privileges), or constitute=20 >>>> non- >> public >>>> information. Any use of this information by anyone other than the >> intended >>>> recipient is prohibited. If you have received this transmission in >> error, >>>> please immediately reply to the sender and delete this information=20 >>>> from your system. Use, dissemination, distribution, or reproduction=20 >>>> of this transmission by unintended recipients is not authorized and=20 >>>> may be unlawful. >>>>> . >>>>> >>>> _______________________________________________ >>>> 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 Tue Apr 23 07:26: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 4EA0A21F96AA for ; Tue, 23 Apr 2013 07:26:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw3Y+i+Oy3o7 for ; Tue, 23 Apr 2013 07:26:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 97B9E21F969F for ; Tue, 23 Apr 2013 07:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1220; q=dns/txt; s=iport; t=1366727188; x=1367936788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5nbH+0fqKBW9/UKmPdutDCDVSVMFc4t/cKO32esKr7M=; b=fWTjmLOtgWzrpYLu+tB5Fp4ta/uDzqX1e9AZWhe5gBt3D55P/b3MS5T2 QZ2tG+HIzma9u1J9NGPpNl2TtzG7JLfRpz+jEFJOxBb2ierIP/MMADOLj Z7yAPvr61hccF1hci4yc8TpzZYQy3RQLLi+bXUIFeHZO/OPD8ZoWggx0x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK6YdlGtJXG9/2dsb2JhbABQgwY2wRuBARZ0gh8BAQEEHRUBBUEQIwklDwJGBg0BBwEBBYgLDK00jyqNdoEyB4NJA5cagSOPeoMqIIE3 X-IronPort-AV: E=Sophos;i="4.87,533,1363132800"; d="scan'208";a="201997307" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 23 Apr 2013 14:26:28 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3NEQRUx009945; Tue, 23 Apr 2013 14:26:27 GMT Message-ID: <51769A13.60502@cisco.com> Date: Tue, 23 Apr 2013 10:26:27 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic References: <516C071B.5050204@ericsson.com> In-Reply-To: <516C071B.5050204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: [MMUSIC] Confirmed [Re: Confirming consensus on way forward with 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: Tue, 23 Apr 2013 14:26:29 -0000 Thank you all for the responses. Based on the e-mail thread, the consensus decision from the Orlando meeting still stands in accordance with the below. Thanks -- Ari & Flemming (MMUSIC chairs) On 4/15/13 9:56 AM, Ari Keränen wrote: > At the Orlando meeting we had a call for consensus (see the minutes of > the meeting at [1]) on using the current SDP bundle WG document [2] as > the baseline of the bundle work. That is, using the offer/answer > exchange as outlined in the draft (subject to clarifying comments made > during the meeting) and using the port numbers as described in the draft. > > The other option would be to not use this as the baseline but to > continue discussing the alternative methods. > > The show-of-hands at the meeting was around 30 for (going forward with > the method described in the WG bundle doc) and 4 against. The MMUSIC > chairs would like to confirm the consensus on this. > > Those who were not present at the meeting to comment on this, please > do so now. > > > Cheers, > Ari > > [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic > [2] > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03 > . > From worley@shell01.TheWorld.com Tue Apr 23 08:32: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 37A1621F9676 for ; Tue, 23 Apr 2013 08:32:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xelj12PBAsG for ; Tue, 23 Apr 2013 08:32:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id AC93921F943C for ; Tue, 23 Apr 2013 08:32:02 -0700 (PDT) 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 r3NFUAjO019299 for ; Tue, 23 Apr 2013 11:30:37 -0400 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 r3NFU9x83244021 for ; Tue, 23 Apr 2013 11:30:09 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3NFU9mB3237170; Tue, 23 Apr 2013 11:30:09 -0400 (EDT) Date: Tue, 23 Apr 2013 11:30:09 -0400 (EDT) Message-Id: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 23 Apr 2013 15:32:03 -0000 Here are a few desiderata related to dealing with legacy devices, both endpoints and intermediate devices: 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. Comments? Dale From martin.thomson@gmail.com Tue Apr 23 09:16: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 B99C521F96EA for ; Tue, 23 Apr 2013 09:16:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZUGqr8VgTak for ; Tue, 23 Apr 2013 09:16:59 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA521F96E9 for ; Tue, 23 Apr 2013 09:16:58 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so3127009wib.17 for ; Tue, 23 Apr 2013 09:16:58 -0700 (PDT) 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=sb/buVMiQpsB546Ztn4lq+qPVuTFRKbzxs6vLBmS3kc=; b=f2G7q1bY4siSrPhbd1OoSQLws8gONDQ2ZF5iGgqFMvlJ2fTAJc0jCGKjAjNxi/HRZP xMqShK6b4JTgLLaRd+CYWgn0ZGHpBuW3m3jj6PqKaTno8rIN4+YmnbIt4DDj3R8BeFga e+dFAwgH4iTlc7YWfG0fLsYcAZfJWiYd6QP1Z4r9eRY7+RgaG/H23H7h9/zbrfUmT/Za pKtmSY9cgOkQtnDe2sXQtoYjD9OeSRYYlmAs+Nsdiwsrz11SCZp9zwiseAtoQlwyH4DA eIVJnbHsRAYB+A27hBJyDCqcjdmrwKHcjVrK3LCC5Rqu/G5W3J97xQYTY8CKB2pFy3xl fBUQ== MIME-Version: 1.0 X-Received: by 10.180.74.146 with SMTP id t18mr46977404wiv.26.1366733818158; Tue, 23 Apr 2013 09:16:58 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 23 Apr 2013 09:16:58 -0700 (PDT) In-Reply-To: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> Date: Tue, 23 Apr 2013 09:16:58 -0700 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 23 Apr 2013 16:16:59 -0000 C3 and C4 look good. On 23 April 2013 08:30, Dale R. Worley wrote: > 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. I'm not sure how to parse this. Is that a double-negative or just two negatives for emphasis? Do you intend to say that the solution should NOT rely on new attributes because SBCs will suppress them, or that the solution is permitted to use new attributes because SBCs are expected to pass attributes. Non-requirements and non-constraints are always difficult to get right. From christer.holmberg@ericsson.com Tue Apr 23 10:59: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 3771B21F9627 for ; Tue, 23 Apr 2013 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB7CeHys2Uil for ; Tue, 23 Apr 2013 10:59:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B95721F96E8 for ; Tue, 23 Apr 2013 10:59:03 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-c5-5176cbe6cae7 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E7.B6.19728.6EBC6715; Tue, 23 Apr 2013 19:59:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 23 Apr 2013 19:59:01 +0200 From: Christer Holmberg To: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQDe3i+cVnxjNCEKSb6lvFRbbnJjkDbqr Date: Tue, 23 Apr 2013 17:59:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> In-Reply-To: <201304231530.r3NFU9mB3237170@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+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvre6z02WBBh2nBC2mLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAldHf9YaxoIWzoq/vCUsD4ye2LkZODgkBE4m3 3Z8ZIWwxiQv31oPFhQQOM0rsOajWxcgFZC9hlGhYcYy5i5GDg03AQqL7nzZIjYiAn8T6VR/Y QWxhoPD5lpPMEHFLiZvLz7NA2EYSN/uegsVZBFQlXq99wApi8wr4Smxfd5cJYpe9xKsPb8H2 cgo4SBw82QVmMwLd8/3UGrAaZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rCCnSQgoSizvl4Mo 15FYsBviRWYBbYllC18zQ6wVlDg58wnLBEbRWUimzkLSMgtJyywkLQsYWVYxsucmZuaklxtt YgRGwcEtv1V3MN45J3KIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxur3 ilGrf8+/4Nzwx/Rb4tPFL/Ws4/1cWDZd/idaIquxvtZgp8Ma1ibtQz/WbrS8fC/6yII7nIu2 yaV+fL1pPfvCoJRf9r3LvYIWujb+1mk8xinGzKtb6ixgLiincbzVNfJs1XGDX/ZMT87o1Ilv 5V4oou1W+GRZs9Jkhy7fDw+mn25vfvJOWomlOCPRUIu5qDgRADJGyZRQAgAA Subject: Re: [MMUSIC] Feedback requested on requirements 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, 23 Apr 2013 17:59:04 -0000 Hi, >Here are a few desiderata related to dealing with legacy devices, both >endpoints and intermediate devices: > > DES C3 Avoid using media types in m=3D 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. I am not sure I understand. Why would one use media types unless required f= or user media? > DES C4 Any additional m=3D lines prescribed by the bundle mechanism > should be ordered after the constituent m=3D lines. That is normal Offer/Answer procedure, isn't it? > Many devices that have only one audio or video channel accept the > first m=3D 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. I don't understand this. Regards, Christer From worley@shell01.TheWorld.com Tue Apr 23 12:06: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 8045321F960E for ; Tue, 23 Apr 2013 12:06:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dvK6C4fsjmg for ; Tue, 23 Apr 2013 12:06:08 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id D5E3621F9603 for ; Tue, 23 Apr 2013 12:06:07 -0700 (PDT) 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 r3NJ5bm6023987; Tue, 23 Apr 2013 15:05:39 -0400 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 r3NIwQSB3266782; Tue, 23 Apr 2013 14:58:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3NIwQYx3263944; Tue, 23 Apr 2013 14:58:26 -0400 (EDT) Date: Tue, 23 Apr 2013 14:58:26 -0400 (EDT) Message-Id: <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Martin Thomson In-reply-to: (martin.thomson@gmail.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 23 Apr 2013 19:06:08 -0000 > From: Martin Thomson > > C3 and C4 look good. > > On 23 April 2013 08:30, Dale R. Worley wrote: > > 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. > > I'm not sure how to parse this. Is that a double-negative or just two > negatives for emphasis? > > Do you intend to say that the solution should NOT rely on new > attributes because SBCs will suppress them, or that the solution is > permitted to use new attributes because SBCs are expected to pass > attributes. I mean the latter. The intended parsing is: (non-DES) C5 SBCs generally pass through attributes that they do not... That is, the possible requirements "Use only known attributes." and "Use only known codecs." are not requirements. > Non-requirements and non-constraints are always difficult to get right. There needs to be a word for this... Dale From worley@shell01.TheWorld.com Tue Apr 23 12:36: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 C9CFF21F93D7 for ; Tue, 23 Apr 2013 12:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 tkruhNxOR6ne for ; Tue, 23 Apr 2013 12:36:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A521F937E for ; Tue, 23 Apr 2013 12:36:04 -0700 (PDT) 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 r3NJZ3YQ002493; Tue, 23 Apr 2013 15:35:06 -0400 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 r3NJZ3nv3249343; Tue, 23 Apr 2013 15:35:03 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3NJZ24T3171577; Tue, 23 Apr 2013 15:35:02 -0400 (EDT) Date: Tue, 23 Apr 2013 15:35:02 -0400 (EDT) Message-Id: <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 23 Apr 2013 19:36:04 -0000 > From: Christer Holmberg > > >Here are a few desiderata related to dealing with legacy devices, both > >endpoints and intermediate devices: > > > > 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. > > I am not sure I understand. Why would one use media types unless > required for user media? The MMT proposal (draft-holmberg-mmusic-sdp-mmt-negotiation-00) and similar proposals add a separate media description (m= line section) which describes the transport for the bundle as a whole. The media type specified by the m= line in such a media description is largely arbitrary. MMT specifies m=anymedia; m=multipart and m=application have been proposed. However, for compatibility with intermediate devices that remove media descriptions other than m=audio and m=video, any "bundle" media description should use either "audio" or "video" type. > > DES C4 Any additional m= lines prescribed by the bundle mechanism > > should be ordered after the constituent m= lines. > > That is normal Offer/Answer procedure, isn't it? If a "bundle" media description is to be added, it ought to be added *after* the m= lines for the constituent media streams, so that the "bundle" media description doesn't change which media description is identified as "the first audio media description", "the second audio media description", "the first video media description", etc. > > 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. > > I don't understand this. See my response to Martin Thompson. I'm considering labeling this item "LATITUDE", meaning a range of flexibility that the solution may exploit, as contrasted to "DESIDERATUM", a constraint that we want the solution to obey. Dale From ari.keranen@ericsson.com Tue Apr 23 15: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 6899321F8D29 for ; Tue, 23 Apr 2013 15:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 E19zrvniOuvC for ; Tue, 23 Apr 2013 15:27:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6469121F8D92 for ; Tue, 23 Apr 2013 15:27:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-80-51770adf091e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.FC.10459.FDA07715; Wed, 24 Apr 2013 00:27:43 +0200 (CEST) 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; Wed, 24 Apr 2013 00:27:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0936A2549; Wed, 24 Apr 2013 01:27:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 75AC654D34; Wed, 24 Apr 2013 01:27:42 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BA01954A3A; Wed, 24 Apr 2013 01:27:41 +0300 (EEST) Message-ID: <51770ADD.6080702@ericsson.com> Date: Wed, 24 Apr 2013 01:27:41 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mmusic-delayed-duplication@tools.ietf.org References: <515F03F3.6070400@ericsson.com> In-Reply-To: <515F03F3.6070400@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre59rvJAgwfXZS32X7zNajF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj765jrAXzmCr2L73P1MD4mLGLkZNDQsBE 4tu1iewQtpjEhXvr2boYuTiEBE4xSsw/9Z8FwtnAKNH5dQIrhLObUWLOhIlMEM46RonVm7ZD OSuAeibfAhvGK6AtsX/ZDGYQm0VAVWL5o1awOJuAvcTNCdfBbFGBZImlO5eyQdQLSpyc+YQF xBYRsJB48P0U2IHMAjISM842MoHYwgLuEnuWvwHq5QBapi3xfo42SJhTQEfi0ZYfTBDlthIX 5lxngbDlJba/ncMM8ZuaxNVzm8BsIaBzrv57xTiBUXQWks2zkLTPQtK+gJF5FSN7bmJmTnq5 4SZGYOAf3PJbdwfjqXMihxilOViUxHnDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBM /i/xM/N35//spykB6t+cQhPK2KvrxAtffJ5y89mWU9mhrAlnFilM7Trtcfdz3qflsfZPXPSX 7Cz4zpL6pL/2gGqzsMzCdeZuE/atm7z2bPy5iANT79Tt6903tShxrxqDeElFT+1kX035Scs1 8ypCTi/tFf029Q7TBL436y+Z3XQ/UZT6z6NUiaU4I9FQi7moOBEA+fSz50oCAAA= Cc: mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 23 Apr 2013 22:27:45 -0000 Hi, I reviewed the draft and noticed that in the intro section you mention a possible DoS attack using the delayed duplication functionality, but it's not discussed at all in the security considerations section. Should that be addressed too? Cheers, Ari (as individual) From ari.keranen@ericsson.com Tue Apr 23 15:27: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 4894221F90A1 for ; Tue, 23 Apr 2013 15:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 txM9uMYpik6k for ; Tue, 23 Apr 2013 15:27:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1659E21F8D29 for ; Tue, 23 Apr 2013 15:27:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-85-51770ae1d365 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.FC.10459.1EA07715; Wed, 24 Apr 2013 00:27:45 +0200 (CEST) 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, 24 Apr 2013 00:27:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 53A5F2549; Wed, 24 Apr 2013 01:27:45 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D731354D34; Wed, 24 Apr 2013 01:27:44 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6C33254A3A; Wed, 24 Apr 2013 01:27:44 +0300 (EEST) Message-ID: <51770AE0.4030800@ericsson.com> Date: Wed, 24 Apr 2013 01:27:44 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mmusic-duplication-grouping@tools.ietf.org References: <515F03EF.1030100@ericsson.com> In-Reply-To: <515F03EF.1030100@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre5DrvJAg4eXDSx2P/jOZDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSujd/o99oJ7zBV9D+exNzC+Zupi5OCQEDCR ODZRoouRE8gUk7hwbz1bFyMXh5DAKUaJ8529rBDOBkaJh00zGEGqhAR2M0q8eJoJkVjHKHHi XzsLRGIFo8SpA9wgNq+AtsTe73vB4iwCqhL/u6aD2WwC9hI3J1xnB7FFBZIllu5cygZRLyhx cuYTsBoRAUuJeW+Pg8WZBWQkZpxtZAKxhQU8JH5fvwK1S1vi3endYHM4BXQkurf9Z4aot5W4 MOc6C4QtL7H97RxmiNfUJK6e28QM0asqcfXfK8YJjKKzkKyehaR9FpL2BYzMqxjZcxMzc9LL DTcxAoP+4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj z+d0zfQ5pi/qL7EnZU1ek/3rs/keG5Mk/0dPFzx65T2B/9YlWR33p9tXxds1Hjw7dXnnfeXN 7wKSvDR+qJcJXFuvd+57hlFJXXnjovj+wxtq78z6c05t4YtYTsWflvuW2Lw7VlQVvP1uvbiO 6Qy7Y+bJ7gxMD28dU1+TvTTX4+PhO6dmSrV3KbEUZyQaajEXFScCAEeRthpIAgAA Cc: mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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, 23 Apr 2013 22:27:47 -0000 Hi, I reviewed the draft and have a few editorial comments: 4.1. Separate Source Addresses join both SSM sessions separately. First use of "SSM"; expand. Alternatively, one could be more explicit and insert an "a=duplication-delay:0" line before the "a=mid:Ch1" line. This is quite vague. Could add an RFC2119 SHOULD/MUST/RECOMMEND here (and same in the next section) and tell when/why (not) to do it. Cheers, Ari (as individual) From ekr@rtfm.com Tue Apr 23 19:17: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 D067E21F93F3 for ; Tue, 23 Apr 2013 19:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMIz-IubI3Un for ; Tue, 23 Apr 2013 19:17:06 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0433621F93F1 for ; Tue, 23 Apr 2013 19:17:05 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 6so907090qeb.36 for ; Tue, 23 Apr 2013 19:17:05 -0700 (PDT) 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=yRRrgaBUckd9N24y5hNMekRxJIb5wgyYF6d+TMb5LK8=; b=SSXPJUkInySEuy/ba8eqqCUYgbk1Y2is32qhlcC9Xg1f2q4uUPygOV8DkFxoCj6ai4 2c8hSJqVSUB8nHCoQC+NSZSH/0NMm9igqFMxxZLAIp5857bmyBwRVdTq5stouSGtbmgO YAxNrSPkUVV0iXl0UTzBkdqaJVIi4FcOJGaOgYWUgHwzgGFDWHYiTVf+31btmsm3538t Oq+ma7Z5gnIMGLonHngNe2FRYQv5LifgNq+I/o6IhXBcZGl2aiqlA3/q7/6c5VfuC7PM GyeWRzOT6JAGB2gP7+Qx3zhrjipFPEgH/MNanFqdCIxAq+09/P1EU/XwfwaIodpV1Vjo HpvA== X-Received: by 10.229.151.134 with SMTP id c6mr4891365qcw.58.1366769825528; Tue, 23 Apr 2013 19:17:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.17.66 with HTTP; Tue, 23 Apr 2013 19:16:25 -0700 (PDT) X-Originating-IP: [220.136.6.74] In-Reply-To: References: From: Eric Rescorla Date: Tue, 23 Apr 2013 19:16:25 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=14dae94ee2adf0f83e04db11e530 X-Gm-Message-State: ALoCoQmGbONgA1JrJhNir07FUcQvAh6jo2eYr1zoSi7+xx77BGbMVjvEAxnm8Wwft7rD7Udx+cP9 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 24 Apr 2013 02:17:06 -0000 --14dae94ee2adf0f83e04db11e530 Content-Type: text/plain; charset=ISO-8859-1 After reading the thread, here are my proposed answers... > Can you create a BUNDLE with a single m= line? (assuming yes) Yes. > Can you create multiple BUNDLEs? (assuming yes) Yes. > When creating an initial offer, how should we deal with the case > where a "null" port is to be used with trickle ICE (since 6.1:1 > indicates the ports MUST be different) I think it's ok for the null port to not be equal. > From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST > use same c=, add rtcp-mux, same a=fingerprint) I don't know if rtcp-mux is necessary, but it seems stupid not to have it. I think we do need to have matching fingerprints because we can only have one DTLS-SRTP association and it's hard to understand what the security properties are if the two associations in principle might have different credentials. > From 6.1, list 2 - is condition 6 right? Why would we use different > SDES keys for a single RTP session? So, I note that this list requires that the other side *support* bundle not that he accept it. So, there's still some chance of getting things unbundled, no? > If you start with a m= line with one SDES config (e.g. 32-bit MAC), > and then BUNDLE with another SDES line with a different (non > overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume > fail) So, this seems like an argument for using distinct SDES lines since then you can just keep the SDES line associated with its associated m-line. > If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the > offer, what happens? (assume fail) That sounds right to me. > If you add a m= line to an existing BUNDLE, can the recipient reject > that BUNDLEing (assume no) I think life would be simpler if this just caused a negotiation fail if the other side was sad about it. > If m= lines are rejected, should their mids show up in the BUNDLE > answer? (assume yes?) That sounds easiest. > Is there any way, in a single PeerConnection, to unBUNDLE m= lines > that were previously BUNDLEd (assume no) I would say no. After all, you can always discard those lines and offer new lines. -Ekr --14dae94ee2adf0f83e04db11e530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After reading the thread, here are my proposed answers...

> Can you create a BUNDLE with a single m=3D line? (assuming yes)=

Yes.


>= Can you create multiple BUNDLEs? (assuming yes)

Yes.


> When = creating an initial offer, how should we deal with the case
> = where a "null" port is to be used with trickle ICE (since 6.1:1
> indicates the ports MUST be different)

I= think it's ok for the null port to not be equal.

<= div>
> From 6.1, list 1 - are conditions 2, 5, 7 really ne= cessary? (MUST
> =A0use same c=3D, add rtcp-mux, same a=3Dfingerprint)
<= br>
I don't know if rtcp-mux is necessary, but it seems stupi= d not to
have it.

I think we do need to = have matching fingerprints because we can
only have one DTLS-SRTP association and it's hard to understand
what the security properties are if the two associations
= in principle might have different credentials.


> From 6.1, list 2 - is condition 6 right? Why would we u= se different
> SDES keys for a single RTP session?
<= br>
So, I note that this list requires that the other side *suppo= rt*
bundle not that he accept it. So, there's still some chance
<= div>of getting things unbundled, no?


> If you start with a m=3D line with one SDES config (e.g. 32-bit MAC)= ,
> and then BUNDLE with another SDES line with a different (non
> overlapping) SDES config (e.g. 80-bit MAC), what happens? (assum= e
> fail)

So, this seems like an argu= ment for using distinct SDES lines
since then you can just keep the SDES line associated with its
associated m-line.


> If the B= UNDLE mids in the answer doesn't match the BUNDLE mids in the
> offer, what happens? (assume fail)

That = sounds right to me.


> If you add= a m=3D line to an existing BUNDLE, can the recipient reject
>= that BUNDLEing (assume no)

I think life would be simpler if this just caused a neg= otiation
fail if the other side was sad about it.

<= /div>

> If m=3D lines are rejected, should their mids= show up in the BUNDLE
> answer? (assume yes?)

That sounds easies= t.


> Is there any way, in a sing= le PeerConnection, to unBUNDLE m=3D lines
> that were previous= ly BUNDLEd (assume no)

I would say no.

After all, you= can always discard those lines and offer new lines.

-Ekr


--14dae94ee2adf0f83e04db11e530-- From christer.holmberg@ericsson.com Tue Apr 23 22:36: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 235F721F9473 for ; Tue, 23 Apr 2013 22:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oHcDO0cOLDc7 for ; Tue, 23 Apr 2013 22:36:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0256121F9433 for ; Tue, 23 Apr 2013 22:36:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-57-51776f54748f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5C.60.10459.45F67715; Wed, 24 Apr 2013 07:36:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 07:36:20 +0200 From: Christer Holmberg To: "Dale R. Worley" , Martin Thomson Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQFSIi+cVnxjNCEKSb6lvFRbbnJjk2nUQ Date: Wed, 24 Apr 2013 05:36:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> In-Reply-To: <201304231858.r3NIwQYx3263944@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+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW5ofnmgwd/LrBbXzvxjtJi6/DGL xcsTZQ7MHpP3f2X22DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgy7s59zV7Qxltx4+kypgbG PVxdjJwcEgImEo3tV1ghbDGJC/fWs4HYQgKHGSUmfzeBsJcwSiw+n9vFyMHBJmAh0f1PG8QU EQiTePMrDsRkFlCXuLo4CKRYGKjgfMtJZhBbRMBS4uby8ywQtpHEr307wBaxCKhKtK79xQhi 8wr4Sky68R+ohgto0R5GibWXj4M1cAo4SHy42MgEYjMCXfb91Bowm1lAXOLWk/lMEBcLSCzZ c54ZwhaVePn4H9QnihJXpy+HqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYh aZmFpGUBI8sqRvbcxMyc9HLDTYzAeDm45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwBjPuFKs5F/s/PeFKs/ll5zUe+bvXzHXJeHlJVm+5UVn6/ftf6Ym JXPwD3O7/5ngrGPbPmjP5U22nn9f8s60f4d9/O/YcUSEXKiYZPToG0+C7N83/4/xZ7OovtYT qPKp4nDd+7QnYutuPoOHoZGuDrfenC08VHjV4byMsEv75wsLHUzfZ7ecU1FiKc5INNRiLipO BADmPAYdZQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 24 Apr 2013 05:36:23 -0000 What do you mean by "known attribute" and a "known codec"?=20 Any defined attribute/codec is "known". Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dale R. Worley Sent: 23. huhtikuuta 2013 21:58 To: Martin Thomson Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements > From: Martin Thomson >=20 > C3 and C4 look good. >=20 > On 23 April 2013 08:30, Dale R. Worley wrote: > > non-DES C5 SBCs generally pass through attributes that they do not > > understand. SBCs generally pass through codec specifications tha= t > > they do not understand, even if they are configured to transcode > > certain specific codecs. >=20 > I'm not sure how to parse this. Is that a double-negative or just two=20 > negatives for emphasis? >=20 > Do you intend to say that the solution should NOT rely on new=20 > attributes because SBCs will suppress them, or that the solution is=20 > permitted to use new attributes because SBCs are expected to pass=20 > attributes. I mean the latter. The intended parsing is: (non-DES) C5 SBCs generally pass through attributes that they do not..= . That is, the possible requirements "Use only known attributes." and "Use on= ly known codecs." are not requirements. > Non-requirements and non-constraints are always difficult to get right. There needs to be a word for this... Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Apr 23 22:40: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 1B7F621F92A5 for ; Tue, 23 Apr 2013 22:40:50 -0700 (PDT) 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=-1.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 W-23FBgnlM8P for ; Tue, 23 Apr 2013 22:40:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DF13A21F91B2 for ; Tue, 23 Apr 2013 22:40:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-4e-5177705f91de Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 73.B0.19728.F5077715; Wed, 24 Apr 2013 07:40:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 24 Apr 2013 07:40:47 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQFmli+cVnxjNCEKSb6lvFRbbnJjk2rcw Date: Wed, 24 Apr 2013 05:40:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35D1BB@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> In-Reply-To: <201304231935.r3NJZ24T3171577@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+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW58QXmgwe6FJhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgytj5awZ7wX6Bih031rA0ME7l7WLk5JAQMJGY fPsNC4QtJnHh3nq2LkYuDiGBw4wSZ27OYIRwljBK7FzWxtrFyMHBJmAh0f1PG8QUEdCU6FiQ A2IyC6hLXF0cBDJGGKjgfMtJZhBbRMBS4uby8ywQtpHE/6YtYDaLgKrEgl0P2UBsXgFfidOr L0Ct3cko0TuvCayZU8BB4ubaJlYQmxHotu+n1jCB2MwC4hK3nsxngrhZQGLJnvPMELaoxMvH /1ghbEWJq9OXQ9XrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FSN7bmJmTnq50SZGYHwc3PJbdQfjnXMihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamCs8OJL0t1r93oZ88V8rs28N8TWl0x74tR3Ieo0Z8BfH8eFUyJFG2JDwl22rN/j Xe9x69YKZdHbIeyiFgy7X0Z4lN1bcSFsc0Dq/qo/xUJ5+0Mmrz5QPV8k44S3etnXL6eyqx2/ 7n3x7FbN4i1CMfsXHZ/t9z86bfqVipty4mF6nO6Xf9v8mqmjxFKckWioxVxUnAgAGF6R9V0C AAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 24 Apr 2013 05:40:50 -0000 Hi, =20 >>>> Here are a few desiderata related to dealing with legacy devices,=20 >>>> both endpoints and intermediate devices: >>> >>> DES C3 Avoid using media types in m=3D 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. >>=20 >> I am not sure I understand. Why would one use media types unless=20 >> required for user media? >> > The MMT proposal (draft-holmberg-mmusic-sdp-mmt-negotiation-00) and simil= ar proposals add a separate media description (m=3D line section) which=20 > describes the transport for the bundle as a whole. The media type specif= ied by the m=3D line in such a media description is largely arbitrary. MMT= =20 > specifies m=3Danymedia; m=3Dmultipart and m=3Dapplication have been propo= sed. > > However, for compatibility with intermediate devices that remove media de= scriptions other than m=3Daudio and m=3Dvideo, any "bundle"=20 > media description should use either "audio" or "video" type. Ok, now I get it :) So, as we will not move forward with draft-bundle, I guess DES C3 is fulfil= led, right? >>> DES C4 Any additional m=3D lines prescribed by the bundle mechanism >>> should be ordered after the constituent m=3D lines. >>=20 >> That is normal Offer/Answer procedure, isn't it? > > If a "bundle" media description is to be added, it ought to be added > *after* the m=3D lines for the constituent media streams, so that the "bu= ndle" media=20 > description doesn't change which media description is identified as "the = first audio=20 > media description", "the second audio media description", "the first vide= o media description", etc. And, with "bundle" media description you refer to something like MMT, right= ? Ie m=3Danymedia, or something similar? So, again, based on the decision to move forward with draft-bundle, I guess= DES C4 does not apply, as we will not have a "bundle" media description to= begin with? Regards, Christer From abegen@cisco.com Tue Apr 23 23:32: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 D78EA21F8FAB for ; Tue, 23 Apr 2013 23:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 8XHQ7I+K8xVM for ; Tue, 23 Apr 2013 23:32:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB0121F8FA4 for ; Tue, 23 Apr 2013 23:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=594; q=dns/txt; s=iport; t=1366785159; x=1367994759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Syn86zRBEptiexPQnNe2AdgD/TcYOB5cmCk7Ty31wJs=; b=YAog8qTAe9PlfBo2RIJMMbILxqLJlJHmzzafnfSjqw32OTR8DCbejOGF 2uR2ipBsu1VGfC7DEBTHJ1cCeWmmu1+JSjoW4x0Rp8WVVH2rhY53rPzEu O6vVZ89vuzwfb39lyTULaWJ7JcVb/Dow0YHfQSwPGa1bSNg9JcQKYHPSf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFACd8d1GtJV2b/2dsb2JhbABQgmUhgyG7ZYELFnSCHwEBAQMBeQULAgEIIiQyJQIEDgUIiAYGAb1XjnUCMQeCaGEDiFefYIMOgig X-IronPort-AV: E=Sophos;i="4.87,540,1363132800"; d="scan'208";a="202299205" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 24 Apr 2013 06:32:27 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3O6WRJp001694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Apr 2013 06:32:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 01:32:27 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01 Thread-Index: AQHOMh+OrJd+p16ntUKckcdJFFsN55jk0xuAgACHcAA= Date: Wed, 24 Apr 2013 06:32:26 +0000 Message-ID: References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> In-Reply-To: <51770ADD.6080702@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.158] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8C533F6D51205541BA737247C879E6F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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: Wed, 24 Apr 2013 06:32:40 -0000 On Apr 24, 2013, at 7:27 AM, Ari Ker=E4nen wrote= : > Hi, >=20 > I reviewed the draft and noticed that in the intro section you mention a = possible DoS attack using the delayed duplication functionality, but it's n= ot discussed at all in the security considerations section. Should that be = addressed too? >=20 Really? the whole section talks about what could happen if someone could mo= dify the SDP (number of dup streams, delays, etc.). Especially the last par= agraph mentions this. is it not clear? >=20 > Cheers, > Ari (as individual) From abegen@cisco.com Tue Apr 23 23: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 5D4D221F8BE4 for ; Tue, 23 Apr 2013 23:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 m028I3734Q1m for ; Tue, 23 Apr 2013 23:36:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8492E21F8BC0 for ; Tue, 23 Apr 2013 23:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=998; q=dns/txt; s=iport; t=1366785393; x=1367994993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yePDm787WX911vsd3b0Zh9n1bLFjPyXxqqmXy6YEPdw=; b=I2n3CP1SSdWPoh/DyBb/Fs71Gqw2EahCEeJIqKfPamkbZU9sRuItV8Tz Z8ubb9xFolIVXrWXXs6Y1/+grbnVWD+0Z1GE3gVRboHBiBryzy8ikTmHI TtaOcZpBqRBKAR47Y7r8KerIBiv+ZZBa1z9R9HlVbqPAC0V3jVlduOwZy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFACd8d1GtJXG//2dsb2JhbABQgmUhgyG7ZYELFnSCHwEBAQMBeQULAgEIIiQyJQIEDgUIiAYGAb1XjnUCMQeCaGEDiFefYIMOgig X-IronPort-AV: E=Sophos;i="4.87,540,1363132800"; d="scan'208";a="202300351" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 24 Apr 2013 06:36:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3O6aWBL003888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Apr 2013 06:36:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 24 Apr 2013 01:36:32 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-01 Thread-Index: AQHOMh+Mau+5XnZYeUyBunjPZbI7K5jk0x4AgACIkYA= Date: Wed, 24 Apr 2013 06:36:32 +0000 Message-ID: References: <515F03EF.1030100@ericsson.com> <51770AE0.4030800@ericsson.com> In-Reply-To: <51770AE0.4030800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.158] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2FA258DB51DB1B4CAFD972118550E74A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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: Wed, 24 Apr 2013 06:36:34 -0000 On Apr 24, 2013, at 7:27 AM, Ari Ker=E4nen wrote= : > Hi, >=20 > I reviewed the draft and have a few editorial comments: >=20 > 4.1. Separate Source Addresses >=20 > join both SSM sessions separately. >=20 > First use of "SSM"; expand. sure. >=20 >=20 > Alternatively, one could be more explicit > and insert an "a=3Dduplication-delay:0" line before the "a=3Dmid:Ch1" > line. >=20 > This is quite vague. Could add an RFC2119 SHOULD/MUST/RECOMMEND here (and= same in the next section) and tell when/why (not) to do it. >=20 I think a MUST would be too strong since it is not really a must. I also th= ink making it a SHOULD would require us to explain when it could be ignored= (which is really any time since nothing will break if it is ignored). Putt= ing it would be more like informational purposes. I think "MAY" would be ap= propriate here. Would that address your concern? >=20 > Cheers, > Ari (as individual) From magnus.westerlund@ericsson.com Wed Apr 24 00: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 E142B21F8FE3 for ; Wed, 24 Apr 2013 00:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.138 X-Spam-Level: X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 seZgTNVYYXZg for ; Wed, 24 Apr 2013 00:52:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 315C821F8FE5 for ; Wed, 24 Apr 2013 00:52:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-fa-51778f578cae Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1B.F4.03253.75F87715; Wed, 24 Apr 2013 09:52:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Apr 2013 09:52:55 +0200 Message-ID: <51778F56.60306@ericsson.com> Date: Wed, 24 Apr 2013 09:52:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <51778EE1.8080505@ericsson.com> In-Reply-To: <51778EE1.8080505@ericsson.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <51778EE1.8080505@ericsson.com> Content-Type: multipart/mixed; boundary="------------020404070301090303080506" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0iTURjGOfu+bd/E4XGpvRkkOsV7mRYKhdQfgUXiDS9YoKOGzk2RqRlI sS5eUjQRFf1S8TIxpRRtUjOpNslRappmMiIlNbt4WWKGJlr79s0Q+u/3nvM873t4n0MRommu MyXLyJYqMyQKN54NWZuwfc0//m5uVMBog0NIVdsceQqFqdWbnEiUaHPyslQhuyJVHglNtkl9 Qd/iZO4kXq0p1fJUqD6iGAkowMeg2VSCWHaCsekuXjGyoUT4NYLJd/cJtmhDUGHY5BcjihJi bzCsRDMGEnvAZLWJyzAPh4Bx4waPkTjiGOjNv8gcC7E9vKqdJxl2wJ6Q/6jMIt+HL8CvZ3N8 hkXYF8bWTRYWYD/QzWpJ9j0HQPO1kM9yMDwdWicYJnAkjDZWkbte1c0ibjmyp/eMo/fIWD4M lZO3Ecsu8Hi5jmA5AXZ+1HH/P0+Ce7OdHNoyOhmMfUZzH2YTfQiGPy3y2KIbAT3RTPy72fg5 b5VVIigY0fKZgsRlJJR/eYPYZu5QotLwaMv6xPCn9be1VyeCdZOGz4q8oKZ9zGygzGwHD/Vi 2ppPwXq3tY8QhioNFi9gNQLTVInFK8LjCBpaRGxTHYK1GS1JW5Mu6CrishfD5kBfViN6N13V xwEOu0BfeD41S9LWeBc3Ziy8Gy/DjjgW+k0LFnbA/rCytYDY0XoCWiftGlFIB+KnS2SKlNzg HmT+ozrNVsAT1DPjpEcHKdJtvzD+zFikCKdIsqVyqTRTqkxS5iikWXrEoQTOKuR5WsMxxiVk NE/IubFzsqxCw3d3L92dqHPtpTtLl9L83jY5VsgN6cfFjstrkhrXwC7bVcFQ4GpekD7HI268 f1BY/CFE3J/qEoY/b8sH6z2j88ShPgPh364rGtICO2TilumIuAmj5L2r+sGJINul7V4/RfiI POasd11RU8zi+UNuZFaq5KgPocyS/AWnSZWocQMAAA== Subject: [MMUSIC] Comment on Payload type restriction in 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, 24 Apr 2013 07:52:58 -0000 --------------020404070301090303080506 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, In RTCWEB WG we had a discussion regarding a limitation in BUNDLE. I think this shall be changed for the reasons that is evident in the forwarded email. Magnus Westerlund --------------020404070301090303080506 Content-Type: message/rfc822; name="Re: [rtcweb] #15: Section 4_8: SSRC signaling.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: [rtcweb] #15: Section 4_8: SSRC signaling.eml" X-Mozilla-Keys: Received: from esessmw0247.eemea.ericsson.se (153.88.115.93) by ESESSHC022.ericsson.se (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 24 Apr 2013 09:51:09 +0200 Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Apr 2013 09:51:04 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id A2.D8.26606.7EE87715; Wed, 24 Apr 2013 09:51:04 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3720E21F8D90; Wed, 24 Apr 2013 00:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366789862; bh=Mys66ZtLZyn4MyKWY4hdOYg9WQg9KM+Y5qAuPtjSsiQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=MzWHWFtGPRtXqXhKrLxDpEsauS1w5E25vn3i+5GA75GegcU5yIpWTNYyQztWbUGca F84J6YZly3nhd05XLqA+eKrcQ+W2A3aRPA5nMkqlGMVJeglIsFDZVUDFBvVArlTLy7 E0Gb+h0NAlSZ22YH5n9Pwm+K4UwwwEzvB2aQ0B1M= X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E2221F8D79 for ; Wed, 24 Apr 2013 00:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.132 X-Spam-Level: X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=0.117, 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 u2r6qgkbi3-4 for ; Wed, 24 Apr 2013 00:50:59 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4F21F8D2E for ; Wed, 24 Apr 2013 00:50:58 -0700 (PDT) X-AuditID: c1b4fb3e-b7f956d0000067ee-3c-51778ee74ed5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 06.94.03253.2EE87715; Wed, 24 Apr 2013 09:50:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Apr 2013 09:50:57 +0200 Message-ID: <51778EE1.8080505@ericsson.com> Date: Wed, 24 Apr 2013 09:50:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 To: "Mo Zanaty (mzanaty)" References: <066.4c5db43349d3176acaa90d17617a02d6@trac.tools.ietf.org> <5173ECC7.7020909@jitsi.org> <51754363.3090300@ericsson.com> <201304222215.r3MMFqsE3199256@shell01.TheWorld.com> <201304231858.r3NIw4OJ3260483@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DB734@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6DB734@xmb-rcd-x14.cisco.com> X-Enigmail-Version: 1.5.1 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTfUwTdxjmvTvurl2rxynygmjMqXMZghIX98vi1CwxWZa4DKN/6LaMMm+0 GRTWK4NpTCohuJTpVECHcZMxa/0IIyCSRl2KBTXCRKhgNdEal06ZIBojteL8uOsV3f57njwf 75PL/Xha3MVl8HKFU3bYLUUSa2RMM96bnT28ozxvcbgDiPvwTBIc76fJoZOfkcob7Rzpb+gC 0natlNwLelTgPUKRS93XgYyFznKk78APQKJVTygy2OjjSO3lnxmytVIhh733gLT21gMJtoQp 8uMLhVwJPaTIKU+QJjeeddDE3xllSfjJOEu6e8bolekfTowPsZ/ABuOyjXKR7VvZsWh5vtEa 6w1TpXekigc1j5JdUJfpBgOPwjtY3fJ9so5nYH+4hXWDkRcFH2DotxPJOtkD2DxWzWmEEXYw uPNOH+iReVjjamc1zAhz8YVnIhH/HbDu2INE71v405F+NcCreCo2B+ZOnqseb030TMGB4Ril ZVE4CHg/VMPpRYNqUe8orZMzKglOcJPLj3v2J4Q/AXef3QM68QJGW/+JjzILWegP/cXoA+fj SOxmHLMCwWuxrXFPqrAOT9+/nfCn4IWGSNwzXcjGsae34wNFIUCjZ2iqhg3CaqzyX2f0FenY PrwtsejvZBzdxWuYFhagp9YV75wmLMULbU0JfyYOHNU/mJZ1b49wOyFr339O74vHc/BqfR2r 4yw89OsI3Qj0UUhVZEUpLsxdnCM7bF8qSok9xy4720D99860P13ugyu3cgOQzlNSqrm8pjxP nFJQsvE7q0WxfuEoK5KVAMzkGSnN3OUtyBOFQotT/lqWS2XHpJrJ8xKa87eryRSHXChXfGUr cr6WKd4QAORN0nTzCc1jVkotxYqtUNd7IJuvHoiMgMjYS+xyRpr5A80kaCZrmf1Vz+RLCcKs jGlmSEpKEk3qhmKb8//6XUjjQVId6oMSTTa789Wlu+oISh1hy3dqI5yW11KGC4b2RhordpeN bhq1WXJ9H2++6lnVWcI1pZxfHej7qPPRqYXDn6ZtbmJ8z+d3zIqZGiu/aWpeH1lg6PHXnysQ YIn3j4t7o6e73L8sOtk6aJyzbKV95Nmm96WGc+dXPH53y5tr1s6u6nZd8nvZxy3P/z0+p1k8 ACvc62tXfX75jbaHSwzRtRKjWC25b9MOxfISSDpe8CQEAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre6jvvJAg1XvRS1ePJjDZLH2Xzu7 xcsTZQ7MHpP3f2X2mPJ7I6vHkiU/mQKYo7hsUlJzMstSi/TtErgyzk+dyVqwQLGi4+UjlgbG 71JdjJwcEgImEpuXzmGGsMUkLtxbz9bFyMUhJHCKUWLn50lQznJGiRfLNrCCVPEKaEvsv/6I BcRmEVCVeP3jPpjNJmAhcfNHI1ADB4eoQLDE1tYYiHJBiZMzn4CViAjoSrz7/YwRpIRZIFBi yXcTkLCwgJnEyU2LWCBWbWOWOHlgNjtIglPAV6Jl/x0WiOMkJba8aAeLMwvoSUy52sIIYctL NG+dDfaAENBpDU0drBMYhWYhWT0LScssJC0LGJlXMbLnJmbmpJebb2IEBu/BLb8NdjBuui92 iFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZuu8Kcazcm3g3Z6RCkGqp1 QOqZ6xQTlS0xZ072v3J1tNmjViR597nLpnwZJY6T2ldaogrvTL3+kH3punXvOfbv2r41aJXj siSmmxNbBdfLON4Razi/JM96Rpe/pEXLoaQnHYI5M2UfBly4uM839OSJ5QKmMVeitl/yulrN x27Sf9wkfkG560klluKMREMt5qLiRAAJzaIWLAIAAA== CC: "rtcweb@ietf.org" Subject: Re: [rtcweb] #15: Section 4.8: SSRC signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: Errors-To: rtcweb-bounces@ietf.org Return-Path: rtcweb-bounces@ietf.org X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Thanks, I fully support this argument, why you can't start using the PT as an identifier to which purpose or specific negotiated set of constraints within a common RTP session this SSRC relates to. I would however note that this discussion would be better to hold on the MMUSIC list, especially as it does apply to a statement in BUNDLE which I believe must be changed: Se Section 7.2 of draft-ietf-mmusic-sdp-bundle-negotiation-03 o - The dynamic payload type values used in the "m=3D" lines MUST NOT overlap. This restriction I think must be changed. I will now forward this email to MMUSIC as comment on BUNDLE. Cheers Magnus On 2013-04-23 23:03, Mo Zanaty (mzanaty) wrote: > You can easily exhaust the dynamic payload type number space (96-127) > with only a few media lines, not 30. Keep in mind the primary purpose > of payload type is to negotiate codecs, not demux different streams. > An offer from a highly interoperable product will contain many > payload types for each stream. It is not uncommon to support 8+ > payload types and 4+ streams, which quickly exhausts the dynamic > space. Also keep in mind that many codecs have different > configurations that are expressed as different payload types, so even > supporting a single audio and video codec can yield many payload > types if those codecs are highly configurable. >=20 > Consider a very simple product (smartphone) in a very simple use case > (3-way video chat). It supports several audio codecs (OPUS, AAC-LD, > AMR-WB, AMR-NB, G.711) and several video codecs (VP8, VP9, H.264, > H.265). It supports several H.264 profiles (BP, HP, SBP, SHP) and > packetization modes (0, 1). This already exhausts all 32 dynamic > payload types, before we even consider things like FEC, scalable or > simulcast layers sent via MST, screen sharing, multiple cameras, > etc. >=20 > So I would strongly discourage folks from assuming payload type demux > is viable in most use cases. It may be viable when there is a single > audio and video stream, each using a single codec and configuration. > But it quickly becomes impractical or impossible when the product > gets more capable or the use case gets more interesting. >=20 > Mo >=20 >=20 > -----Original Message----- From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: > Tuesday, April 23, 2013 2:58 PM To: rtcweb@ietf.org Subject: Re: > [rtcweb] #15: Section 4.8: SSRC signaling >=20 >> From: Martin Thomson >>=20 >> On 22 April 2013 15:15, Dale R. Worley wrote: >>> My understanding is that associating an incoming RTP packet with >>> an m=3D line is a solved problem -- the transport association on >>> which the packet arrives determines the bundle, and (within all >>> of the currently active bundling proposals) the payload type >>> tells which m=3D line within the bundle. >>=20 >> Not so. If you have five PTs on each m=3D line, and 30 m=3D lines, >> you just don't have that many PTs available. At some point you >> have to recognize that SSRC is what you have to use. (Neither >> number is extraordinary.) >=20 > But why would you use 30 m=3D lines? You'd only have 30 streams in a=20 > videoconference-type situation, where the streams don't have > distinct roles and so don't need to be given role labels. As far as > I know, current videoconference systems don't put each video stream > in a separate m=3D line. >=20 > Dale _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=20 > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 --=20 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 ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------020404070301090303080506-- From pkyzivat@alum.mit.edu Wed Apr 24 06:44: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 1DCB521F89B2 for ; Wed, 24 Apr 2013 06:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.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 rVzxGRZ-jXHZ for ; Wed, 24 Apr 2013 06:44:29 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 30FBC21F8976 for ; Wed, 24 Apr 2013 06:44:28 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id Tpi71l0081ei1Bg5CpkTKM; Wed, 24 Apr 2013 13:44:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id TpkT1l00Q3ZTu2S3kpkThn; Wed, 24 Apr 2013 13:44:27 +0000 Message-ID: <5177E1BB.3010708@alum.mit.edu> Date: Wed, 24 Apr 2013 09:44:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366811068; bh=/bVF59iiXBDE0AHd9+wGIrRLj4zvt5oJm7cGQRuvH5o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rnbGmuGs+rGzL1BL9u8oRK+icQ8RfFpg3wMIftVR/ckCfG/404A5WThnf83eNQFv2 J1Duf7FTQY/Gb7xVGxVTVuHagMwJ2ObPDLXVLmVU1abD3OosQPxw0WYog/Lexh+C7W i8z1dcwrOB5ycbbcf7gUIJ2NnUJFNF7huIkzf52xq6ePQUFKa2S2TdB0dBPRpKULXE bVjeRjOjSUN2wXncJLQ7F5BuVAYBwnItnEz2qLBcQr6fsgaYnASlqhBZftR936djcm pNb7umZCwgsGKoNWQ7xD1/SEMW8KV+olYZT1ZfLXpz9FzpfHJ86YFjLM4wz5HphOla jYNivyZtB4fqg== Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 24 Apr 2013 13:44:30 -0000 On 4/22/13 11:25 AM, Cullen Jennings (fluffy) wrote: [snip] >>> Also imagine case where >>> >>> Alice offers A, B, and C and offers to bundle them all >>> >>> Bob wants to accept A and B in a bundle and C separate >>> >>> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling). >> >> This is actually the same sort of problem as the above. The question >> is whether the bundle is negotiated as a whole, or whether answers can >> differentiate on per-line basis. I can appreciate the desire to >> simplify, but you have to examine use cases. >> >> Example: Alice offers A and B bundled, Bob accepts the bundling. >> Later, Alice adds C to the bundle. How can Bob get that m= line >> routed over a different path? Do we require that Bob reject the line >> and offer the same line, potentially inverted, without bundling in a >> subsequent offer? >> >> I'm thinking here about a case where a session escalates from audio to >> audio+video and there might be a middlebox involved. I guess in that >> case the middlebox needs to drive the addition. >> >> I can probably live with the simplification, but this needs to be >> crystal clear. A more complete discussion of the implications of this >> particular choice would be really helpful. > > +1 on we need to be crystal clear. > > I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it. This is a subcase of "splitting" a bundle, which I posted on earlier: http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html IMO it *must* be permissible to accomplish this in some way. For the case of splitting one bundle into two bundles, I concluded that it will take another O/A. Just leaving some of the proposed bundle candidates out of single bundle seems to be acceptable to 5888. I see no reason to circumvent that for bundle groups. The second o/a I proposed for splitting a bundle would not be allowed by what the two of you are proposing. There are real use cases for this, where the offerer processes all the streams at a single network access point, but the other endpoint processes them at multiple access points. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 24 07:35: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 4E14321F8D31 for ; Wed, 24 Apr 2013 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 MsFPCs+p4a6H for ; Wed, 24 Apr 2013 07:35:39 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5921F866E for ; Wed, 24 Apr 2013 07:35:39 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id TnfR1l0060ldTLk5DqbedP; Wed, 24 Apr 2013 14:35:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Tqbd1l01P3ZTu2S3Qqbe0Z; Wed, 24 Apr 2013 14:35:38 +0000 Message-ID: <5177EDB9.9030103@alum.mit.edu> Date: Wed, 24 Apr 2013 10:35:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org 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=1366814138; bh=YLUUTkiO1zE8+cgn6kRVQe4U9spN1ZhstU1wu7ni/EM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EbRzgJ5geDBlOsIbKCaIHOQiL0T94heJbly9YPklfMWKkLo0gdx/oFuTSd5sOfNRQ OwFA5HOxAk1zwpOHA75v2ryoa3l2PcEPb26yLjyVpccMD2kKuutk/wkJVzhj7Etf0e nDnRkHeohadWAUDFpZzFVa3BmsjPa/MqN7Dd7ACXKzMgZbjL/9GSmiUJ0QaICAyvzi hta0dCSWd7ec2Il47PcsO9LSv0hXxsBVbzNOeDGdb8uctkL6RWEsSrVFBfwCGIjJ2f pXsO5Nr+nUCtxOMINNZ23NgN7AqMGmH+rMXPoNYwXnzAQZiiTR4wJxzMIhh3kgkj3J C6pP0ZrgP0pNQ== Subject: Re: [MMUSIC] 10 BUNDLE questions 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, 24 Apr 2013 14:35:40 -0000 inline, trimming On 4/23/13 10:16 PM, Eric Rescorla wrote: > After reading the thread, here are my proposed answers... > > When creating an initial offer, how should we deal with the case > > where a "null" port is to be used with trickle ICE (since 6.1:1 > > indicates the ports MUST be different) > > I think it's ok for the null port to not be equal. What is a "null" port? In any case, ISTM this reply isn't responsive to the question. IIUC, the question was: - the current spec says that the initial bundle offer must have *different* addr/port for each m-line; - but if, in conjunction with trickle ice, you want to make the initial offer have *null* port, then multiple m-lines will have the *same* null port. This seems to require that the bundle spec acknowledge and permit this case. > > If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the > > offer, what happens? (assume fail) > > That sounds right to me. Exactly what does "fail" mean here? It is the receiver of the answer that detects this issue. Presumably the answerer didn't consider it an error, and so won't know the offerer thinks it is. So does "fail" mean that the offerer should tear down the PeerConnection? Or what? > > If you add a m= line to an existing BUNDLE, can the recipient reject > > that BUNDLEing (assume no) > > I think life would be simpler if this just caused a negotiation > fail if the other side was sad about it. If the change was to add a new m-line, that previously was not present, to the SDP *and* to the bundle, then answerer could potentially either: 1) accept the m-line (non-zero port) and accept the bundling (matching mid-line to what was in the offer) 2) accept the m-line and reject the bundling (mid value for the rejected m-line omitted from the bundle group) 3) reject the m-line (zero port) and reject the bundling. For better or worse, RFC5888 requires this behavior in the group line for rejected m-lines. I guess you are suggesting that (2) be unacceptable. Again, what do you expect to happen in that case? > > If m= lines are rejected, should their mids show up in the BUNDLE > > answer? (assume yes?) > > That sounds easiest. I think RFC5888 requires this. (But it may be arguable.) But it also requires that the group in the answer not reference the mid tag of the rejected m-line. > > Is there any way, in a single PeerConnection, to unBUNDLE m= lines > > that were previously BUNDLEd (assume no) > > I would say no. > > After all, you can always discard those lines and offer new lines. ISTM there are more details to be worked out: * When is an m-line considered to have been "previously bundled"? - Is it when it was first offered with a mid tag referenced by a bundle group line? - Or is it the first time the mid tag appears in a bundle group in an answer? ISTM it should be the latter, not the former. That means m-lines that were offered but rejected in the answer are not bundled, and so can be reused in a subsequent offer to propose a separate bundle. * When "offering new lines", must those lines really be *new*, or can they include the recycling of m-lines that were previously rejected? Precedent says that these are functionally equivalent. * Is there any requirement for preservation of mid tags from one O/A cycle to the next? IOW, is the *value* of the mid tag for each m-line part of the persistent state of the session? - I think there is a requirement that the *bundling* be preserved; - But the mid tags are merely a means to an end for describing the grouping. It is not important that the specific tags be preserved. - There could be a difference between what is required here for 3264 usage and what is required for JSEP, since the usage for JSEP is not a wire protocol. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 24 08:01: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 98BE221F92C0 for ; Wed, 24 Apr 2013 08:01:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEPm3J7WWS1l for ; Wed, 24 Apr 2013 08:01:12 -0700 (PDT) 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 E955D21F8E7E for ; Wed, 24 Apr 2013 08:01:11 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id Tn3P1l0060cZkys51r1BSd; Wed, 24 Apr 2013 15:01:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Tr1A1l00U3ZTu2S3Wr1Bvc; Wed, 24 Apr 2013 15:01:11 +0000 Message-ID: <5177F3B6.1090709@alum.mit.edu> Date: Wed, 24 Apr 2013 11:01:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <51778EE1.8080505@ericsson.com> <51778F56.60306@ericsson.com> In-Reply-To: <51778F56.60306@ericsson.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=1366815671; bh=SN3JVGNQIuUjSM2QSLiyqpIhVYCcGBT7XY4RXoKFEmU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=biB00gx2Yc71EHgEqPy/lUZlmCIIOuNSkV7Zld3tIDEV3HMOIBLAp6w6YIoV64OcA hqvYEIctX8BaSdgQwz+c3t/GywfhfV7P0xZT0hjMtaZYY1+063bhXgtCjQztNZjokq eCnFgjBTxl9JM7udjneo3SY+oiciLXF6ONzqslsb0x8UpTM9Fsd8mo7/AJpaIkaW5o zWwJWKD0G91JnAFTizsQ5f5TS6FuhlXT5xkYT5bqv6O4x+bIpo/N5yCvo2cnbECqjF 7UYNHsZDTvjW+rYZHKhS4Q0QjiVzr9ZukasiPqxtYMkWzh1brXsQKeyxFUocvR0pX4 7PEGlaQhRjqtQ== Subject: Re: [MMUSIC] Comment on Payload type restriction in 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, 24 Apr 2013 15:01:12 -0000 I agree that this restriction needs to be reconsidered. But this is just part of the more general issue of how the contents of a bundle are demultiplexed. There have been a number of demux mechanisms proposed: - Payload type *has* been proposed as one mechanism. In those cases where it is to be used to map an RTP packet to a particular m-line then indeed the payload type restriction needs to apply. - SSRC has been proposed as another mechanism. When SSRCs are declared in SDP per m-line, then those can be used map RTP packets to m-lines. In this case the payload type restriction isn't needed. But we then need a restriction that an SSRC can only appear in one m-line of the bundle. - A special new RTP header extension has been proposed as another mechanism. To be used to map packets to m-lines it will need to be declared somewhere - probably as a new media-level sdp attribute. If this is used for the demux then we don't need the PT restriction, but we will need a restriction that this new value can only be declared in one m-line per-bundle. - the draft doesn't currently talk at all about including the m-line for the SCTP association for data channels in the bundle, but people expect it. There is a special mechanism for demuxing those packets from RTP. But that mechanism is limited to SCTP over DTLS. And it is limited to a single SCTP association in the bundle. ISTM that there must be specification of: - the demux mechanisms that are available, - how they work, - how they do or don't coexist with one another, - and how they are signaled in SDP. The list of available demux mechanisms may need to be extensible. And the bundle mechanism should be designed to accommodate that. Thanks, Paul On 4/24/13 3:52 AM, Magnus Westerlund wrote: > WG, > > In RTCWEB WG we had a discussion regarding a limitation in BUNDLE. I > think this shall be changed for the reasons that is evident in the > forwarded email. > > Magnus Westerlund > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ari.keranen@ericsson.com Wed Apr 24 10:25: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 9B0C621F8F12 for ; Wed, 24 Apr 2013 10:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 OAl4CrcFOFI0 for ; Wed, 24 Apr 2013 10:25:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A420721F8F08 for ; Wed, 24 Apr 2013 10:25:53 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-43-517815a03664 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3E.B9.19728.0A518715; Wed, 24 Apr 2013 19:25:52 +0200 (CEST) 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, 24 Apr 2013 19:25:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 06A942419; Wed, 24 Apr 2013 20:25:52 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 839B254D41; Wed, 24 Apr 2013 20:25:51 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A7AA54ADA; Wed, 24 Apr 2013 20:25:50 +0300 (EEST) Message-ID: <5178159E.9070405@ericsson.com> Date: Wed, 24 Apr 2013 20:25:50 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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+Jvre4C0YpAg+vLFCxuHDjHbDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSuj88UnloLtzBVnF7czNTDeZ+pi5OSQEDCR WHl7BSOELSZx4d56ti5GLg4hgVOMEstutzBBOBsYJb5N2c4M4exmlFj1YRKUs45RYu+ks1DO CkaJnhc7wQbzCmhLvO1/AWazCKhK/NvWyQpiswnYS9yccJ29i5GDQ1QgWeL/Dm+IckGJkzOf sIDYIgIyEns3bWYGsZkFdCWubFkGZgsL6Eu0L/7NChG3lbgw5zoLhC0vsf3tHGaIH9Qkrp7b BGYLAa29+u8V4wRG4VlIVsxC0j4LSfsCRuZVjOy5iZk56eVGmxiBgXxwy2/VHYx3zokcYpTm YFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTGg7PubRaHyezWmbnr2QL5pUcxJ nizz9CmKjRZvJ6k9mKF0S+Jr5LFDd857sjOGR3DND5gan2nS+6sg6Fdzv+/1nzMNe9uCJMX5 ln6ymLy2c8kHpZhA07b1p/8wRM3a8Unz2NbA7O+OnaxOi3m/Lln3/2659b4n1Z1Fs7eEFtfO /8/FoZWZtkWJpTgj0VCLuag4EQBjxE7ZMgIAAA== Cc: draft-ietf-mmusic-latching@tools.ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-latching-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: Wed, 24 Apr 2013 17:25:55 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-latching-00 The WGLC ends on May 8th, 2013. Please review the document send your comments both to the authors and to the MMUSIC mailing list. If you review the document but do not have any comments, please send a note to that effect as well. The document is available here: http://tools.ietf.org/html/draft-ietf-mmusic-latching-00 Thanks, Ari From ari.keranen@ericsson.com Wed Apr 24 10:30: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 2EE0B21F8DFC for ; Wed, 24 Apr 2013 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 gRH7t4-WJ3vG for ; Wed, 24 Apr 2013 10:30:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1EFB21F8C38 for ; Wed, 24 Apr 2013 10:30:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-d8-517816b872e1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 59.69.03253.8B618715; Wed, 24 Apr 2013 19:30:32 +0200 (CEST) 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, 24 Apr 2013 19:30:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6CDA42419; Wed, 24 Apr 2013 20:30:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D1C7254D41; Wed, 24 Apr 2013 20:30:31 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8200F54ADA; Wed, 24 Apr 2013 20:30:31 +0300 (EEST) Message-ID: <517816B7.2070307@ericsson.com> Date: Wed, 24 Apr 2013 20:30:31 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mmusic-latching@tools.ietf.org References: <5178159E.9070405@ericsson.com> In-Reply-To: <5178159E.9070405@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre4OsYpAg11NthY3Dpxjtpi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJUx42oHS8Eq0YoDG8waGI8KdDFyckgImEh0 v5rEDmGLSVy4t56ti5GLQ0jgFKPE8Zkv2CGcDYwSPU2XoZzdjBIrdu1lgXDWMUqcfHSAGcJZ wSjx+VUHG8gwXgFtiW3rzjGD2CwCqhJvJ61jBLHZBOwlbk64DjSKg0NUIFni/w5viHJBiZMz n7CA2CICuhK7fyxiBbGZBWQkZpxtZAKxhQUMJFre7QOrEQIa3zfpD1gNp4COxMz5t9kh6m0l Lsy5zgJhy0tsfzuHGeI3NYmr5zYxQ/SqSlz994pxAqPoLCSrZyFpn4WkfQEj8ypG9tzEzJz0 cvNNjMCwP7jlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA WHLAsPGnSIT0SnNh0fxXr2O9Nn5+ca5cbsp9zroF+0Kf1mitvXn85czv2bYRfxiWa+6dZTFF f9Jpr10b1k17t6+1L/+BVI5g1ee11zheey9SVXpxhlfqh4FOgN+SDxufljEJ5898vN9nqcjs okX1spvF1vrXvU29+/GjPm/RQgVmT5fkLOPDwUosxRmJhlrMRcWJAKcqtkBJAgAA Cc: mmusic Subject: [MMUSIC] Review of draft-ietf-mmusic-latching-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: Wed, 24 Apr 2013 17:30:35 -0000 Hi, I reviewed the draft-ietf-mmusic-latching-00 and have a few (mainly editorial) comments. Abstract: expand RTC. 1. Introduction address and transport port number. This includes consumer NAPTs, Expand NAPT; (or alternatively, even if NAPT is more "technically correct" term, maybe just "consumer NAT" is more clear..) encoded in bodies such as SDP [RFC4566]> as well as, in the case of Extra ">" here. Also expand SDP, STUN, TURN, ICE, XMPP, MGCP (but SIP & RTP are OK without; http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). [...] MGCP, H.248/MEGACO, and H.323. Informative references for these? 2. Terminology You're not using RFC 2119 terminology; this section can be removed. 3. Background equivalents) by NATed User Agents (UAs) are not usable across the Internet, because they represent the private addressing information of the UA rather than the addresses/ports that will The term "private addressing information" sounds a bit strange. Maybe "private network addressing information" or something instead? 5. Media Behavior, Latching however is not typically aware of the public mapping and would often advertise in the private address:port couple in signaling. Extra "in" here? This way, when the signalling intermediary performing HNT receives the private addressing information from the UA it will not know what address/ ports to send media to Could clarify that "private addressing information of a peer behind a NAT from the UA" (if that's what you mean). UAC network and 198.51.100/24 facing towards the UAS network. First time "UAC" and "UAS"; expand. Figure 2: Why are you using /port instead of :port notation here? As in "SBC allocates 198.51.100.2/22007". That's a bit confusing with the CIDR "198.51.100/24" notation in the same figure. And the latter address (and likewise on the other side of the SBC) are missing the last (0) octet. Figure 3: Latcing by a SIP SBC across two interfaces Typo: "Latcing". Also same slash-port notation issues as in figure 2. address information in in offers and answers may actually completely Extra "in" here too (and missing full stop at the end). There's no IANA considerations section. Please add one with "This document has no actions for IANA." with note to RFC editor to remove the section before publication. There's a bunch of idnits warning on the references; please check and fix these: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mmusic-latching-00.txt Cheers, Ari (as individual) From ari.keranen@ericsson.com Wed Apr 24 14:07: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 D84A021F910E for ; Wed, 24 Apr 2013 14:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 YgvsovL3f2Np for ; Wed, 24 Apr 2013 14:07:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1A21F9104 for ; Wed, 24 Apr 2013 14:07:37 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-53-51784998e6fb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.45.19728.89948715; Wed, 24 Apr 2013 23:07:36 +0200 (CEST) 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, 24 Apr 2013 23:07:36 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4A1302419; Thu, 25 Apr 2013 00:07:36 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BB51654D41; Thu, 25 Apr 2013 00:07:35 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 57E3D54ADA; Thu, 25 Apr 2013 00:07:35 +0300 (EEST) Message-ID: <51784997.3040207@ericsson.com> Date: Thu, 25 Apr 2013 00:07:35 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvre4Mz4pAg2NLTCwebJ/LaLH/4m1W i6nLH7M4MHtM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyphz7TJrwQ/2igsfP7I2 MK5h62Lk5JAQMJGY9bWLHcIWk7hwbz1QnItDSOAUo8S8h1uYIJwNjBKzJz9hhXB2M0ps+DQR KrOOUeLrilXMEM4KRokJu8+BDeMV0Ja49XUHC4jNIqAqsbD3LxOIzSZgL3FzwnWwGlGBZIml O5eyQdQLSpyc+QSsXkRAT2J/xzRGkKHMAv2MEtNWXARrEBZwl9iz/A07xLYeoKP6PoNN5RTw lZj7GORATqAOW4kLc66zQNjyEs1bZzNDvKcmcfXcJjBbCOiiq/9eMU5gFJ2FZPksJO2zkLQv YGRexciem5iZk15utIkRGBMHt/xW3cF455zIIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWl OanFhxiZODilGhilPlW1fKvKtK2u44pRVNN8u7nk0JkPM4+x7OTKW5I0ZYli0o89s1xZEv74 FPe31CX+1lt4/FHQM3e7188bTF16wzs3dTzco7rPU63l6VxxyR8Hzbv9z4hr6bAnngqpzt1f fJW57XPd5iddqzwct+9yrl917f/3fywCwYLlT/cKbLk6g7nilKISS3FGoqEWc1FxIgA6OnXq VwIAAA== Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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: Wed, 24 Apr 2013 21:07:39 -0000 On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote: > > On Apr 24, 2013, at 7:27 AM, Ari Keränen > wrote: > >> Hi, >> >> I reviewed the draft and noticed that in the intro section you >> mention a possible DoS attack using the delayed duplication >> functionality, but it's not discussed at all in the security >> considerations section. Should that be addressed too? >> > > Really? the whole section talks about what could happen if someone > could modify the SDP (number of dup streams, delays, etc.). > Especially the last paragraph mentions this. is it not clear? Not really. I guess I was expecting something more for a "new series of denial-of-service attacks" than what was described in the security section. To make this more clear, perhaps you could use the term DoS also in the security section, where applicable. Especially the last section talks about software bug or misconfiguration, but couldn't an active attacker also do this? Cheers, Ari From ari.keranen@ericsson.com Wed Apr 24 14:08: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 B227021F91A0 for ; Wed, 24 Apr 2013 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 93WqsRx0JxTS for ; Wed, 24 Apr 2013 14:07:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4734621F910E for ; Wed, 24 Apr 2013 14:07:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-44-517849ac06eb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 49.36.10459.CA948715; Wed, 24 Apr 2013 23:07:56 +0200 (CEST) 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; Wed, 24 Apr 2013 23:07:56 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 054702419; Thu, 25 Apr 2013 00:07:56 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7EAF954D41; Thu, 25 Apr 2013 00:07:55 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2F62754ADA; Thu, 25 Apr 2013 00:07:55 +0300 (EEST) Message-ID: <517849AB.2030703@ericsson.com> Date: Thu, 25 Apr 2013 00:07:55 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <515F03EF.1030100@ericsson.com> <51770AE0.4030800@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre4az4pAg/9bVC0ebJ/LaLH7wXcm i6nLH7M4MHtM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyjjdOIepYBFnxZ8r+1ga GFexdzFyckgImEjsfX+YCcIWk7hwbz1bFyMXh5DAKUaJdxN7mEESQgIbGCW2nlCDSOxmlDj5 7hcrhLOOUWLqk4PsEFUrGCWO3pIDsXkFtCWO/bnOBmKzCKhKzN75nxHEZhOwl7g54TpYvahA ssTSnUvZIOoFJU7OfMICYosI6Ens75gGVs8sMJFR4sOvMBBbWMBD4vf1KywQi3sYJbp/TAAr 4hTwlZiwH2IZs4CtxIU511kgbHmJ5q2zmSF+U5O4em4T1DuqElf/vWKcwCg6C8nuWUjaZyFp X8DIvIqRPTcxMye93HATIzAaDm75rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwGu284p74WKr/3R/jMDfTpRPLl21K1b74PcBcr5LX8W+SF8ff8k4Gc9YD /NKTb/2IlGB88WbKvzkFUf98+3//Mo5+8zLHwU+ibKeK1+UJ038qHWFeOZ83WOj7BJ35q6Zo rrmreOcrI/vpf8tiXURD20+uX6ijk/uVvzVl/Sq9N0pl4g7a34v/K7EUZyQaajEXFScCAHQh cENUAgAA Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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: Wed, 24 Apr 2013 21:08:01 -0000 On 4/24/13 9:36 AM, Ali C. Begen (abegen) wrote: > > On Apr 24, 2013, at 7:27 AM, Ari Keränen wrote: >> Alternatively, one could be more explicit >> and insert an "a=duplication-delay:0" line before the "a=mid:Ch1" >> line. >> >> This is quite vague. Could add an RFC2119 SHOULD/MUST/RECOMMEND here (and same in the next section) and tell when/why (not) to do it. >> > > I think a MUST would be too strong since it is not really a must. I also think making it a SHOULD would require us to explain when it could be ignored (which is really any time since nothing will break if it is ignored). Putting it would be more like informational purposes. I think "MAY" would be appropriate here. > > Would that address your concern? I think the important part is to tell why you should (or may) put it there. Is it, e.g., informational for a human reading the SDP or is there some corner case where this would help? If there's no real value adding it there, perhaps it's better to not talk about this alternative at all since it will potentially just results in unnecessary differences how it ends up implemented. Cheers, Ari From pkyzivat@alum.mit.edu Wed Apr 24 15:48: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 E588821F8E9A for ; Wed, 24 Apr 2013 15:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 KJ3deFNLUvrI for ; Wed, 24 Apr 2013 15:48:44 -0700 (PDT) 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 5360C21F8DCF for ; Wed, 24 Apr 2013 15:48:43 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id TqqH1l00D0bG4ec53yojEp; Wed, 24 Apr 2013 22:48:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Tyoi1l01C3ZTu2S3PyoimD; Wed, 24 Apr 2013 22:48:43 +0000 Message-ID: <5178614A.1090207@alum.mit.edu> Date: Wed, 24 Apr 2013 18:48:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C35D1A5@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=1366843723; bh=8KqSLT/YiDF/QIaBZP4ah5Hr/hRwRduSOPQ1URNRL+A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WHp6M5H3qkkZVEAAwh4JpHSZU3g3UbYIpULKbXbYadu/E5KPLXW+3Oh+OHy5+hoLf oy9SBDzgqD5CB+YpKNpJDHlTP6ciRDjfFgJXloSCATJS/dzMzFMTkLLwGek9Z8NZ5r 71ufSQ39Twz2axflUjNekcHo1Oh47359rbIR/MdKjS2Yr+vdVa/wMSqsVzYO/Dh8Qe dqqgQd7KUaW7ESweM7QStwa4HK9GqDP8Em+nOMacfYQJwykEaXaOjzIunNVuW6cgZU y3dlIosqY7ErWlr7z44qnV8zj3Mlwz/Z72vdNG+QmJYkL8DLqeWDQt3mUJ2nbrzJHP OwD/bcV/xy53g== Subject: Re: [MMUSIC] Feedback requested on requirements 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, 24 Apr 2013 22:48:45 -0000 On 4/24/13 1:36 AM, Christer Holmberg wrote: >> On 23 April 2013 08:30, Dale R. Worley wrote: >>> 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. >> >> I'm not sure how to parse this. Is that a double-negative or just two >> negatives for emphasis? >> >> Do you intend to say that the solution should NOT rely on new >> attributes because SBCs will suppress them, or that the solution is >> permitted to use new attributes because SBCs are expected to pass >> attributes. > > I mean the latter. The intended parsing is: > > (non-DES) C5 SBCs generally pass through attributes that they do not... What evidence do you have to support this assertion? AFAIK this is far from universally true. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 24 15:58: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 54E9F21F91D8 for ; Wed, 24 Apr 2013 15:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 WBgwUOjDoPSn for ; Wed, 24 Apr 2013 15:58:32 -0700 (PDT) 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 2568821F91CA for ; Wed, 24 Apr 2013 15:58:31 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id TmVQ1l0090mv7h055yyXCT; Wed, 24 Apr 2013 22:58:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id TyyX1l0033ZTu2S3XyyXFc; Wed, 24 Apr 2013 22:58:31 +0000 Message-ID: <51786396.9080706@alum.mit.edu> Date: Wed, 24 Apr 2013 18:58:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> In-Reply-To: <201304231935.r3NJZ24T3171577@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=1366844311; bh=OV4t8BJ7sUX64B7rdtvM3qhq6SkXc55EkLQ5yYmsZr8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oot1Kp4dcqV8hUR3nKYeZo2AIRkKMHFyV2wv0U2vYJnFbtRUBzZ6Y64F22YvG7VsT zbIAbA6KTSEc4vtBmzjxmY7n8PBHXUEPyVdq0knFopmujBSjp8gIMViwzA/wbSPdxU pCWA98YXAVzw750HzhWCuBoApXyaRDSf3NIa2bCxhEgdliFaaEnW5HsQ5K4TEYv+04 NK4A0w/mV2lGgbV5geyEzrQMLNSJLog4ii3C1Isp8JGrGFg8FvK5pz+uwgVQ5z1/Em bjxGhxhy4+g1u8YG6RPljdrbnlu6+xTTgLC4MhHgY8TxRuVQuLzeeltJaZ7CgoTi3Y BKBn12truiogQ== Subject: Re: [MMUSIC] Feedback requested on requirements 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, 24 Apr 2013 22:58:34 -0000 On 4/23/13 3:35 PM, Dale R. Worley wrote: >>> DES C4 Any additional m= lines prescribed by the bundle mechanism >>> should be ordered after the constituent m= lines. >> >> That is normal Offer/Answer procedure, isn't it? > > If a "bundle" media description is to be added, it ought to be added > *after* the m= lines for the constituent media streams, so that the > "bundle" media description doesn't change which media description is > identified as "the first audio media description", "the second audio > media description", "the first video media description", etc. So, suppose A makes an offer to B with 4 m-lines to be bundled, with a 5th "bundle" m-line after those. But then suppose B needs those split into two bundles with different addresses. B could accept the initial offer but reject m-lines 2 & 4. So then there is a bundle consisting of m-lines 1,3,5. Then it might send another offer back toward A, reactivating m-lines 2 & 4, and adding m-line 6 as the bundle m-line for the second bundle. Assuming A accepts that, then there will be two bundles, 1,3,5 and 2,4,6. Is that consistent with what you are proposing here? Or must m-lines 2&4 be abandoned, and the new bundle constructed from m-lines 6,7,8. Thanks, Paul Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 24 16:35:19 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 8E1B321F91A2 for ; Wed, 24 Apr 2013 16:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 TGEm97ZxT+iB for ; Wed, 24 Apr 2013 16:35:19 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C890821F8F63 for ; Wed, 24 Apr 2013 16:35:18 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id TzaB1l0020vyq2s58zbJRf; Wed, 24 Apr 2013 23:35:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id TzbH1l00f3ZTu2S3RzbHJS; Wed, 24 Apr 2013 23:35:18 +0000 Message-ID: <51786C35.9040008@alum.mit.edu> Date: Wed, 24 Apr 2013 19:35:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <5178159E.9070405@ericsson.com> In-Reply-To: <5178159E.9070405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366846518; bh=ZCIZtPuqupLdwiL7+PNsXCtZr/N52GNz0WUbaYeK8xQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fNPcJ+6vXcQ4F57vX1TZz+Lj50zr4DPMw4+9aax3difO+hp5iMAwjdW7O3QDpEXAS lC3VL3oK9JnroHBbgph2J7YJFHAm2ihwk25W0Gko6w+cl6mj3zJCsKh8Epo8L5Uk2/ 90MjbS9/zr/pBBGUtxYjYu9cjcGd1/+SGkW2TYpvqM2PA7jOSAlmVlaXJneNVttrB6 GZlWA8Ll6HQF+nETU+8ptQcFXDt/PZfO6zOkl8eZ0/A5Yw6SrbNIyS01dFfG/tCmCd XZ+FNs0oHnLK/0Y4nmU2hN0J2MTnp1ZGfY+aZ37QRL/vT4NeeVBcV0KB8QuU1+Raq6 Z5NqWxldLWySA== Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-latching-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: Wed, 24 Apr 2013 23:35:19 -0000 WGLC Comments: I did a fresh read of this. I found a few small things: Section 5: 1. After receiving an offer from a NATed UA, a signaling intermediary located on the public Internet would allocate a set of IP address:ports on a media relay. The set would then be advertised to the remote party so that it would use it for all media it wished to send toward the UA. The last sentence is using "it" in two different ways, and neither is clear. I suggest: 1. After receiving an offer from a NATed UA, a signaling intermediary located on the public Internet would allocate a set of IP address:ports on a media relay. The set would then be advertised to the remote party so that it would use those media relay address:ports for all media it wished to send toward the UA. Similarly for 2, I suggest: 2. Next, after receiving an answer to its offer, the signaling server would allocate a second address:port set on the media relay. It would advertise this second set in the answer to the UA. The UA will then send to this media relay address:port. Figure 2: This figure is inconsistent with the steps described above. It shows both address/port sets being allocated when the offer is received, while the steps say that the second pair is allocated when the answer is received. Thanks, Paul On 4/24/13 1:25 PM, Ari Keränen wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-latching-00 > > The WGLC ends on May 8th, 2013. > > Please review the document send your comments both to the authors and to > the MMUSIC mailing list. If you review the document but do not have any > comments, please send a note to that effect as well. > > The document is available here: > http://tools.ietf.org/html/draft-ietf-mmusic-latching-00 > > > Thanks, > Ari > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From internet-drafts@ietf.org Wed Apr 24 23:56: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 B09ED21F93AA; Wed, 24 Apr 2013 23:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 CY7lxgHJXtNA; Wed, 24 Apr 2013 23:56:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B7C21F8AE8; Wed, 24 Apr 2013 23:56:06 -0700 (PDT) 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.44.p4 Message-ID: <20130425065606.9636.74857.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 23:56:06 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-18.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, 25 Apr 2013 06:56:25 -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 : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-18.txt Pages : 35 Date : 2013-04-24 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Thu Apr 25 00:11: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 D9E4521F850E for ; Thu, 25 Apr 2013 00:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 HqeriWaSQYis for ; Thu, 25 Apr 2013 00:11:07 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0793221F9350 for ; Thu, 25 Apr 2013 00:11:06 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r3P7B3SQ012117; Thu, 25 Apr 2013 10:11:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Apr 2013 10:11:02 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.240]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0328.011; Thu, 25 Apr 2013 07:11:01 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-18.txt Thread-Index: AQHOQYIEBnlyvQUGO0Wyi/jg1U9A1pjmgaJw Date: Thu, 25 Apr 2013 07:11:01 +0000 Message-ID: References: <20130425065606.9636.74857.idtracker@ietfa.amsl.com> In-Reply-To: <20130425065606.9636.74857.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYpTTbxVIFml5YIjdQ82Caqueg2RS9O8k7Kzam4w/8HfqAZJnJz/cdSoNYr/hQg4dC69S/fGAgbcFlmElyUeihJIZik9vaYbJt9rVrFRVzILh7dhPzpCIxZl9RL7j9ReHOAjI4PpDssR60nsSuWq6pS82ebaplBc1jVKKzrmrX6pAEvehQMOcPz6h+UCllVQvwA== x-originating-ip: [172.21.81.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Apr 2013 07:11:03.0021 (UTC) FILETIME=[0BD351D0:01CE4184] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-18.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, 25 Apr 2013 07:11:12 -0000 Dear WG, We have submitted version 18 of the SDP CS draft, including changes based o= n comments received during Last Call: - fixed typos - changed text on handling of received port number from " any syntactically= valid value, which is to be ignored" to " any value resulting from the pro= duction rule of connection-address in RFC4566 [RFC4566], but in all cases a= ny value encountered will be ignored." - if the endpoint is aware of the codecs it can use on the PSTN bearer, it = MUST use those (was SHOULD) payload numbers - we do not enumerate the correlation mechanisms in order to make the text = valid also for cases when additional correlation mechanisms are used: "[...= ] it MUST add at least one of the possible correlation mechanisms, [...]" Regards, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 25. huhtikuuta 2013 9:56 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-18.txt 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 : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-18.txt Pages : 35 Date : 2013-04-24 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Thu Apr 25 00:15:17 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 1E7A021F9397 for ; Thu, 25 Apr 2013 00:15:17 -0700 (PDT) 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=0.160, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 j4YSkK2Cjjup for ; Thu, 25 Apr 2013 00:15:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4945021F9382 for ; Thu, 25 Apr 2013 00:15:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-05-5178d803b1a8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 61.1E.03253.308D8715; Thu, 25 Apr 2013 09:15:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 09:15:14 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: Can you create a BUNDLE with a single m= line? Thread-Index: Ac5BhAE7Gx+m/jcrR5qWYbXLAfAmJA== Date: Thu, 25 Apr 2013 07:15:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F01B@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrS7zjYpAgxXrpC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMX/BAoWsFfcm7SEtYGxg72LkZNDQsBEYvnVA4wQtpjEhXvr 2boYuTiEBA4zSpxu+c0M4SxhlFiwfiZQhoODTcBCovufNkiDiIC6xNe9PcwgtrBAjMTyYxdZ IOKxErMa1rJD2HoSDT1/wOIsAqoSG9d+YAOxeQV8JdqndoHZjECLv59awwRiMwuIS9x6Mp8J 4iABiSV7zjND2KISLx//Y4WwFSWuTl/OBHIOs4CmxPpd+hCtihJTuh+yQ4wXlDg58wnLBEbh WUimzkLomIWkYxaSjgWMLKsY2XMTM3PSy803MQID+OCW3wY7GDfdFzvEKM3BoiTOG+56IUBI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY4Tp7uREZaPZQVP3OZvu0z78bUn9L4n5z/+GBFV/ mMzaYXzzq1PjT6mLPQFdQW7lyRbMfvPfiKxqPr6nqfrAesXjm8PKTWanp1d4ffeIU/2kbHIj w+pO6c+YrqPROzXmL9mxtq/W+lLwC2GT7VOa9gZJvVK6+GUxwyShuR33VPidPFbd+b9qmRJL cUaioRZzUXEiAFWV/b4uAgAA Subject: Re: [MMUSIC] 10 BUNDLE questions: Can you create a BUNDLE with 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, 25 Apr 2013 07:15:17 -0000 SGksDQoNCkl04oCZcyBhIGxpdHRsZSB0cmlja3kgdG8gZm9sbG93IHRoZSBkaXNjdXNzaW9ucyBv biBhbGwgMTAgcXVlc3Rpb25zIGluIGEgc2luZ2xlIHRocmVhZCwgc28gSeKAmWxsIHRyeSB0byBz ZXBhcmF0ZSB0aGVtLCBzZWUgd2hlcmUgd2UgYXJlLCBhbmQgd2hhdCBhZGRpdGlvbnMvY2hhbmdl cyB0byB0aGUgYnVuZGxlIGRyYWZ0IHdvdWxkIGJlIG5lZWRlZC4NCg0KPjEuIENhbiB5b3UgY3Jl YXRlIGEgQlVORExFIHdpdGggYSBzaW5nbGUgbT0gbGluZT8gKGFzc3VtaW5nIHllcykNCg0KQ29u Y2x1c2lvbjogCUkgaGF2ZSBzZWVuIG5vIG9iamVjdGlvbnMvY29uY2VybnMgd2l0aCBhbGxvd2lu ZyB0aGlzLCBhbmQgdGhlIGdyb3VwaW5nIGZyYW1ld29yayBkb2VzIG5vdCBmb3JiaWQgaXQsIHNv IEkgc3VnZ2VzdCB3ZSBhbGxvdyBpdC4NCg0KRHJhZnQgaW1wYWN0OglJIHN1Z2dlc3QgdG8gYWRk IGEgbm90ZSBzYXlpbmcgdGhhdCBhIGJ1bmRsZSBncm91cCBjYW4gY29udGFpbiBhIHNpbmdsZSBt LSBsaW5lLg0KDQpQbGVhc2UgaW5kaWNhdGUgaWYgeW91IE9CSkVDVCB0byB0aGUgY29uY2x1c2lv biwgYW5kL29yIGlmIHlvdSBETyBOT1QgdGhpbmsgd2UgbmVlZCB0byBzYXkgYW55dGhpbmcgYWJv dXQgdGhpcyBpbiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From abegen@cisco.com Thu Apr 25 00:55: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 D2BAB21F93AB for ; Thu, 25 Apr 2013 00:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 n+1FdEGG1Wzs for ; Thu, 25 Apr 2013 00:55:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F034221F9377 for ; Thu, 25 Apr 2013 00:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1366876532; x=1368086132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cwhPolj7/ZOGFLcqW+XW0sNQ7WW5ZkwLfItjv07sIqo=; b=b3KyX3Pgks7vdXZPTCLNYgTNU9QzRYjK+Ci5LtnjfBJR2oQ4kubqNpkS /JwVQQod23+qKw2TH6tXNZl5gAAeiLOvkZ6dEi5OLY/l7NCib8B+lEBGU uJq2vY5XdOMtHNDUiKrNGtXpgtxqrjZqDEi95vvIPCl1KceyPvFpAcMsF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA3heFGtJXHA/2dsb2JhbABRgmUhvmaBARZ0gh8BAQEDAXkFCwIBCBgKJDIlAgQOBQiIBgYBvh2NeYEEAjEHgmthA4hYn2SDDoFrPQ X-IronPort-AV: E=Sophos;i="4.87,548,1363132800"; d="scan'208";a="202868611" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 25 Apr 2013 07:55:31 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3P7tVYi023187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 07:55:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 02:55:31 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01 Thread-Index: AQHOMh+OrJd+p16ntUKckcdJFFsN55jk0xuAgACHcACAAPSDgIAAtQcA Date: Thu, 25 Apr 2013 07:55:30 +0000 Message-ID: References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> <51784997.3040207@ericsson.com> In-Reply-To: <51784997.3040207@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8996FBEF43ED1D4E9F1B670A03EAFF45@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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: Thu, 25 Apr 2013 07:55:36 -0000 On Apr 25, 2013, at 6:07 AM, Ari Ker=E4nen wrote= : > On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote: >>=20 >> On Apr 24, 2013, at 7:27 AM, Ari Ker=E4nen >> wrote: >>=20 >>> Hi, >>>=20 >>> I reviewed the draft and noticed that in the intro section you >>> mention a possible DoS attack using the delayed duplication >>> functionality, but it's not discussed at all in the security >>> considerations section. Should that be addressed too? >>>=20 >>=20 >> Really? the whole section talks about what could happen if someone >> could modify the SDP (number of dup streams, delays, etc.). >> Especially the last paragraph mentions this. is it not clear? >=20 > Not really. I guess I was expecting something more for a "new series of d= enial-of-service attacks" than what was described in the security section. = To make this more clear, perhaps you could use the term DoS also in the sec= urity section, where applicable. >=20 > Especially the last section talks about software bug or misconfiguration,= but couldn't an active attacker also do this? >=20 I will change the text as follows. let me know if there are objections. OLD: Another security risk is due to possible software misconfiguration or a software bug where a large number of duplicates could be unwillingly signaled in the 'duplication-delay' attribute. In applications where this attribute is to be used, it is a good practice to put a hard limit both on the number of duplicate streams and the total delay introduced due to duplication regardless of what the SDP description specifies. NEW: Another security risk is due to possible software misconfiguration or a software bug where a large number of duplicates could be unwillingly signaled in the 'duplication-delay' attribute. Similarly, an= attacker can use this attribute to start a denial-of-service attack by sig= naling and sending too many duplicated streams. In applications where this attribute is to be used, it is a good practice to put a hard limit both on the number of duplicate streams and the total delay introduced due to duplication regardless of what the SDP description specifies. >=20 > Cheers, > Ari From abegen@cisco.com Thu Apr 25 01:19: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 5D97D21F93B4 for ; Thu, 25 Apr 2013 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 9jT1yP0T7mMr for ; Thu, 25 Apr 2013 01:19:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6925021F8E6A for ; Thu, 25 Apr 2013 01:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1366877981; x=1368087581; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rU0iBD1f74Y4UXhIh8RxKD8sdx8vWtJSfslq5dlaVsY=; b=ZUOJxNHv+wOO4ecUGVlUjSW3W+euJNYaAh1SgEhd5/UR5vWCQLXvt2Ux dYmrUrAg5VamCnL62LcSfOxf7MOHGa95h7y72yUkibLndC6p25spEMmPO m5Z++7hx+8DRvWb5ryqlUEX5kqGses+Ow16FB7HngLFKkwXwWnd0Of2B8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMLmeFGtJV2d/2dsb2JhbABRgmUhvmaBARZ0gh8BAQEDAXkFCwIBCBgKJDIlAgQOBQiIBgYBvhyOfQIxB4JrYQOIWJ9kgw6CKA X-IronPort-AV: E=Sophos;i="4.87,548,1363132800"; d="scan'208";a="202954189" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 25 Apr 2013 08:19:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3P8JcLo027596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 08:19:38 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 03:19:38 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-01 Thread-Index: AQHOMh+Mau+5XnZYeUyBunjPZbI7K5jk0x4AgACIkYCAAPN3gIAAu6yA Date: Thu, 25 Apr 2013 08:19:37 +0000 Message-ID: References: <515F03EF.1030100@ericsson.com> <51770AE0.4030800@ericsson.com> <517849AB.2030703@ericsson.com> In-Reply-To: <517849AB.2030703@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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: Thu, 25 Apr 2013 08:19:42 -0000 On Apr 25, 2013, at 6:07 AM, Ari Ker=E4nen wrote= : > On 4/24/13 9:36 AM, Ali C. Begen (abegen) wrote: >>=20 >> On Apr 24, 2013, at 7:27 AM, Ari Ker=E4nen wr= ote: >>> Alternatively, one could be more explicit >>> and insert an "a=3Dduplication-delay:0" line before the "a=3Dmid:Ch1" >>> line. >>>=20 >>> This is quite vague. Could add an RFC2119 SHOULD/MUST/RECOMMEND here (a= nd same in the next section) and tell when/why (not) to do it. >>>=20 >>=20 >> I think a MUST would be too strong since it is not really a must. I also= think making it a SHOULD would require us to explain when it could be igno= red (which is really any time since nothing will break if it is ignored). P= utting it would be more like informational purposes. I think "MAY" would be= appropriate here. >>=20 >> Would that address your concern? >=20 > I think the important part is to tell why you should (or may) put it ther= e. Is it, e.g., informational for a human reading the SDP or is there some = corner case where this would help? It is informational line for humans. Are you ok if we say: "Alternatively, one MAY explicitly insert an "a=3Dduplication-delay:0" line= before ... for informational purposes." > If there's no real value adding it there, perhaps it's better to not talk= about this alternative at all since it will potentially just results in un= necessary differences how it ends up implemented. >=20 Even if we dont mention this, one can use this and the SDP would be valid u= nless we say one MUST NOT be explicit (I think this would be worse to say) -acbegen >=20 > Cheers, > Ari From christer.holmberg@ericsson.com Thu Apr 25 03:57: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 87DB621F937B for ; Thu, 25 Apr 2013 03:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 YWLgAWa6Bh+W for ; Thu, 25 Apr 2013 03:57:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C90C21F92C0 for ; Thu, 25 Apr 2013 03:57:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-f9-51790c0c9a15 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A2.5E.10459.C0C09715; Thu, 25 Apr 2013 12:57:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 12:57:16 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd? Thread-Index: Ac5BoMU7D+du+vhxRBeyo6SZqShpVw== Date: Thu, 25 Apr 2013 10:57:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F1AC@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrS4PT2WgwbptchZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr3lR5kK2gQq/j04xtzAeIG/i5GTQ0LARGL643NsELaYxIV7 64FsLg4hgcOMEu3L2pkhnCWMEvMer2LvYuTgYBOwkOj+pw3SICKgLvF1bw8ziC0s0Mso0Xyr GKReRKCPUeLnyiNMEEV6EqvuNrKC2CwCqhIH3m5kBLF5BXwlTt2/ChZnBNr8/dQasHpmAXGJ W0/mM0FcJCCxZM95ZghbVOLl43+sELaixNXpy5lA7mEW0JRYv0sfolVRYkr3Q3aI8YISJ2c+ YZnAKDwLydRZCB2zkHTMQtKxgJFlFSN7bmJmTnq54SZGYBAf3PJbdwfjqXMihxilOViUxHll 2SoDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDWt+4Iq8oW8Gg9abL2JVP/oavBK85F8h1O UXh5S87nRvFRh1VTrl9fvr6wml/PVkPFZ9dfgW2fpWffaQivK+uaNtXV6sNqx2Cmy8/yjgQd EzsUXL3VS1Z5erzmkY/C6U2bHx62vCwecPbiPpO3J+c5lM757M06aenvTvYJdfHvY7b+Ef3G 1N6ixFKckWioxVxUnAgAW0TZ6zACAAA= Subject: Re: [MMUSIC] 10 BUNDLE questions: Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd? 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, 25 Apr 2013 10:57:18 -0000 SGksDQoNCj4xMC4gSXMgdGhlcmUgYW55IHdheSwgaW4gYSBzaW5nbGUgUGVlckNvbm5lY3Rpb24s IHRvIHVuQlVORExFIG09IGxpbmVzIHRoYXQgd2VyZSBwcmV2aW91c2x5IEJVTkRMRWQgKGFzc3Vt ZSBubykNCg0KV2VsbCwgd2hhdCBpcyBwb3NzaWJsZSB0byBkbyBpbiBhIFBlZXJDb25uZWN0aW9u IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIEJVTkRMRSwgYnV0IHdlIG9mIGNvdXJzZSBuZWVkIHRv IGRlY2lkZWQgd2hldGhlciBCVU5ETEUgaXRzZWxmIGFsbG93cyB0aGUgInVuYnVuZGxpbmciIG9m IHByZXZpb3VzbHkgQlVORExFZCBtLSBsaW5lcy4gDQoNCihJbiBTRFAgTy9BIGxhbmd1YWdlIHRo YXQgd291bGQgbWVhbiBzZW5kaW5nIGFuIG9mZmVyIHdoZXJlIHRoZSB1bkJVTkRMRWQgbT0gbGlu ZXMgYXJlIG5vIGxvbmdlciBhc3NvY2lhdGVkIHdpdGggYSBCVU5ETEUgZ3JvdXAuKQ0KDQpUaGVy ZSBoYXMgYmVlbiBpbmRpY2F0aW9ucyB0aGF0IGl0IHdvdWxkIGJlIG5lZWRlZCBmb3Igc29tZSAz cGNjIGNhc2VzLg0KDQpPdGhlcnMgaGF2ZSBzYWlkIHRoYXQgaXQgd291bGQgbWVzcyB1cCB0aGlu Z3MsIGJlY2F1c2UgeW91IHdvdWxkIGhhdmUgdG8gYmUgYWJsZSB0bywgZHVyaW5nIHRoZSBTRFAg Ty9BICJ0cmFuc2l0aW9uIiwgc2ltdWx0YW5lb3VzbHkgZG8gc3R1ZmYgYWNjb3JkaW5nIHRvIHRo ZSBvbGQgKGUuZy4gQlVORExFZCkgbmVnb3RpYXRlZCBTRFAgYW5kIHRoZSBuZXcgKGUuZy4gdW5C VU5ETEVkKSBTRFAuDQoNClJlZ2FyZGluZyBoYXZpbmcgdG8gYmUgYWJsZSB0byBkbyB0aGluZ3Mg c2ltdWx0YW5lb3VzbHksIHRoYXQgaXMgYSBnZW5lcmljIFNEUCBPL0EgcHJvYmxlbSwgbm90IHJl bGF0ZWQgdG8gQlVORExFIGFzIHN1Y2guIEJ1dCwgb2YgY291cnNlLCBCVU5ETEUgaW5jcmVhc2Vz IHRoZSB0aGluZ3MgeW91IGhhdmUgdG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseSBoYW5kbGUg ZHVyaW5nIHRoZSB0cmFuc2l0aW9uLiANCg0KQnV0LCBhcmUgZXhpc3RpbmcgcHJvZHVjdHMgcmVh bGx5IGFibGUgdG8gZG8gdGhpbmdzIHNpbXVsdGFuZW91c2x5IGR1cmluZyBhIHRyYW5zaXRpb24s IG9yIGFyZSB3ZSBkaXNjdXNzaW5nIHRoaW5ncyB3aGljaCB3b24ndCB3b3JrIGluIHJlYWwgbGlm ZSBkZXBsb3ltZW50cyBhbnl3YXk/DQoNCkFub3RoZXIgc3VnZ2VzdGlvbiB3YXMgdG8sIGluc3Rl YWQgb2YgbW9kaWZ5aW5nIHRoZSBleGlzdGluZyBtLSBsaW5lcywgc2ltcGx5IGFkZCBuZXcgbS0g bGluZXMsIHJlcHJlc2VudGluZyBlLmcuIHRoZSB1c2VyIHRvIHdob20gYSBjYWxsIGhhcyBiZWVu IHRyYW5zZmVycmVkLg0KDQpJIHRoaW5rIHdlJ2xsIG5lZWQgYSBsaXR0bGUgbW9yZSB0aW1lIHRv IHRoaW5rIGFib3V0IHRoaXMsIHNvIHdvbid0IHN1Z2dlc3QgYW55IGNvbmNsdXNpb24gYXQgdGhp cyBwb2ludCwgYnV0IGluc3RlYWQgbGlzdCBpdCBhcyBhbiBPUEVOIElTU1VFLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQo= From christer.holmberg@ericsson.com Thu Apr 25 04:01: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 0E47A21F9423 for ; Thu, 25 Apr 2013 04:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 fP9DMBf1sstx for ; Thu, 25 Apr 2013 04:01:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30C21F941D for ; Thu, 25 Apr 2013 04:01:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-a9-51790d235a25 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 97.7F.19728.32D09715; Thu, 25 Apr 2013 13:01:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:01:54 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: 3. When creating an initial offer, how should we deal with the case where a "null" port is to be used with trickle ICE (since 6.1:1 indicates the ports MUST be different)? Thread-Index: Ac5BhinCSSktjDSCRnqiL3Mm5oCRww== Date: Thu, 25 Apr 2013 11:01:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F1D7@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvra4yb2WgwaEFkhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxofOXpaCFbwV3x6JNzD+4eli5OSQEDCR2Hx2DSOELSZx4d56 ti5GLg4hgcOMEvtP9jJDOEsYJa59P8fexcjBwSZgIdH9TxukQURAXeLr3h6wGmGBW4wS/97c ZAFxRARuM0p83XSDEaJKT2Lbyy+sIDaLgKrE9IsHwGxeAV+Jg0s+MIHYjECrv59aA2YzC4hL 3HoynwniJAGJJXvOM0PYohIvH/9jhbAVJa5OX84EchCzgKbE+l36EK2KElO6H7JDjBeUODnz CcsERuFZSKbOQuiYhaRjFpKOBYwsqxjZcxMzc9LLjTYxAoP44JbfqjsY75wTOcQozcGiJM4r y1YZKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRNH1b3gw5dkYh95K1HLdOneCOy1Mu3st9 9WPPDw12oY0Sq15EvJ78SH9eoCbXlW+nmL6Gi+99Wr75k+qFkp8zzRckXmYM1ZO84bU6/Ic+ T3gI3yRlQYOmdaue8W9vSzqcsnfJiux1ipc0tngese4M/JgiGigV8uaY/4sEFkvp+stezbOj ouOVWIozEg21mIuKEwHXl4njMAIAAA== Subject: Re: [MMUSIC] 10 BUNDLE questions: 3. When creating an initial offer, how should we deal with the case where a "null" port is to be used with trickle ICE (since 6.1:1 indicates the ports MUST be different)? 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, 25 Apr 2013 11:01:59 -0000 SGksDQoNCj4zLiBXaGVuIGNyZWF0aW5nIGFuIGluaXRpYWwgb2ZmZXIsIGhvdyBzaG91bGQgd2Ug ZGVhbCB3aXRoIHRoZSBjYXNlIHdoZXJlIGEgIm51bGwiIHBvcnQgaXMgdG8gYmUgdXNlZCB3aXRo IHRyaWNrbGUgSUNFIChzaW5jZSA2LjE6MSBpbmRpY2F0ZXMgdGhlIHBvcnRzIE1VU1QgYmUgZGlm ZmVyZW50KT8NCg0KRGlzY3Vzc2lvbjoNCg0KSW4gZ2VuZXJhbCwgZnJvbSBhIHB1cmUgU0RQIE9m ZmVyL0Fuc3dlciBwZXJzcGVjdGl2ZSwgSSBzZWUgbm8gbWFqb3IgaXNzdWUgd2l0aCB1c2luZyBw b3J0cyAwIG9yIDkgZm9yIG11bHRpcGxlIG0tIGxpbmVzLiBUaGF0IHNob3VsZCBiZSBhbGxvd2Vk IGV2ZW4gd2l0aG91dCBCVU5ETEUuDQoNCkl0IHdvdWxkIG5lZWQgdG8gYmUgaW5kaWNhdGVkIGlu IHRoZSBCVU5ETEUgZHJhZnQsIHRob3VnaC4NCg0KVGhlIHByb2JsZW0sIGFzIFBhdWwgaGFzIGlu ZGljYXRlZCwgc2VlbXMgdG8gY29tZSBmcm9tIHRoZSBncm91cGluZyBmcmFtZXdvcmsgKFJGQyA1 ODg4KSwgd2hpY2ggZm9yYmlkcyAoZm9yIHJlYXNvbnMgbm90IGNsZWFybHkgc3BlY2lmaWVkKSB0 aGUgdXNhZ2Ugb2YgYSBwb3J0IHplcm8gbS0gbGluZSB3aXRoaW4gYSBncm91cC4gDQoNCkFsc28s IEkgdGhpbmsgaXQgYXBwbGllcyB0byBib3RoIFNEUCBvZmZlcnMgYW5kIGFuc3dlcnMsIGFuZCBh bHNvIHRvIHN1YnNlcXVlbnQgb2ZmZXJzIGFuZCBhbnN3ZXJzLg0KDQpUaGUgb3B0aW9ucyBJIGNh biB0aGluayBvZi4NCg0KMSkgVXBkYXRlIFJGQyA1ODg4LCBhbmQgcmVsYXggdGhlIGN1cnJlbnQg cnVsZS4gT2YgY291cnNlLCB3ZSB3b3VsZCBjYXJlZnVsbHkgbmVlZCB0byBzdHVkeSB0aGF0IGl0 IHdvdWxkIGJlIG9rIHRvIHJlbGF4IHRoZSBydWxlLg0KDQoyKSBVc2UgYW5vdGhlciBwb3J0LCBl LmcuIDkNCg0KMykgS2VlcCBtLSBsaW5lcyB3aXRoIHBvcnQgMCBvdXRzaWRlIG9mIGFueSBidW5k bGUgZ3JvdXAuIFdoZW4gcmVtb3Zpbmcgc3RyZWFtcyB0aGF0IG1heSBiZSBvaywgYnV0IEkgYW0g bm90IHN1cmUgaG93L3doZXRoZXIgaXQgd291bGQgd29yayB3aXRoIHRyaWNrbGUgSUNFLg0KDQo0 KSBVc2UgImR1bW15IiBwb3J0IHZhbHVlcyBpbiB0aGUgbS0gbGluZSwgdW50aWwgdGhlIHJlYWwg cG9ydCB2YWx1ZXMgY2FuIGJlIHJldmVhbGVkLg0KDQpTbywgdGhpcyBpcyBhbiBvcGVuIGlzc3Vl IHdlIG5lZWQgdG8gZGlzY3Vzcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From christer.holmberg@ericsson.com Thu Apr 25 04:02: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 B0FF521F9436 for ; Thu, 25 Apr 2013 04:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=0.6, 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 BBiwPIKVhR5N for ; Thu, 25 Apr 2013 04:02:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EBCF821F9425 for ; Thu, 25 Apr 2013 04:02:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-84-51790d526eea Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.B0.03253.25D09715; Thu, 25 Apr 2013 13:02:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:02:42 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: Can you create multiple BUNDLEs? Thread-Index: Ac5BhQndjFtLqTAuRZeJBUbWGc8XwQ== Date: Thu, 25 Apr 2013 11:02:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F1EA@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW4wb2Wgwa8ljBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr0F/AVHWCpOXt/A0sC4haWLkZNDQsBE4uKfrewQtpjEhXvr 2boYuTiEBA4zSqxa/ZkFwlnCKDF/EYjDwcEmYCHR/U8bpEFEQF3i694eZhBbWMBb4t/uC+wQ cR+J4/0XWSBsPYkdS9+B2SwCqhJfV+0Cq+EV8JV4+OkzE4jNCLT4+6k1YDazgLjErSfzmSAO EpBYsuc8M4QtKvHy8T9WCFtR4ur05Uwg5zALaEqs36UP0aooMaX7IdR4QYmTM5+wTGAUnoVk 6iyEjllIOmYh6VjAyLKKkT03MTMnvdx8EyMwgA9u+W2wg3HTfbFDjNIcLErivHJslYFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGDf1u1df2HF65oOJZ0/q+65v1lK0evyJ9YHQ9aYQr2/d d6U0pZuky7hvP3098ayPa8y8bZ4Xr7rf5JDa9/r8Ma1ZgpYr0+ecvSZ6S4vxHl9uVJgCm7d0 twpHflqZ9t6pZ3ODGG7GdSTMOM9XK7K9bM2UoLBH394canhadjXz8tqp7QovpJ5EOCqxFGck GmoxFxUnAgDBfmuCLgIAAA== Subject: Re: [MMUSIC] 10 BUNDLE questions: Can you create multiple BUNDLEs? 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, 25 Apr 2013 11:02:44 -0000 SGksDQoNCj4gMi4gQ2FuIHlvdSBjcmVhdGUgbXVsdGlwbGUgQlVORExFcz8NCg0KQ29uY2x1c2lv bjogCUkgaGF2ZSBzZWVuIG5vIG9iamVjdGlvbnMvY29uY2VybnMgd2l0aCBhbGxvd2luZyB0aGlz IGluIGdlbmVyYWwsIHNvIEkgc3VnZ2VzdCB3ZSBhbGxvdyBpdC4gSG93ZXZlciwgdGhlcmUgaXMg YXQgbGVhc3Qgb25lIHJlbGF0ZWQgcXVlc3Rpb24sIGJlbG93Og0KDQpRdWVzdGlvbiAyYToJRG8g d2UgYWxsb3cgc2VwYXJhdGUgYnVuZGxlIGdyb3VwcyB0byB1c2UgdGhlIHNhbWUgbG9jYWwgcG9y dDphZGRyZXNzPyBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRoYXQgd2UgZG8gTk9UIGFsbG93IGl0 LCBpZSBlYWNoIGJ1bmRsZSBncm91cCBtdXN0IHVzZSBhIHVuaXF1ZSBwb3J0OmFkZHJlc3MuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From christer.holmberg@ericsson.com Thu Apr 25 04:16: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 555A621F9350 for ; Thu, 25 Apr 2013 04:16:32 -0700 (PDT) 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.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ZetlsSgUHsyy for ; Thu, 25 Apr 2013 04:16:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5153421F84E2 for ; Thu, 25 Apr 2013 04:16:31 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-f5-5179108e564b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 36.A2.03253.E8019715; Thu, 25 Apr 2013 13:16:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:16:29 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the offer, what happens? Thread-Index: Ac5BpI+q5+GuQrBOQqWqGu5HQN4kLQ== Date: Thu, 25 Apr 2013 11:16:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F204@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvrW6fQGWgwbYzshZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuIzHawFX7grHv3JbWA8w93FyMkhIWAiseT2ZTYIW0ziwr31 QDYXh5DAYUaJdQ9XsEM4SxglNj9+DORwcLAJWEh0/9MGaRARUJf4ureHGaRGWKCdUaLvwBsm iEQHo0TrZCcIW0/ix9RFLCA2i4CqRNOJN4wgNq+Ar8Sy64uYQWxGoM3fT60B62UWEJe49WQ+ E8RFAhJL9pxnhrBFJV4+/scKYStKXJ2+nAnkHmYBTYn1u/QhWhUlpnQ/ZIcYLyhxcuYTlgmM wrOQTJ2F0DELSccsJB0LGFlWMbLnJmbmpJebb2IEhvDBLb8NdjBuui92iFGag0VJnFeOrTJQ SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NAxBcBDp7nSy+X6M9dyLZT7GJre9yctTaGBfPi 7Dz4LTa1Nay0flPLt293c+h9Y7XEfWz58j/fVDOeMJy7Nf3HT3vBbdfbHjNKam7XV1b7NLEr feqb1COL0uckPn0+g5FVKF3gbkJAjeaJTXr+Ckb1qvfuc+/Y9ngC78HAxht3Y1/dyTNUf6zE UpyRaKjFXFScCACTlz01LwIAAA== Subject: Re: [MMUSIC] 10 BUNDLE questions: If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the offer, what happens? 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, 25 Apr 2013 11:16:32 -0000 SGksDQoNCj43LiBJZiB0aGUgQlVORExFIG1pZHMgaW4gdGhlIGFuc3dlciBkb2Vzbid0IG1hdGNo IHRoZSBCVU5ETEUgbWlkcyBpbiB0aGUgb2ZmZXIsIHdoYXQgaGFwcGVucz8NCg0KQ29uY2x1c2lv bjogQXMgcGVvcGxlIGhhdmUgYmVlbiBpbmRpY2F0ZWQsIGl0IHdvdWxkIHZpb2xhdGUgdGhlIHJ1 bGVzIGluIHNlY3Rpb24gOS4xIG9mIFJGQyA1ODg4IChzZWUgYmVsb3cpLCBzbyBpdCBpcyBjb25z aWRlcmVkIGEgZmFpbHVyZS4NCg0KICAgIlRoZSAibWlkIiBhdHRyaWJ1dGUgaXMgYW4gaWRlbnRp ZmllciBmb3IgYSBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVhbS4NCiAgIFRoZXJlZm9yZSwgdGhlICJt aWQiIHZhbHVlIGluIHRoZSBvZmZlciBNVVNUIGJlIHRoZSBzYW1lIGFzIHRoZSAibWlkIg0KICAg dmFsdWUgaW4gdGhlIGFuc3dlci4iDQoNClBhdWwgYXNrZWQgd2hldGhlciB3ZSBuZWVkIHRvIHNh eSBzb21ldGhpbmcgYWJvdXQgd2hhdCB0aGUgb2ZmZXJlciBzaG91bGQgZG8gaW4gdGhpcyBjYXNl LiBCdXQsIHBlcnNvbmFsbHkgSSB0aGluayBpdCBpcyBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4gUkZD IDU4ODggZG9lcyBub3Qgc2F5IGhvdyB0byBoYW5kbGUgdGhlc2Uga2luZCBvZiBjYXNlcyBlaXRo ZXIsIHNvLi4uDQoNCkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgQlVORExFIGlzIGEgZ2VuZXJpYyBt ZWNoYW5pc20sIGJ1dCBpZiBXM0Mgd2FudHMgdG8gZGVzY3JpYmUgd2hhdCBhIGJyb3dzZXIgc2hh bGwgZG8gaW4gdGhpcyBjYXNlLCB0aGF0J3MgYSBzZXBhcmF0ZSBzdG9yeS4NCg0KRHJhZnQgaW1w YWN0OiBJIHN1Z2dlc3QgdG8gYWRkIGEgbm90ZSBzYXlpbmcgdGhhdCwgYXMgZGVmaW5lZCBpbiBS RkMgNTg4OCwgdGhlIG1pZCB2YWx1ZXMgaW4gdGhlIFNEUCBhbnN3ZXIgYXJlIHJlcXVpcmVkIHRv IG1hdGNoIHRoZSB2YWx1ZXMgaW4gdGhlIGFzc29jaWF0ZWQgU0RQIG9mZmVyLg0KDQpQbGVhc2Ug aW5kaWNhdGUgaWYgeW91IE9CSkVDVCB0byB0aGUgY29uY2x1c2lvbiwgYW5kL29yIGlmIHlvdSBE TyBOT1QgdGhpbmsgd2UgbmVlZCB0byBzYXkgYW55dGhpbmcgYWJvdXQgdGhpcyBpbiB0aGUgZHJh ZnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From christer.holmberg@ericsson.com Thu Apr 25 04:21: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 DCFED21F8F01 for ; Thu, 25 Apr 2013 04:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 YE42oHAm5HDT for ; Thu, 25 Apr 2013 04:21:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15B21F9552 for ; Thu, 25 Apr 2013 04:21:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-a8-517911a453c1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 53.22.19728.4A119715; Thu, 25 Apr 2013 13:21:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:21:07 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: New version of BUNDLE coming up - what are the editorial changes YOU would like to see? Thread-Index: Ac5BpvrYT47HjLPCRQ+CbS/YlTBsqA== Date: Thu, 25 Apr 2013 11:21:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F216@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C35F216ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre4SwcpAgwd3RCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIntq9gL5spVdM4Ra2C8K9XFyMkhIWAicfLYbnYIW0ziwr31 bF2MXBxCAocZJc7NmMsI4SxhlLg4dyOQw8HBJmAh0f1PG6RBREBd4uveHmYQW1ggSeL68vuM EPF0iX13j7JC2HoSL9cuArNZBFQlVt96wAZi8wr4Stx+1Aq2mBFo8fdTa5hAbGYBcYlbT+Yz QRwkILFkz3lmCFtU4uXjf6wQtqLE1enLoerzJS4decQOMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUje25iZk56udEmRmDQH9zyW3UH451zIocY pTlYlMR5ZdkqA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwLti+U1xSKH+i9ecFwmldjWzN d9iy13y/rCC/yeNE06wVa3Tvu/FWCyxdfkHV7clto1Pr+KetveAl8ktRIv/bG7mAvy8S2Q59 65n7LzLW4dmxJUqHjuRuZcs9OPOf+ebTCn+cRI66sSbn2zKfebXWI+2F6eUzX5LX2j6+FBn/ 4vhrBb4P+cbrfiqxFGckGmoxFxUnAgDtfy23SAIAAA== Subject: [MMUSIC] New version of BUNDLE coming up - what are the editorial changes YOU would like to see? 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, 25 Apr 2013 11:21:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C35F216ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I intend to submit a new version of draft-bundle during next week. If there are any PURE EDITORIAL changes/fixes/clarifications that you would= like to see, please post them to the list. In case of modifying existing text, I suggest to use the following format: OLD TEXT: NEW TEXT: People are also welcome to suggest TECHNICAL changes, assuming that the com= munity has agreed to those changes :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C35F216ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I intend to submit a new version of draft-bundle dur= ing next week.

 

If there are any PURE EDITORIAL changes/fixes/clarif= ications that you would like to see, please post them to the list.

 

In case of modifying existing text, I suggest to use= the following format:

 

OLD TEXT:

 

<Existing section/paragraph>

 

NEW TEXT:

 

<New section/paragraph>

 

People are also welcome to suggest TECHNICAL changes= , assuming that the community has agreed to those changes :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C35F216ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Apr 25 04:47: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 71C2221F94FD for ; Thu, 25 Apr 2013 04:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 9bNdbrbwcEQm for ; Thu, 25 Apr 2013 04:47:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12121F94E1 for ; Thu, 25 Apr 2013 04:47:25 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-fc-517917ca9c34 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7A.B6.03253.AC719715; Thu, 25 Apr 2013 13:47:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:47:22 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing? Thread-Index: Ac5BpmyBUXNlqyHMTIaLMfqqjmqBZQ== Date: Thu, 25 Apr 2013 11:47:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F2C0@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvre5p8cpAg+lnWCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO2PutkLpghVfH/xi7WB8YZgFyMnh4SAicTqTRdYIGwxiQv3 1rN1MXJxCAkcZpR4Me8BO4SzhFFi16ENQA4HB5uAhUT3P22QBhEBdYmve3uYQWqEBRoZJZYs uc0K4ogINDFKvDzZwwJRpScxf/tbdhCbRUBVonX6K2YQm1fAV+LqpBOsIDYj0Orvp9YwgdjM AuISt57MZ4I4SUBiyZ7zzBC2qMTLx/9YIWxFiavTlzOBHMQsoCmxfpc+RKuixJTuh+wQ4wUl Ts58wjKBUXgWkqmzEDpmIemYhaRjASPLKkb23MTMnPRy802MwDA+uOW3wQ7GTffFDjFKc7Ao ifNuB4a3kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsY1j3IKtNrrhDun+rDE8092Zkv46z7p mVhY3vTVjcGSFu+nVTzWSFg3Iznf8H1vZ2umiknE/HP+LtsYKuYULbpwIP7/bCaWv0tmLzuc d4uvr24n69xpvnO9Zl5bMO2OxdyZmsH/X6TtTGsovPZ+067gms0lK/Y84WVwPVyXKZufHJA9 /4NL3xQlluKMREMt5qLiRADHDrziMQIAAA== Subject: Re: [MMUSIC] 10 BUNDLE questions: If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing? 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, 25 Apr 2013 11:47:26 -0000 SGksDQoNCj4gOC4gSWYgeW91IGFkZCBhIG09IGxpbmUgdG8gYW4gZXhpc3RpbmcgQlVORExFLCBj YW4gdGhlIHJlY2lwaWVudCByZWplY3QgdGhhdCBCVU5ETEVpbmcNCg0KUGF1bCB3cm90ZSB0aGUg Zm9sbG93aW5nOg0KDQogICAgICJJZiB0aGUgY2hhbmdlIHdhcyB0byBhZGQgYSBuZXcgbS1saW5l LCB0aGF0IHByZXZpb3VzbHkgd2FzIG5vdCBwcmVzZW50LCB0byB0aGUgU0RQICphbmQqIHRvIHRo ZSBidW5kbGUsIHRoZW4gYW5zd2VyZXIgY291bGQgcG90ZW50aWFsbHkgZWl0aGVyOg0KDQogICAg IDEpIGFjY2VwdCB0aGUgbS1saW5lIChub24temVybyBwb3J0KSBhbmQgYWNjZXB0IHRoZSBidW5k bGluZw0KICAgICAobWF0Y2hpbmcgbWlkLWxpbmUgdG8gd2hhdCB3YXMgaW4gdGhlIG9mZmVyKSIN Cg0KT2suDQoNCiAgICAgIjIpIGFjY2VwdCB0aGUgbS1saW5lIGFuZCByZWplY3QgdGhlIGJ1bmRs aW5nIChtaWQgdmFsdWUNCiAgICAgZm9yIHRoZSByZWplY3RlZCBtLWxpbmUgb21pdHRlZCBmcm9t IHRoZSBidW5kbGUgZ3JvdXApDQoNCiAgICAgMykgcmVqZWN0IHRoZSBtLWxpbmUgKHplcm8gcG9y dCkgYW5kIHJlamVjdCB0aGUgYnVuZGxpbmcuIEZvciBiZXR0ZXINCiAgICAgb3Igd29yc2UsIFJG QzU4ODggcmVxdWlyZXMgdGhpcyBiZWhhdmlvciBpbiB0aGUgZ3JvdXAgbGluZSBmb3INCiAgICAg cmVqZWN0ZWQgbS1saW5lcy4iDQoNCjIpIGFuZCAzKSBhc3N1bWUgdGhhdCB3ZSBkb24ndCByZXF1 aXJlLCBmb3IgYW55IGdpdmVuIGJ1bmRsZSwgdGhhdCB0aGUgbnVtYmVyIG9mIG0tIGxpbmVzIGlu IFNEUCBhbnN3ZXIgbWF0Y2hlcyB0aGUgbnVtYmVyIG9mIG0tIGxpbmVzIGluIHRoZSBhc3NvY2lh dGVkIFNEUCBvZmZlci4gDQoNCkEgZm91cnRoIG9wdGlvbiB3b3VsZCBiZToNCg0KICAgICA0KSBy ZWplY3QgdGhlIG0tbGluZSAoemVybyBwb3J0KSBhbmQgYWNjZXB0IHRoZSBidW5kbGluZy4gDQoN CkJ1dCwgYXMgUGF1bCBpbmRpY2F0ZWQsIFJGQyA1ODg4IGRvZXMgbm90IGFsbG93IHRoaXMsIHNp bmNlIGl0IHdvdWxkIG1lYW4gaGF2aW5nIGEgbWlkIHZhbHVlIGZvciBhbiBtLSBsaW5lIHdpdGgg YSB6ZXJvIHBvcnQgdmFsdWUuDQoNCg0KQSBmaWZ0aCBvcHRpb24gd291bGQgYmU6DQoNCiAgICA1 KSByZWplY3QgdGhlIG0tbGluZSAoemVybyBwb3J0KSBhbmQgUkVNT1ZFIHRoZSB3aG9sZSBCVU5E TEUgZ3JvdXAgaW4gd2hpY2ggdGhlIG0tIGxpbmUgd2FzIG9mZmVyZWQuDQoNClRoaXMgc2hvdWxk IG9mIGNvdXJzZSBiZSBhdm9pZGVkLCBhcyB0aGUgYW5zd2VyZXIgd291bGQgaGF2ZSB0byBhc3Np Z24gbmV3IGluZGl2aWR1YWwgcG9ydCBsaW5lcyBmb3IgZWFjaCBtLSBsaW5lIHRoYXQgd2FzIHBy ZXZpb3VzbHkgcGFydCBvZiB0aGUgQlVORExFIGdyb3VwLiBCdXQsIG5ldmVyIHRoZSBsZXNzLCBh c3N1bWluZyB3ZSBhbGxvdyAiZGVCVU5ETElORyIsIGl0IHdvdWxkbid0IGJlIGZvcmJpZGRlbiA6 KQ0KDQpJIHRoaW5rIHdlIG5lZWQgYSBsaXR0bGUgbW9yZSB0aW1lIHRvIHRoaW5rIGFib3V0IHRo aXMgYWxzbywgc28gSSB3aWxsIGxpc3QgaXQgYXMgYW4gT1BFTiBJU1NVRS4gVGhlIG91dGNvbWUg bWlnaHQgYWxzbyBiZSBkZXBlbmRlbnQgb24gd2hldGhlciB3ZSBlLmcuIGFyZSBnb2luZyB0byB1 cGRhdGUgUkZDIDU4ODguDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From christer.holmberg@ericsson.com Thu Apr 25 04:59: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 5C3CE21F8746 for ; Thu, 25 Apr 2013 04:59:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvN0SKK02Y7B for ; Thu, 25 Apr 2013 04:59:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2A721F85C0 for ; Thu, 25 Apr 2013 04:59:26 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-d5-51791a9dbd16 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.28.03253.D9A19715; Thu, 25 Apr 2013 13:59:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 13:59:24 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: If m= lines are rejected, should their mids show up in the BUNDLE answer? Thread-Index: Ac5Bq1jh2eCuU35HTICY4R5IfzHliA== Date: Thu, 25 Apr 2013 11:59:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F2E0@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre5cqcpAg+1H1SymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ5z85gLpnBUTHt4mb2B8Qd7FyMnh4SAicShBb1QtpjEhXvr 2boYuTiEBA4zSjxfdYgJwlnCKNGy7h5LFyMHB5uAhUT3P22QBhEBdYmve3uYQWxhgTKJ3Tcf MEPEyyWOnZkJZetJ9PzaCWazCKhK9J+aywwyhlfAV2L9xXiQMCPQ3u+n1jCB2MwC4hK3nsxn grhHQGLJnvPMELaoxMvH/1ghbEWJq9OXM4GMYRbQlFi/Sx+iVVFiSvdDsFd4BQQlTs58wjKB UXgWkqmzEDpmIemYhaRjASPLKkb23MTMnPRy802MwAA+uOW3wQ7GTffFDjFKc7AoifPaAwNb SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NA2+G5n6wfT5m5y9mHgcXa7oC3APNr1VQhlw0h fKKiYffZ2vrWVJebGKltr7t6roAx9FaEloTSis32iw49VshX5e5anv1KIXdx1QXn777/p/Gf EHaI/Oudf/zhAp7+MHc7JYuDk1LvXT2xrOvDho3buzt/e/6TaeFzC39+pSAp8P5q85pZqUos xRmJhlrMRcWJACdmvd8uAgAA Subject: Re: [MMUSIC] 10 BUNDLE questions: If m= lines are rejected, should their mids show up in the BUNDLE answer? 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, 25 Apr 2013 11:59:27 -0000 SGksDQoNCj45LiBJZiBtPSBsaW5lcyBhcmUgcmVqZWN0ZWQsIHNob3VsZCB0aGVpciBtaWRzIHNo b3cgdXAgaW4gdGhlIEJVTkRMRSBhbnN3ZXI/IChhc3N1bWUgeWVzPykNCg0KQXMgaGFzIGJlZW4g aW5kaWNhdGVkLCBSRkMgNTg4OCBkb2VzIG5vdCBjdXJyZW50bHkgYWxsb3cgaXQuDQoNCj4xLiBJ ZiBub3QsIGhvdyBkb2VzIHJlbW90ZSBzaWRlIGluZGljYXRlIEJVTkRMRSBzdXBwb3J0IGlmIGl0 IHJlamVjdHMgdGhlIG09IGxpbmVzIHRoYXQgYXJlIEJVTkRMRWQ/DQoNCkFzIHdhcyBpbmRpY2F0 ZWQsIG9uZSB3YXkgd291bGQgYmUgdG8gcmV0dXJuIGVuICJlbXB0eSIgQlVORExFIGdyb3VwIGF0 dHJpYnV0ZSwgd2l0aG91dCBhbnkgbWlkICh0aGUgUkZDIDU4ODggQUJORiBhbGxvd3MgaXQpLg0K DQpGb3Igbm93LCBJIHdpbGwga2VlcCB0aGlzIGFzIGFuIE9QRU4gSVNTVUUsIGFzIHRoZSBvdXRj b21lIG1pZ2h0IGJlIGRlcGVuZGVudCBvbiB3aGV0aGVyIHdlIGFyZSBnb2luZyB0byB1cGRhdGUg UkZDIDU4ODguDQoNCk5PVEUgdGhhdCBJIGFtIGN1cnJlbnRseSBOT1Qgc3VnZ2VzdGluZyB0aGF0 IHdlIHNob3VsZCB1cGRhdGUgUkZDIDU4ODguIEJ1dCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHRo aW5ncyB3aGljaCBjb3VsZCBiZSBzb2x2ZWQgdGhhdCB3YXksIHNvIEkgd2FudCB0byBtYWtlIHN1 cmUgd2UgZmluZCBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMgZm9yIGFsbCBpc3N1ZXMgOikNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg== From christer.holmberg@ericsson.com Thu Apr 25 07: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 AFCA921F961A for ; Thu, 25 Apr 2013 07:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ygkMxNs9-xRk for ; Thu, 25 Apr 2013 07:04:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9421F960F for ; Thu, 25 Apr 2013 07:03:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-74-517937cea8d6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AB.C6.10459.EC739715; Thu, 25 Apr 2013 16:03:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 16:03:57 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions Thread-Index: Ac5BtetQA/tOGLtGSMCPJoJAl/DbRg== Date: Thu, 25 Apr 2013 14:03:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F453@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre4588pAg4dHVCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGdXOxgLPghU7H+9hbWBcYdAFyMnh4SAiUT39c9MELaYxIV7 69m6GLk4hAQOM0p0rbsPlhASWMIoMe8ufxcjBwebgIVE9z9tkLCIgLrE1709zCC2sICPxNqX u9gh4r4SPec7GCFsPYmzp3aBjWERUJXoWfsYrIYXqOb8h92sIDYj0N7vp9aA1TALiEvcejIf 6h4BiSV7zjND2KISLx//Y4WwFSWuTl/OBHIOs4CmxPpd+hCtihJTuh9CjReUODnzCcsERuFZ SKbOQuiYhaRjFpKOBYwsqxjZcxMzc9LLDTcxAgP44JbfujsYT50TOcQozcGiJM47XaoyUEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj5EebW+Vlqtq/phd+U1n072D/sQVX156+U92arjdz dc38arHt7q4aKSYvJthsPrHLsnBW5SvbBy84jQMk83Mu7T2744WoT5+x6OGd259qPN+1y01t QY/h16S5v44X9M10qVqYpD5ze3fiNudWEb+654e7HBsKl9y/lL/uyL+A/Q8XLFDWruJ+psRS nJFoqMVcVJwIACzsmxUuAgAA Subject: Re: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions 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, 25 Apr 2013 14:04:00 -0000 SGksDQoNCj40LiBGcm9tIDYuMSwgbGlzdCAxIC0gYXJlIGNvbmRpdGlvbnMgMiwgNSwgNyByZWFs bHkgbmVjZXNzYXJ5PyAoTVVTVCB1c2Ugc2FtZSBjPSwgYWRkIHJ0Y3AtbXV4LCBzYW1lIGE9Zmlu Z2VycHJpbnQpDQoNClRoZXJlIHdlcmUgc29tZSBxdWVzdGlvbnMgb24gd2h5IHdlIGhhdmUgY2Vy dGFpbiByZXN0cmljdGlvbnMgaW4gbGlzdCAxLCBhcyB2YWx1ZXMgY2FuIGJlICJzb3J0ZWQgb3V0 IiBpbiB0aGUgc2Vjb25kIG9mZmVyICh3aGVyZSBsaXN0IDIgYXBwbGllcykuDQoNClJlZ2FyZGlu ZyB0aGUgc2FtZSBjPSwgaWYgc29tZW9uZSByZWFsbHkgc2VlcyBhIG5lZWQgZm9yIHNlbmRpbmcg dGhlIGZpcnN0IG9mZmVyIHdpdGggZGlmZmVyZW50IHZhbHVlcywgSSBndWVzcyB3ZSBjb3VsZCBk aXNjdXNzIGl0LiBNeSBzdWdnZXN0aW9uIGlzIHRvIGtlZXAgdGhlIHJlc3RyaWN0aW9uIGluIGxp c3QgMS4gQnV0LCBpZiBzb21lb25lIE9CSkVDVFMgdG8gdGhpcywgcGxlYXNlIGluZGljYXRlIHNv Lg0KDQpSZWdhcmRpbmcgImE9cnRjcC1tdXgiLCBteSBzdWdnZXN0aW9uIGlzIHRoYXQgd2Ugc2hv dWxkIG1hbmRhdGUgaXQgZm9yIEJVTkRMRSwgYW5kIEkgaGF2ZSBoZWFyZCBvdGhlcnMgc2F5aW5n IHRoZSBzYW1lLiBCdXQsIGlmIHNvbWVvbmUgT0JKRUNUUyB0byB0aGlzLCBwbGVhc2UgaW5kaWNh dGUgc28uDQoNClJlZ2FyZGluZyAiYT1maW5nZXJwcmludCIsIHRoZSBvcGluaW9uIHNlZW1zIHRv IGJlIHRoYXQgdGhlcmUgd291bGQgYmUgbm8gaWRlYSB1c2luZyBkaWZmZXJlbnQgdmFsdWVzLiBC dXQsIGlmIHNvbWVvbmUgT0JKRUNUUyB0byB0aGlzLCBwbGVhc2UgaW5kaWNhdGUgc28uDQoNCg0K PjUuIEZyb20gNi4xLCBsaXN0IDIgLSBpcyBjb25kaXRpb24gNiByaWdodD8gV2h5IHdvdWxkIHdl IHVzZSBkaWZmZXJlbnQgU0RFUyBrZXlzIGZvciBhIHNpbmdsZSBSVFAgc2Vzc2lvbj8NCg0KQXMg cGVvcGxlIGhhdmUgaW5kaWNhdGVkLCBpdCBwcmV2ZW50cyBhIHR3by10aW1lIHBhZCBhdHRhY2ss IGFuZCB0aGF0IGlzIGFsc28gdGhlIG9ubHkgcmVhc29uIEkgY2FuIHRoaW5rIG9mLiBNeSBzdWdn ZXN0aW9uIGlzIHRvIGtlZXAgdGhlIHJlc3RyaWN0aW9uIGluIGxpc3QgMSBhbmQgMi4gQnV0LCBp ZiBzb21lb25lIE9CSkVDVFMgdG8gdGhpcywgcGxlYXNlIGluZGljYXRlIHNvLg0KDQoNCj4gNi4g SWYgeW91IHN0YXJ0IHdpdGggYSBtPSBsaW5lIHdpdGggb25lIFNERVMgY29uZmlnIChlLmcuIDMy LWJpdCBNQUMpLCBhbmQgdGhlbiBCVU5ETEUgd2l0aCBhbm90aGVyIFNERVMgbGluZSB3aXRoIGEg ZGlmZmVyZW50IChub24gb3ZlcmxhcHBpbmcpIFNERVMgY29uZmlnIChlLmcuIDgwLWJpdCBNQUMp LCB3aGF0IGhhcHBlbnM/IChhc3N1bWUgZmFpbCkNCg0KUGVvcGxlIGhhdmUgaW5kaWNhdGVkIHRo YXQgdGhpcyB3b3VsZCBiZSBhIGZhaWx1cmUsIGFuZCBJIGhhdmUgc2VlbiBubyBvbmUgaW5kaWNh dGUgb3RoZXJ3aXNlLiBCdXQsIGlmIHNvbWVvbmUgT0JKRUNUUyB0byB0aGlzLCBwbGVhc2UgaW5k aWNhdGUgc28uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From christer.holmberg@ericsson.com Thu Apr 25 07:19: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 8D11F21F91B2 for ; Thu, 25 Apr 2013 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 dR9FGBDCuAtD for ; Thu, 25 Apr 2013 07:19:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 97EDC21F925B for ; Thu, 25 Apr 2013 07:19:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-fd-51793b852e0e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B7.E9.19728.58B39715; Thu, 25 Apr 2013 16:19:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 16:19:49 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: BUNDLE and DATA CHANNEL Thread-Index: Ac5BvnL9Ik6q+PHpSI2jUL+JN2f+Gg== Date: Thu, 25 Apr 2013 14:19:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C35F47A@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+NgFlrOLMWRmVeSWpSXmKPExsUyM+JvrW6rdWWgwacjRhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRt3cSS8EKnopDz54zNTBe5uxi5OSQEDCR uNf4kx3CFpO4cG89WxcjF4eQwGFGidnnDrGBJIQEljBKbDin0MXIwcEmYCHR/U8bJCwi4Cvx 7PFtsBJhAQWJW79OskPEVSXmbOtihrD1JC50TQarYQGKt/1+DmbzAvXOPvkZrJ4RaO/3U2uY QGxmAXGJW0/mM0HcIyCxZM95ZghbVOLl43+sELaixNXpy6HqdSQW7P7EBmFrSyxb+JoZYr6g xMmZT1gmMArPQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93GgTIzCwD275rbqD8c45kUOM0hws SuK8M6QqA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw9ga7vSgy4Ju2YbOChLzQxrlH9p2J uJ05+V5otV/b0TPP13/8LxyUbnr38uXIuk/1W0ryLmSd5JQycznud57zTiobp+ukuPv3zCY3 15cYcr80Dz3duuCfgNJ1m/9TlJVf7EjgCXcpuCVxLDX7AteJwp0bBBs9VDd1PVTpefGws1xx opU5c9VfJZbijERDLeai4kQAzBXptjoCAAA= Subject: [MMUSIC] BUNDLE and DATA CHANNEL 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, 25 Apr 2013 14:19:51 -0000 [Was: [MMUSIC] Comment on Payload type restriction in draft-ietf-mmusic-sdp= -bundle-negotiation-03] Hi, > - the draft doesn't currently talk at all about including the > m-line for the SCTP association for data channels in the bundle, > but people expect it. There is a special mechanism for demuxing > those packets from RTP. But that mechanism is limited to SCTP > over DTLS. And it is limited to a single SCTP association in the > bundle. That is for sure text that needs to be added - assuming we have a WG decisi= on that we are going to do it. Or, does someone think we only need to care = about RTP (as far as BUNDLE is concerned) at this point? >ISTM that there must be specification of: >- the demux mechanisms that are available, >- how they work, >- how they do or don't coexist with one another, >- and how they are signaled in SDP. > > The list of available demux mechanisms may need to be extensible. > And the bundle mechanism should be designed to accommodate that. Yes. Whenever someone wants to add a new transport to BUNDLE, he/she needs = to describe how the multiplexing with other transports is done, i.e. fill o= ut the bullet list above. BUT, does that mean that we need a signalling mechanism where a BUNDLE clie= nt inform which demux mechanisms it supports? Example: a=3Dmux_transports: RTP, DTLS-SCTP In future, someone may specify how to add MSRP to BUNDLE, and how to mux it= with DTLS-SCRTP and RTP: Example: a=3Dmux_transports: RTP, DTLS-SCTP, MSRP Regards, Christer From fandreas@cisco.com Thu Apr 25 09:16: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 905F221F868B for ; Thu, 25 Apr 2013 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 17LM44jbKr9C for ; Thu, 25 Apr 2013 09:16:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8910B21F85E8 for ; Thu, 25 Apr 2013 09:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21869; q=dns/txt; s=iport; t=1366906573; x=1368116173; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lomBWvhY6Kme87bI58KNN5A/SA6DtoBbLlz4dK8B4Lg=; b=bbNyqOtYgOwmX/U5jitnjU0a/thO8y1gxrDPzV3YG2A82/pdF17U7sps HKnZkcBjUgd8GXJHFOWsysDJt/MIBUTzjDP6k8Wn+Sc90C7BywwU1hSjA 2GDhY6YgZv5sQyqMuoA+YIP+BiG8NORtomlRfS37464DI4xl8kAYiZMyY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJFWeVGtJXHB/2dsb2JhbABRgwY2vi6BBBZ0gh8BAQEDAQEBARcYAQU0AggCAQUHBAsRBAEBAQkWBAQHCQMCAQIBFR8JCBMBBQIBAQUSh3MGDL5SjX0GgTIHBoNIA5ccgSWPfYFYgVIggS4JFw X-IronPort-AV: E=Sophos;i="4.87,551,1363132800"; d="scan'208";a="203047630" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Apr 2013 16:16:12 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3PGGBbC027613; Thu, 25 Apr 2013 16:16:11 GMT Message-ID: <517956CB.2040701@cisco.com> Date: Thu, 25 Apr 2013 12:16:11 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 25 Apr 2013 16:16:15 -0000 On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com wrote: > Below the original and proposed text on the usage of ccap attribute in Section 3.1.2. of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > This is pretty much the same text I proposed earlier, including Jonathan's wording on IN address families. > > --- begin original text --- > The 'ccap' capability attribute allows for expressing alternative > connection address ('c=') lines in SDP as part of the SDP capability > negotiation process. The 'ccap' capability attribute is intended to > be used only when there is no other mechanism available for > negotiating alternative connection address information, such as when > the is different among the alternative addresses (e.g. > "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in > situations where an existing mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245]) can be used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). > --- end original text --- > > --- begin proposed text --- > The 'ccap' capability attribute is intended for offering > alternative connection addresses where the > is "IN" or "PSTN", i.e. selecting between an IP based > bearer or a circuit-switched bearer. > > The 'ccap' attribute MUST NOT be used to indicate more > than one address with an IN network type in actual > or potential configurations for any given media description > (e.g. between "IP4" and "IP6" address families or different > IP addresses within the same IP address family). > --- end proposed text--- I'm ok with the overall restriction but I think the opening wording is overly constraining. With that in mind, a slightly modified proposal below: The 'ccap' capability attribute allows for expressing alternative connection address ('c=') lines in SDP as part of the SDP capability negotiation process. One of the primary use cases for this is offering alternative connection addresses where the is "IN" or "PSTN", i.e., selecting between an IP based bearer or a circuit-switched bearer. By supporting the "IN" , the 'ccap' attribute enables the signaling of multiple IPv4 and IPv6 addresses, however the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change that and hence the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the 'ccap' attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IP4" and "IP6" address families or different IP addresses within the same IP address family). > > Also, since no alternative port numbers can be offered, add this sentence at the end the of the last paragraph to clarify how alternative IP and PSTN media descriptions are offered: > > This document does not define any mechanism for negotiating or > describing different port numbers and hence the port number from the > "m=" line MUST be used by default. Exceptions to this default can be > provided by extension mechanisms or network type specific rules. > This draft defines an exception when the network type is "PSTN", in > which case the port number is replaced with 9 (the "discard" port) as > described in Session Decription Protocol (SDP) Extension For Setting > Up Audio and Video Media Streams over Circuit-Switched Bearers in the > Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. > --- begin new text --- > An endpoint offering alternative IP and PSTN bearers MUST include the > IP media description in the actual configuration (IP address in the "c=" line > and port number in the "m=" line), and the PSTN media descriptions in the > potential configuration. > --- end new text --- Looks good. Thanks -- Flemming > Regards, > Simo > > > -----Original Message----- > From: ext Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 17. huhtikuuta 2013 17:33 > To: mohamed.boucadair@orange.com > Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com; HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: >> Hi Felmming, >> >> Because it does not allow to indicate an alternate port number. > Correct - a connection address does not provide a port number; a different capability would be needed for that. >> This makes it a no working solution for various scenarios. > No - it simply means that you would need to define another capability to convey port numbers if you wanted such a solution (however we have ICE as the complete solution for that and the WG has not indicated a desire to change that). > >> The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread. > I have asked Simo to update the draft. > > Thanks > > -- Flemming > > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoyé : samedi >>> 13 avril 2013 02:40 À : BOUCADAIR Mohamed OLNC/OLN Cc : >>> Simo.Veikkolainen@nokia.com; aallen@blackberry.com; >>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; >>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data >>> Capability (ccap) and IP-addresses >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> >>> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Simo, >>>> >>>> I'm in favor of restricting the alternative address to PSTN. >>> Can you elaborate on why ? >>> >>> We have defined a generic connection data capability as part of a >>> general capability negotiation framework. What's the point of that if >>> the only value it can convey is PSTN ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> This is coherent whit your first bullet below. >>>> >>>> If you share the text changes you are proposing, this would be more >>> easier to review. >>>> Thanks for taking care of this issue. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la >>>>> part >>> de >>>>> Simo.Veikkolainen@nokia.com >>>>> Envoyé : lundi 8 avril 2013 08:35 >>>>> À : fandreas@cisco.com; aallen@blackberry.com; >>>>> HKaplan@acmepacket.com Cc : jonathan@vidyo.com; mmusic@ietf.org; >>>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data >>>>> Capability (ccap) and IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Recapping the discussion so far: >>>>> >>>>> >>>>> - ICE is the way to negotiate between different IP addresses. There >>> seems >>>>> to be no disagreement here. >>>>> >>>>> - since no alternative port number can be expressed, in practice >>>>> the IN address needs to go to the actual configuration (address in >>>>> the c= line >>> and >>>>> port number in the m= line), and the alternative PSTN address in >>>>> the potential configurations. Also here, there seems to be no disagreement. >>>>> >>>>> - then, whether the "ccap" attribute should be limited to carry >>>>> only >>> PSTN >>>>> addresses, or also other types. I'm with Flemming on this one; SDP >>> capneg >>>>> framework is already fragmented enough, and limiting the connection >>> address >>>>> capability to PSTN addresses only would again be targeted for a >>>>> single >>> use >>>>> case only, whereas we should strive for general solutions. >>>>> >>>>> Simo >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> ext Flemming Andreasen >>>>> Sent: 25. maaliskuuta 2013 3:32 >>>>> To: Andrew Allen >>>>> Cc: jonathan@vidyo.com; mmusic@ietf.org; >>>>> christer.holmberg@ericsson.com >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and >>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> >>>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>>> There is also nothing that prevents people from defining their own >>>>> proprietary attributes to do such a thing but that is not part of >>>>> an >>> IETF >>>>> standard and is not approved usage. >>>>> Agreed. >>>>> >>>>>> If we really feel the need to discourage further such usage I >>>>>> suppose >>> we >>>>> could add some text stating that if CCAP s received containing an >>>>> IN net type and an IN net type is present in the corresponding >>>>> Connection Attribute then the CCAP attribute MUST be ignored. >>>>> I think that gets complicated quickly for a questionable gain. I'd >>>>> prefer the "MUST NOT" described below with an explanation as to why >>>>> it's there; as you note, ultimately people either decide to be spec >>>>> compliant or not. >>>>> >>>>> -- Flemming >>>>>> That way compliant implementations would not perfom the >>>>>> discouraged >>>>> behavior. >>>>>> Andrew >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>>> To: Christer Holmberg >>>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>>> >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In general I agree that having multiple ways of doing the same >>>>>>> thing >>> is >>>>> not a good thing, and I don't have any strong feelings regarding >>>>> the >>> ccap >>>>> usage. >>>>>>> But, no matter what we say, what would actually prevent people >>>>>>> from >>>>> using ccap, in the same way they are using ANAT and altc? :) >>>>>> There's no port signaling capability with ccap, but other than >>>>>> that, >>> the >>>>>> only thing that prevents people from using this to signal >>>>>> alternative IP-addresses is the existence of a "MUST NOT" in the spec. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf >>>>>>> of >>>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>>> To: Flemming Andreasen >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> Currently, the deployed SIP world has three mechanisms to allow >>>>>>> some >>>>> flavor of negotiation among multiple IP addresses: ICE, altc >>>>> (despite >>> the >>>>> general disapproval of the working group), and ANAT (despite its >>>>> deprecation). >>>>>>> I think that adding ccap as a fourth member of this set would be >>>>>>> a >>>>> terrible idea; and as far as I can tell, no one wants to do that. >>>>> So we need to make it clear that that it MUST NOT be used for that purpose. >>>>>>> In the formulation below, I think I'd say that a given media >>> description >>>>> MUST NOT indicate more than one address with an IN network type, >>>>> across >>> all >>>>> its configurations (actual and potential). >>>>>>> Obviously, different media descriptions (m= line blocks) can have >>>>> different addresses. >>>>>>> In practice, given the port number issue that started this >>>>>>> thread, I >>>>> suspect this means that the SDP offer will need to put the IN >>>>> address in the actual configuration (in the c= line), and the PSTN >>>>> address(es) will >>> be >>>>> in the potential configurations. >>>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> Still waiting for more comments on this, especially from the >>>>>>>> people >>>>> that >>>>>>>> were very vocal in their complaints previously: Now is the time >>>>>>>> to >>>>> speak up. >>>>>>>> Regardless, a few comments on the below: >>>>>>>> 1) It allows the use of "ccap" to be used to indicate one or >>>>>>>> more >>> "IP4" >>>>>>>> addresses in a given SDP. >>>>>>>> 2) It allows the use of "ccap" to be used to indicate one or >>>>>>>> more >>> "IP6" >>>>>>>> addresses in a given SDP. >>>>>>>> >>>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>>> The "ccap" attribute is not what is being to select between >>>>>>>> different IP-addresses; the use of a "ccap" attribute in a >>>>>>>> potential >>>>> configuration >>>>>>>> ("pcfg") is what is being used for this. Is the restriction that >>>>>>>> we >>>>> want >>>>>>>> here: >>>>>>>> a) A potential configuration MUST NOT reference more than one "ccap" >>>>>>>> attribute with a network type of "IN" ? >>>>>>>> b) All potential configurations for a particular media >>>>>>>> description >>> MUST >>>>>>>> NOT reference more than one "ccap" attribute with a network type >>>>>>>> of >>>>> "IN" ? >>>>>>>> c) Something else ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>>> I am OK with either of these proposals >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>>>>> On >>>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> I went through the discussion, and my reading is that there is >>>>> agreement on not allowing ccap to be used for alternative IP >>>>> address negotiation. >>>>>>>>> That could be made clear in the text e.g. by modifying the >>>>>>>>> second >>>>> sentence Flemming quoted to read: >>>>>>>>> >>>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>>> between different IP connection addresses (e.g. between >>>>>>>>> "IP4" and "IP6" address families or different IP addresses >>>>>>>>> within the same IP address family). >>>>>>>>> >>>>>>>>> >>>>>>>>> The ccap attribute should be able to carry either an IP or PSTN >>>>> address; that way either a PSTN or an IP bearer could be offered as >>>>> the highest priority configuration (in the "m=" line). However, if >>>>> we want >>> to >>>>> clarify the intended use of ccap, we could modify the first >>>>> sentence to >>>>> read: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>>> alternative connection addresses where the >>>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>>> bearer or a circuit-switched bearer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Simo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>>>>> On >>>>> Behalf Of ext Flemming Andreasen >>>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>>> To: mmusic >>>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and >>>>>>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> As you may have seen, there has recently been some list >>>>>>>>> discussion >>> on >>>>> the "connection data capability" defined in >>>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.ht >>>>>>>>> ml) >>>>>>>>> >>>>>>>>> To recap, the connection data capability ("ccap") provides >>> capability >>>>> negotiation capabilities for what amounts to the "c=" line in >>>>> regular >>> SDP, >>>>> and as such enables negotiation of network type (such as "IN") and >>>>> IP- address information (v4 and v6 addresses). The Standards Track >>>>> mechanism for negotiating and determining alternative IP-address >>>>> information today >>> is >>>>> ICE, and hence the draft currently includes the following wording: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>>> be used only when there is no other mechanism available for >>>>>>>>> negotiating alternative connection address information, >>>>>>>>> such >>> as >>>>> when >>>>>>>>> the is different among the alternative >>>>>>>>> addresses >>> (e.g. >>>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>>>>>>>> situations where an existing mechanism (such as Interactive >>>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used >>>>>>>>> to >>>>> select >>>>>>>>> between different connection addresses (e.g. "IP4" and "IP6" >>> or >>>>>>>>> different IP addresses within the same IP address family). >>>>>>>>> >>>>>>>>> >>>>>>>>> The above text has led to some confusion as to exactly when and >>>>>>>>> what >>>>> "ccap" can be used for. More specifically, is it/should it ever be >>> allowed >>>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under >>>>> what circumstances ? >>>>>>>>> If you have an opinion, please let us know. >>>>>>>>> >>>>>>>>> A couple of points to keep in mind: >>>>>>>>> - The current document has been WGLC'ed without comment ~6 >>>>>>>>> months >>> ago. >>>>>>>>> - 3GPP has a dependency on the document (however I'm not sure >>>>>>>>> if >>> that >>>>> dependency includes the above "IN" feature) >>>>>>>>> - The connection data capability is defined in a general manner >>>>>>>>> to >>> be >>>>> generally useful in line with the overall capability negotiation >>> framework >>>>> (as opposed to targeted at one specific use case with one specific >>> value) >>>>>>>>> - There are scenarios where ICE cannot be used, even if >>>>>>>>> implemented >>>>> (e.g. ice-mismatch). >>>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >>> absence >>>>> of ICE support >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- 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 >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- >>> - >>>>>>>>> This transmission (including any attachments) may contain >>> confidential >>>>> information, privileged material (including material protected by >>>>> the solicitor-client or other applicable privileges), or constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information >>>>> from your system. Use, dissemination, distribution, or reproduction >>>>> of this transmission by unintended recipients is not authorized and >>>>> may be unlawful. >>>>>>>>> . >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> -- >>>>>>> Jonathan Lennox >>>>>>> jonathan@vidyo.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> --- This transmission (including any attachments) may contain >>>>>> confidential >>>>> information, privileged material (including material protected by >>>>> the solicitor-client or other applicable privileges), or constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information >>>>> from your system. Use, dissemination, distribution, or reproduction >>>>> of this transmission by unintended recipients is not authorized and >>>>> may be unlawful. >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> 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 Apr 25 10:26: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 AD06121F9633 for ; Thu, 25 Apr 2013 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 bsC7znuTxGhE for ; Thu, 25 Apr 2013 10:26:07 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00A21F961C for ; Thu, 25 Apr 2013 10:26:04 -0700 (PDT) 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 r3PHPNbB020156 for ; Thu, 25 Apr 2013 13:25:26 -0400 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 r3PHPNZl3425422 for ; Thu, 25 Apr 2013 13:25:23 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PHPNPu3426177; Thu, 25 Apr 2013 13:25:23 -0400 (EDT) Date: Thu, 25 Apr 2013 13:25:23 -0400 (EDT) Message-Id: <201304251725.r3PHPNPu3426177@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 17:26:08 -0000 Here are two desiderata based on the limitations of existing intermediate devices: 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 [RFC4566]. Some SBCs do not support such duplication (ultimately, because it was not supported by [RFC2327]), and they reject SDP specifying duplicated transport association endpoints. This desideratum was suggested by Cullen Jennings. Dale From worley@shell01.TheWorld.com Thu Apr 25 10:26: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 C996E21F95FB for ; Thu, 25 Apr 2013 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 fuswEkWiEfAE for ; Thu, 25 Apr 2013 10:26:08 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id A78F421F961F for ; Thu, 25 Apr 2013 10:26:05 -0700 (PDT) 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 r3PHPqZL010753 for ; Thu, 25 Apr 2013 13:25:55 -0400 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 r3PHPqGb3427393 for ; Thu, 25 Apr 2013 13:25:52 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PHPqeV3429515; Thu, 25 Apr 2013 13:25:52 -0400 (EDT) Date: Thu, 25 Apr 2013 13:25:52 -0400 (EDT) Message-Id: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 25 Apr 2013 17:26:11 -0000 I was looking at the IANA registry "RTP Payload types (PT) for standard audio and video encodings" (http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-1) to see what the allowed dynamic payload types are, and what PTs are reserved to avoid confusion with RTCP. The unassigned range is: 35-71 Unassigned 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Unassigned 96-127 dynamic [RFC3551] Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data and Control Packets on a Single Port"), which gives these instructions in section 4: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. Since the entire range 64 to 95 is now reserved, the table should read: 35-63 Unassigned 64-71 Reserved for RTCP conflict avoidance [RFC5761] 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Reserved for RTCP conflict avoidance [RFC5761] 96-127 dynamic [RFC3551] IMHO, it would be helpful to get this table up to date with regard to the RFCs, even though it is marked "Closed". Do people agree with me on this? (And how do we go about it? I assume that the AD can route it to IANA.) (This also limits us to 61 PTs, which is another matter.) Dale From christer.holmberg@ericsson.com Thu Apr 25 10:31: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 37ABA21F961E for ; Thu, 25 Apr 2013 10:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 izGB0h2g-qMc for ; Thu, 25 Apr 2013 10:31:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5572221F93B9 for ; Thu, 25 Apr 2013 10:31:04 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-e2-517968556b74 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D3.0C.19728.55869715; Thu, 25 Apr 2013 19:31:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 19:31:01 +0200 From: Christer Holmberg To: "'Dale R. Worley'" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQdoCk0UK10QF00CYB+KA+npxHpjnMNzg Date: Thu, 25 Apr 2013 17:31:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36072A@ESESSMB209.ericsson.se> References: <201304251725.r3PHPNPu3426177@shell01.TheWorld.com> In-Reply-To: <201304251725.r3PHPNPu3426177@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvrW5oRmWgwaLP2hZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgymjatoqloIGr4sPsz6wNjHfYuxg5OSQETCQm tD2EssUkLtxbz9bFyMUhJHCYUeJKZxsrhLOEUWLPvRtAVRwcbAIWEt3/tEEaRASCJB637QFr FgYKn285yQwRt5S4ufw8C4RtJPHx4BpWEJtFQFXi2fnVTCA2r4CvxItbc1hARgoJ2Esc3QTW yingIDHp5m+wckage76fWgNWziwgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxXCVpRof9rACFGv I7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenlRpsY gXFwcMtv1R2Md86JHGKU5mBREuedIVUZKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRa425 RuHrak/Hf81VWxv0U/bnzkxgLp82Zb7kcecXU33WCJ5x11tx8OOax6xp0978Oz537fV3MlMj pypkiD7Y+COVtTmn+ddihVLROyV39OdOvXzjlUcQ20S2WVrCcR3J4Z0eE46aOWgcjFPkS03K 6vEx4HGu5I+1l/jsezzsRGaDPK/u8SIlluKMREMt5qLiRACqhM6fUQIAAA== Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 17:31:25 -0000 Hi, >Here are two desiderata based on the limitations of existing intermediate = devices: > > 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. Well, this is not the case with BUNDLE, after the first O/A transaction. Th= at's why there is a second O/A transaction. > DES C7 In a session description, no endpoint of a transport > association may be used multiple times. > > Such duplication is not defined by [RFC4566]. Some SBCs do not > support such duplication (ultimately, because it was not supported by > [RFC2327]), and they reject SDP specifying duplicated transport > association endpoints. This desideratum was suggested by Cullen > Jennings. I don't understand what is meant by this desiderata. Regards, Christer From juberti@google.com Thu Apr 25 10:43: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 7997C21F9452 for ; Thu, 25 Apr 2013 10:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 kQssng63F6rK for ; Thu, 25 Apr 2013 10:43:23 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3021F8E76 for ; Thu, 25 Apr 2013 10:43:23 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id t2so1692892qcq.28 for ; Thu, 25 Apr 2013 10:43:15 -0700 (PDT) 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=qHIqUB/XMb53bwyOcYbZsmoemGWNydnIq58GBXBE+ZI=; b=ox1lJ5zERGjFezpiNWCEvB4Zlx4ADNljpkJXRvUMSr9Z/DtOrIb9CoGoLFz72PBD+Q OfPiZcdDQ9GMMfe31uGG/E6+gKwuaIpLtDOLOjaC8P2g4s8zyFwv0DCraLuZ17e5+VBn dYIx5GMAgDH54k52+xr31ipKfKDPndvxaGeWntEJm1gUCQw4QVgen6KSIt6ph/PXvQzV Kii9ra8g35dnYvW713a6rfFUfgluHSFkYVSx++NOFUyhAiL89q/+pB1ko/tip/cXN8Uo bwvPxaXL3IuRUbiGQQXz5zTqEJsLATUZsV+wxVP4zkM66D2jF5VtC4Z9s5DIZ4qayOK9 KXnQ== 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=qHIqUB/XMb53bwyOcYbZsmoemGWNydnIq58GBXBE+ZI=; b=horBfvB+IxJwtVieAG+L5k2kyTeR2z8ajOOc54YaNXreo09nTnLNX9JUpRd4319q7N 89TsIOopUrRMPGpYlO58nsxhHZSUZj8w2FaakMF6q4eVIytDnfDMyJf6VS0xM4lPqoGY W2vqfGKfVek2AN0VT0szRE8vpMbSxB2mkHY0JN/nv4zQKaKAGIwWgmk1OYZek48uYNF3 VEh1K8b9/KKZXSMC8bkvEwTzrf/8/R0nX1po2YnXwTNIsyekZ1feIz9woo75GDHvv8Ty Ko22KnnYCo6hWJytTULTN4g/+GH3Mx2A5XmP95T3rLUGcjwF751QUZo3uneYncvhvEVW sGww== X-Received: by 10.49.50.162 with SMTP id d2mr21009781qeo.17.1366911795136; Thu, 25 Apr 2013 10:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.28 with HTTP; Thu, 25 Apr 2013 10:42:55 -0700 (PDT) In-Reply-To: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> From: Justin Uberti Date: Thu, 25 Apr 2013 10:42:55 -0700 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7bb05082fd495104db32f30d X-Gm-Message-State: ALoCoQkxI2ugiOCLtl42SfyX3uMim+iWOdKbfLBsS3TAEvP0zFiF8DtOTTrFqZGURNDv8/AQbOUIjfulM4d/7Sk9i9CnDykfpHS4asuNS9X4mSlZzG3W/yFNO9h3RQOt2GoA47gXdfcrz39Dij3T1wJGqMm4AM/c5Ym94YwtxBy+9Dx6lFJkO8nAEjsLpgcMLSw08EYTB31K Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 25 Apr 2013 17:43:24 -0000 --047d7bb05082fd495104db32f30d Content-Type: text/plain; charset=UTF-8 I think this would be useful, if only to make clear that # of PTs is extremely limited. On Thu, Apr 25, 2013 at 10:25 AM, Dale R. Worley wrote: > I was looking at the IANA registry "RTP Payload types (PT) for > standard audio and video encodings" > ( > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-1 > ) > to see what the allowed dynamic payload types are, and what PTs are > reserved to avoid confusion with RTCP. The unassigned range is: > > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] > > Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data > and Control Packets on a Single Port"), which gives these > instructions in section 4: > > Given these constraints, it is RECOMMENDED to follow the guidelines > in the RTP/AVP profile [7] for the choice of RTP payload type values, > with the additional restriction that payload type values in the range > 64-95 MUST NOT be used. Specifically, dynamic RTP payload types > SHOULD be chosen in the range 96-127 where possible. Values below 64 > MAY be used if that is insufficient, in which case it is RECOMMENDED > that payload type numbers that are not statically assigned by [7] be > used first. > > Since the entire range 64 to 95 is now reserved, the table should > read: > > 35-63 Unassigned > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 dynamic [RFC3551] > > IMHO, it would be helpful to get this table up to date with regard to > the RFCs, even though it is marked "Closed". > > Do people agree with me on this? (And how do we go about it? I > assume that the AD can route it to IANA.) > > (This also limits us to 61 PTs, which is another matter.) > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bb05082fd495104db32f30d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this would be useful, if only to make clear that #= of PTs is extremely limited.


On Thu, Apr 25, 2013 at 10:25 AM, Dale R. Worley <w= orley@ariadne.com> wrote:
I was looking at the IANA registry "RTP= Payload types (PT) for
standard audio and video encodings"
(http://www.iana.org/assignments/rtp-= parameters/rtp-parameters.xml#rtp-parameters-1)
to see what the allowed dynamic payload types are, and what PTs are
reserved to avoid confusion with RTCP. =C2=A0The unassigned range is:

35-71 =C2=A0 Unassigned
72-76 =C2=A0 Reserved for RTCP conflict avoidance =C2=A0 =C2=A0[RFC3551] 77-95 =C2=A0 Unassigned
96-127 =C2=A0dynamic =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC3551]

Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Da= ta
and Control Packets on a Single Port"), which gives these
instructions in section 4:

=C2=A0 =C2=A0Given these constraints, it is RECOMMENDED to follow the guide= lines
=C2=A0 =C2=A0in the RTP/AVP profile [7] for the choice of RTP payload type = values,
=C2=A0 =C2=A0with the additional restriction that payload type values in th= e range
=C2=A0 =C2=A064-95 MUST NOT be used. =C2=A0Specifically, dynamic RTP payloa= d types
=C2=A0 =C2=A0SHOULD be chosen in the range 96-127 where possible. =C2=A0Val= ues below 64
=C2=A0 =C2=A0MAY be used if that is insufficient, in which case it is RECOM= MENDED
=C2=A0 =C2=A0that payload type numbers that are not statically assigned by = [7] be
=C2=A0 =C2=A0used first.

Since the entire range 64 to 95 is now reserved, the table should
read:

35-63 =C2=A0 Unassigned
64-71 =C2=A0 Reserved for RTCP conflict avoidance =C2=A0 =C2=A0[RFC5761] 72-76 =C2=A0 Reserved for RTCP conflict avoidance =C2=A0 =C2=A0[RFC3551] 77-95 =C2=A0 Reserved for RTCP conflict avoidance =C2=A0 =C2=A0[RFC5761] 96-127 =C2=A0dynamic =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC3551]

IMHO, it would be helpful to get this table up to date with regard to
the RFCs, even though it is marked "Closed".

Do people agree with me on this? =C2=A0(And how do we go about it? =C2=A0I<= br> assume that the AD can route it to IANA.)

(This also limits us to 61 PTs, which is another matter.)

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

--047d7bb05082fd495104db32f30d-- From pkyzivat@alum.mit.edu Thu Apr 25 10:52: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 EB03621F9654 for ; Thu, 25 Apr 2013 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 zVT3K2HM4gAC for ; Thu, 25 Apr 2013 10:52:21 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id B60EF21F93E6 for ; Thu, 25 Apr 2013 10:52:07 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id UHKi1l00717dt5G5DHs7uK; Thu, 25 Apr 2013 17:52:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id UHs61l00p3ZTu2S3ZHs71V; Thu, 25 Apr 2013 17:52:07 +0000 Message-ID: <51796D46.9030300@alum.mit.edu> Date: Thu, 25 Apr 2013 13:52:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C35F47A@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=1366912327; bh=udmq4KTX7LEedrr9Uyw0yiLQT7zaE17Lf9WhzG/oYwI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rR0cVhf01XBDIhquiP67zi8NfH0MgLY2+mQPut9rAfyDJJR4tOsHmpNvPjNkvL49L /g59NtIo5PxvKYYePYQ+m1o2rCswF6j2xi6jyApTg4OIouveCBPePwgoJNUMUQWevo tsxnpZC5EsBW16wMppBMHiIzei/0eP/+JxJx7kNKevr3DUvxAd27jaotALn+DdMBsr Ik4Y4Zd32XVwWGwHn9Xlw84RhnNDDKFTx4Az+TIy/jf3UPf85BHEbPyhndgEsGTlXE 4gyILWl65wfT6Qx4cBBzSD2iSGpqwI5e/hCX1zmfgKR9qsSMjRKtKPOWvmuc4ZUGBI 8cXIzA/4pZdaA== Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 25 Apr 2013 17:52:30 -0000 On 4/25/13 10:19 AM, Christer Holmberg wrote: > [Was: [MMUSIC] Comment on Payload type restriction in draft-ietf-mmusic-sdp-bundle-negotiation-03] > > Hi, > >> - the draft doesn't currently talk at all about including the >> m-line for the SCTP association for data channels in the bundle, >> but people expect it. There is a special mechanism for demuxing >> those packets from RTP. But that mechanism is limited to SCTP >> over DTLS. And it is limited to a single SCTP association in the >> bundle. > > That is for sure text that needs to be added - assuming we have a WG decision that we are going to do it. Or, does someone think we only need to care about RTP (as far as BUNDLE is concerned) at this point? > >> ISTM that there must be specification of: >> - the demux mechanisms that are available, >> - how they work, >> - how they do or don't coexist with one another, >> - and how they are signaled in SDP. >> >> The list of available demux mechanisms may need to be extensible. >> And the bundle mechanism should be designed to accommodate that. > > Yes. Whenever someone wants to add a new transport to BUNDLE, he/she needs to describe how the multiplexing with other transports is done, i.e. fill out the bullet list above. > > BUT, does that mean that we need a signalling mechanism where a BUNDLE client inform which demux mechanisms it supports? > > Example: a=mux_transports: RTP, DTLS-SCTP > > In future, someone may specify how to add MSRP to BUNDLE, and how to mux it with DTLS-SCRTP and RTP: > > Example: a=mux_transports: RTP, DTLS-SCTP, MSRP Yes - we need a way to signal the demux mechanism to be used. (Unless there is only one possibility. And we have already disproved that.) ISTM that there will need to be a spec (maybe just a small one) for each mechanism, that describes how it works and also how it is signaled. How that is denoted isn't yet apparent to me. Its not even clear to me *where* in the SDP it needs to go. *Perhaps* it can be per-m-line, as long as there are clear rules for how the rules for different m-lines are coordinated in a bundle. Thanks, Paul From mzanaty@cisco.com Thu Apr 25 11:57: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 0183D21F9671; Thu, 25 Apr 2013 11:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 H47H+Q5t9hUy; Thu, 25 Apr 2013 11:57:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0984521F8411; Thu, 25 Apr 2013 11:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2628; q=dns/txt; s=iport; t=1366916268; x=1368125868; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lH8OVXyc9gZ8+6CgKDUB+oAEjpSEmgJ2Kvx+/RESnqk=; b=IZ2b/i25HunEJajkF4IQSoB9sHEQMQ3DDHRxRnBmn2YrzvQ5MpaOpUp7 n4J/dtuDLcdcoBVPuW78zDwIpnOLX165rCGxndHTSmbzlMRucSg+d6XWb 5I2xvPTVZynCV1rz3ECVCsh2Gp5tud60/LlFhKGBlLXzqSJAITKOtbEMY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA98eVGtJV2b/2dsb2JhbABRgwY2vi+BBBZ0gh8BAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAGICwy+Po19gQc4BoJnYQOoPoMOgWo+ X-IronPort-AV: E=Sophos;i="4.87,552,1363132800"; d="scan'208";a="200150634" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2013 18:57:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3PIvlAR031810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 18:57:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 13:57:46 -0500 From: "Mo Zanaty (mzanaty)" To: "Dale R. Worley" , "mmusic@ietf.org" , "payload@ietf.org" , "Ali C. Begen (abegen)" Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOQdoLz3rs6rgYyUO2pptDF+kp/pjnRTkw Date: Thu, 25 Apr 2013 18:57:46 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> In-Reply-To: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.88.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 25 Apr 2013 18:57:49 -0000 I agree with the IANA update below for clarity. But practically speaking, P= AYLOAD will never assign another static payload, so we are effectively limi= ted to the dynamic range for all modern codecs unless PAYLOAD decides to re= allocate 35-63 from static to dynamic. I could only see that happening if p= roducts really need to support >32 codecs. (True codecs, not demux IDs for = different streams in bundles.) Mo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dale R. Worley Sent: Thursday, April 25, 2013 1:26 PM To: mmusic@ietf.org Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? I was looking at the IANA registry "RTP Payload types (PT) for standard audio and video encodings" (http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-para= meters-1) to see what the allowed dynamic payload types are, and what PTs are reserved to avoid confusion with RTCP. The unassigned range is: 35-71 Unassigned 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Unassigned 96-127 dynamic [RFC3551] Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data and Control Packets on a Single Port"), which gives these instructions in section 4: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. Since the entire range 64 to 95 is now reserved, the table should read: 35-63 Unassigned 64-71 Reserved for RTCP conflict avoidance [RFC5761] 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Reserved for RTCP conflict avoidance [RFC5761] 96-127 dynamic [RFC3551] IMHO, it would be helpful to get this table up to date with regard to the RFCs, even though it is marked "Closed". Do people agree with me on this? (And how do we go about it? I assume that the AD can route it to IANA.) (This also limits us to 61 PTs, which is another matter.) Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Thu Apr 25 12:29: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 D6EDD21F850E; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 BxN63Fn1bmap; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) 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 3052F21F84F5; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3PJTT13005817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 14:29:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51798419.7070103@nostrum.com> Date: Thu, 25 Apr 2013 14:29:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------060404010905000303020204" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 25 Apr 2013 19:29:41 -0000 This is a multi-part message in MIME format. --------------060404010905000303020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote: > I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic. I think RFC 3551, section 3 is still the governing text on how RTP/AVP (and its related profiles) allocates payload types: > "This profile reserves payload type numbers in the range 96-127 > exclusively for dynamic assignment. Applications SHOULD first use > values in this range for dynamic payload types. Those applications > which need to define more than 32 dynamic payload types MAY bind > codes below 96, in which case it is RECOMMENDED that unassigned > payload type numbers be used first. However, the statically assigned > payload types are default bindings and MAY be dynamically bound to > new encodings if needed." (With particular emphasis on the final quoted sentence) So, _practically_ speaking, the proposed registry update does make a big difference: it clarifies that 64-71 and 77-95 are off limits. Also, _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct codecs, since even the statically assigned payload types can be rebound. If you work with teams that are under the mistaken impression that you cannot dynamically re-bind the first 64 RTP payload types, I would beg you to disabuse them of that notion. /a --------------060404010905000303020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote:
I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic.

I think RFC 3551, section 3 is still the governing text on how RTP/AVP (and its related profiles) allocates payload types:

>  "This profile reserves payload type numbers in the range 96-127
>   exclusively for dynamic assignment.  Applications SHOULD first use
>   values in this range for dynamic payload types.  Those applications
>   which need to define more than 32 dynamic payload types MAY bind
>   codes below 96, in which case it is RECOMMENDED that unassigned
>   payload type numbers be used first.  However, the statically assigned
>   payload types are default bindings and MAY be dynamically bound to
>   new encodings if needed."

(With particular emphasis on the final quoted sentence)

So, _practically_ speaking, the proposed registry update does make a big difference: it clarifies that 64-71 and 77-95 are off limits. Also, _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct codecs, since even the statically assigned payload types can be rebound.

If you work with teams that are under the mistaken impression that you cannot dynamically re-bind the first 64 RTP payload types, I would beg you to disabuse them of that notion.

/a
--------------060404010905000303020204-- From worley@shell01.TheWorld.com Thu Apr 25 12:34: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 5E4AE21F96C5 for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 X055LnkyYbuU for ; Thu, 25 Apr 2013 12:34:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 157FA21F9647 for ; Thu, 25 Apr 2013 12:34:01 -0700 (PDT) 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 r3PJX3KP006525; Thu, 25 Apr 2013 15:33:05 -0400 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 r3PJX34d3436818; Thu, 25 Apr 2013 15:33:03 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJX2Lk3440743; Thu, 25 Apr 2013 15:33:02 -0400 (EDT) Date: Thu, 25 Apr 2013 15:33:02 -0400 (EDT) Message-Id: <201304251933.r3PJX2Lk3440743@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <51786396.9080706@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> <51786396.9080706@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:34:03 -0000 > From: Paul Kyzivat > >>> DES C4 Any additional m= lines prescribed by the bundle mechanism > >>> should be ordered after the constituent m= lines. > > If a "bundle" media description is to be added, it ought to be added > > *after* the m= lines for the constituent media streams, so that the > > "bundle" media description doesn't change which media description is > > identified as "the first audio media description", "the second audio > > media description", "the first video media description", etc. > > So, suppose A makes an offer to B with 4 m-lines to be bundled, with a > 5th "bundle" m-line after those. > > But then suppose B needs those split into two bundles with different > addresses. > > B could accept the initial offer but reject m-lines 2 & 4. So then there > is a bundle consisting of m-lines 1,3,5. > > Then it might send another offer back toward A, reactivating m-lines 2 & > 4, and adding m-line 6 as the bundle m-line for the second bundle. > Assuming A accepts that, then there will be two bundles, 1,3,5 and 2,4,6. > > Is that consistent with what you are proposing here? Yes, that seems consistent with this desideratum. The "bundle" m= lines are 5 (containing 1 and 3) and 6 (containing 2 and 4), and each of them follows all of the constituent m= lines. That makes it less likely that a simple-minded UA considers m= lines 5 and 6 to be usable media. In this particular case, B might want to accept 2 and 4, but disconnect them from the bundle (now containing 1 and 3 only). Then B could send a new offer bundling 2 and 4 separately. That prevents an interval during which 2 and 4 are inactive, which might not be the semantics B wants to present to A. Dale From worley@shell01.TheWorld.com Thu Apr 25 12:34: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 5D4A521F96BC for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 TrNaUrk7uqcx for ; Thu, 25 Apr 2013 12:34:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 167F421F9670 for ; Thu, 25 Apr 2013 12:34:01 -0700 (PDT) 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 r3PJXMiB015946; Thu, 25 Apr 2013 15:33:24 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJXM5O3364035; Thu, 25 Apr 2013 15:33:22 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJXMnt3433409; Thu, 25 Apr 2013 15:33:22 -0400 (EDT) Date: Thu, 25 Apr 2013 15:33:22 -0400 (EDT) Message-Id: <201304251933.r3PJXMnt3433409@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <5178614A.1090207@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <5178614A.1090207@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:34:03 -0000 > From: Paul Kyzivat > > I mean the latter. The intended parsing is: > > > > (non-DES) C5 SBCs generally pass through attributes that they do not... > What evidence do you have to support this assertion? > AFAIK this is far from universally true. That's what I've been told, but I haven't surveyed the market very thoroughly. What do you think would be a more accurate statement? Dale From worley@shell01.TheWorld.com Thu Apr 25 12:34: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 CF12A21F96BC for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 1DWx6Mvf2uQy for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1584021F966D for ; Thu, 25 Apr 2013 12:34:01 -0700 (PDT) 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 r3PJWhAH029671; Thu, 25 Apr 2013 15:32:45 -0400 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 r3PJWgKG3439532; Thu, 25 Apr 2013 15:32:42 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJWg933435890; Thu, 25 Apr 2013 15:32:42 -0400 (EDT) Date: Thu, 25 Apr 2013 15:32:42 -0400 (EDT) Message-Id: <201304251932.r3PJWg933435890@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <5177F3B6.1090709@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <51778EE1.8080505@ericsson.com> <51778F56.60306@ericsson.com> <5177F3B6.1090709@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comment on Payload type restriction in 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, 25 Apr 2013 19:34:04 -0000 > From: Paul Kyzivat > > But this is just part of the more general issue of how the contents of a > bundle are demultiplexed. There have been a number of demux mechanisms > proposed: > > - Payload type *has* been proposed as one mechanism. > In those cases where it is to be used to map an RTP packet to a > particular m-line then indeed the payload type restriction needs > to apply. In regard to demultiplexing by payload type (and related tests, that is, RFC 5764) and demultiplexing by a "shim" or encpapsulation RTP format, here is a start: http://tools.ietf.org/html/draft-worley-sdp-bundle-06#section-8 Dale From worley@shell01.TheWorld.com Thu Apr 25 12:34: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 B9BB221F9647 for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 bSbti3+zHRnR for ; Thu, 25 Apr 2013 12:34:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 329C521F9692 for ; Thu, 25 Apr 2013 12:34:01 -0700 (PDT) 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 r3PJXueC031564; Thu, 25 Apr 2013 15:33:58 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJXuWY3436246; Thu, 25 Apr 2013 15:33:56 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJXuon3430760; Thu, 25 Apr 2013 15:33:56 -0400 (EDT) Date: Thu, 25 Apr 2013 15:33:56 -0400 (EDT) Message-Id: <201304251933.r3PJXuon3430760@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:34:04 -0000 > From: Christer Holmberg > > What do you mean by "known attribute" and a "known codec"? > > Any defined attribute/codec is "known". By "known attribute" I mean, "an attribute that we can expect most or all SBCs to understand". Dale From worley@shell01.TheWorld.com Thu Apr 25 12: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 5F58621F9692 for ; Thu, 25 Apr 2013 12:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 GSW0B0fEdNd6 for ; Thu, 25 Apr 2013 12:34:12 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1299B21F96C8 for ; Thu, 25 Apr 2013 12:34:04 -0700 (PDT) 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 r3PJXeXb018388; Thu, 25 Apr 2013 15:33:42 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJXe5s3428218; Thu, 25 Apr 2013 15:33:40 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJXdJA3428532; Thu, 25 Apr 2013 15:33:39 -0400 (EDT) Date: Thu, 25 Apr 2013 15:33:39 -0400 (EDT) Message-Id: <201304251933.r3PJXdJA3428532@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C35D1BB@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1BB@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:34:13 -0000 > From: Christer Holmberg > > So, as we will not move forward with draft-bundle, I guess DES C3 is > fulfilled, right? I'm not asking "Does the current proposal have this desideratum?" but rather "Is this property, which I think we need, actually needed?" In this instance, I'm trying to assess what the requirements on MMT-style solutions would be. Dale From worley@shell01.TheWorld.com Thu Apr 25 12:34: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 E558B21F94B1 for ; Thu, 25 Apr 2013 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 rY10DSDwKtxE for ; Thu, 25 Apr 2013 12:34:54 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5581621F91B2 for ; Thu, 25 Apr 2013 12:34:54 -0700 (PDT) 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 r3PJYUTI013651; Thu, 25 Apr 2013 15:34:32 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJYUYR3423964; Thu, 25 Apr 2013 15:34:30 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJYUml3428803; Thu, 25 Apr 2013 15:34:30 -0400 (EDT) Date: Thu, 25 Apr 2013 15:34:30 -0400 (EDT) Message-Id: <201304251934.r3PJYUml3428803@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <516466C5.1070201@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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: Thu, 25 Apr 2013 19:34:55 -0000 > From: Paul Kyzivat > > This has come up in CLUE, and pertains to cases where not all media > processing equipment is at the same address. In such cases bundling may > be supported, but more than one bundle may be required. > > When this happens on the offering end the offerer can propose multiple > bundles from the beginning. But when it is the answerer that needs > things in separate bundles then it will need to "split" (partition) the > offered bundle into multiple bundles. You can view this as a variant of > (1)+(3) below. I've given a little thought to the question of how a new offer may amend the bundling situation created by the previous negotiation. I was considering the extremely general case when nested or hierarchial bundling is allowed, but I think the conclusions are the same even with one-level bundling: 1) It's natural to consider a rule "The new bundling must be compatible with the old bundling", but it is extremely difficult to come up with a definition of "compatible" that makes sense in all cases, or even a definition that can be verified and enforced (unless it is so strict as to be an impediment in practical situations). 2) There is little practical benefit to trying to align the new bundling with the old bundling. The reason for (2) is that after the offer/answer cycle, the endpoint only needs to adjust its multiplexing/demultiplexing mechanism to connect the correct application-level interfaces to the correct transport endpoints. That connection is actually fairly simple and can be driven by a fairly small table that can be extracted directly from the O/A SDP (even in complex cases such as hierarchial bundling using an MMT-style syntax) -- there is no need to minimize the changes from the previous bundling state to the new bundling state. Dale From worley@shell01.TheWorld.com Thu Apr 25 12:35: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 2652921F95F9 for ; Thu, 25 Apr 2013 12:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 R5LLi7YAkvqc for ; Thu, 25 Apr 2013 12:35:05 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 780F721F94B1 for ; Thu, 25 Apr 2013 12:35:05 -0700 (PDT) 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 r3PJYvl7002615; Thu, 25 Apr 2013 15:34:59 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJYup43430625; Thu, 25 Apr 2013 15:34:56 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJYupZ3410480; Thu, 25 Apr 2013 15:34:56 -0400 (EDT) Date: Thu, 25 Apr 2013 15:34:56 -0400 (EDT) Message-Id: <201304251934.r3PJYupZ3410480@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <516466C5.1070201@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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: Thu, 25 Apr 2013 19:35:06 -0000 > From: Paul Kyzivat > > This has come up in CLUE, and pertains to cases where not all media > processing equipment is at the same address. In such cases bundling may > be supported, but more than one bundle may be required. > > When this happens on the offering end the offerer can propose multiple > bundles from the beginning. But when it is the answerer that needs > things in separate bundles then it will need to "split" (partition) the > offered bundle into multiple bundles. You can view this as a variant of > (1)+(3) below. Some further thoughts on splitting an offered bundle: One consideration is that when the answerer wants to split an offered bundle, how does it do so in a way that takes into account what the offerer wants? For instance: 1. A offers a bundle 1,2,3,4. 2. B cannot bundle 3,4 with 1,2. 3. So B replies with bundle 1,2 and rejects 3,4 (or accepts them unbundled). 4. Now B offers bundle 1,2 and bundle 3,4. 5. A can accept both bundles, so A accepts bundle 1,2 and bundle 3,4. This is somewhat inefficient, since it takes two O/A cycles, but it's simple, since A doesn't need to signal to B in some way what bundlings it is willing to accept (e.g., with the hierarchial bundling concept I've talked about). Now suppose A wants to bundle 1,2,3,4 and 5,6,7,8, but B wants to bundle 1,2,5,6 and 3,4,7,8. The best bundling that can be achieved is in four pairs, bundle 1,2, bundle 3,4, bundle 5,6, and bundle 7,8. The best possible pattern for A and B to negotiate this would be something like this: 1. A offers bundle 1,2,3,4 and bundle 5,6,7,8. 2. B accepts bundle 1,2 and bundle 5,6 and rejects 3, 4, 7, and 8. 3. B offers bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8. (Although it is willing to bundle 3,4 with 7,8, it remembers from A's offer that it was unwilling to do so. So B is limited to bundling the four m= lines into two pairs.) 4. A accepts bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8. We have to make sure that A doesn't attempt to start a third cycle to see if it can get 1,2 bundled with 3,4, etc. But if either side initiates a re-offer for some other reason, the new offer should be the biggest bundling the offerer is willing to support. Dale From worley@shell01.TheWorld.com Thu Apr 25 12:36: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 C354421F96E6 for ; Thu, 25 Apr 2013 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 I8i8P4DXwdEF for ; Thu, 25 Apr 2013 12:36:01 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 087BB21F96DE for ; Thu, 25 Apr 2013 12:36:00 -0700 (PDT) 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 r3PJZK2H015380; Thu, 25 Apr 2013 15:35:22 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJZK3C3435476; Thu, 25 Apr 2013 15:35:20 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJZKXe3439225; Thu, 25 Apr 2013 15:35:20 -0400 (EDT) Date: Thu, 25 Apr 2013 15:35:20 -0400 (EDT) Message-Id: <201304251935.r3PJZKXe3439225@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C36072A@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304251725.r3PHPNPu3426177@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36072A@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:36:01 -0000 > From: Christer Holmberg > > >Here are two desiderata based on the limitations of existing > >intermediate devices: > > > > 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. > > Well, this is not the case with BUNDLE, after the first O/A > transaction. That's why there is a second O/A transaction. That's true, which is an undesirable feature of BUNDLE. (But we may have to tolerate that undesirable feature in order to avoid an even more undesirable feature.) > > DES C7 In a session description, no endpoint of a transport > > association may be used multiple times. > > > > Such duplication is not defined by [RFC4566]. Some SBCs do not > > support such duplication (ultimately, because it was not supported by > > [RFC2327]), and they reject SDP specifying duplicated transport > > association endpoints. This desideratum was suggested by Cullen > > Jennings. > > I don't understand what is meant by this desiderata. "Don't specify the same address/port in two m= lines." Dale From worley@shell01.TheWorld.com Thu Apr 25 12:36: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 71DD821F96E6 for ; Thu, 25 Apr 2013 12:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 jGGfJ1tp+Um6 for ; Thu, 25 Apr 2013 12:36:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D447021F96DE for ; Thu, 25 Apr 2013 12:36:01 -0700 (PDT) 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 r3PJYDCs004670 for ; Thu, 25 Apr 2013 15:34:15 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3PJYDCT3432439 for ; Thu, 25 Apr 2013 15:34:13 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PJYDQH3438432; Thu, 25 Apr 2013 15:34:13 -0400 (EDT) Date: Thu, 25 Apr 2013 15:34:13 -0400 (EDT) Message-Id: <201304251934.r3PJYDQH3438432@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:36:02 -0000 Two final "compatibility" desiderata. 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. This one is another reason not to use encapsulation/shim: DES C9 If an intermediate entity provides transcoding between codecs, and if the offer/answer does not specify encryption of a media stream, the media stream should be able to take advantage of the transcoding facility. Dale From christer.holmberg@ericsson.com Thu Apr 25 12:46: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 0E87F21F899E for ; Thu, 25 Apr 2013 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 McTD+gbO54Tk for ; Thu, 25 Apr 2013 12:46:27 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1115E21F8976 for ; Thu, 25 Apr 2013 12:46:26 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-49-5179881134bc Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.43.19728.11889715; Thu, 25 Apr 2013 21:46:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 21:46:25 +0200 From: Christer Holmberg To: "'Dale R. Worley'" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQdoCk0UK10QF00CYB+KA+npxHpjnMNzggAAjpsCAAAKkQA== Date: Thu, 25 Apr 2013 19:46:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C360971@ESESSMB209.ericsson.se> References: <201304251725.r3PHPNPu3426177@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36072A@ESESSMB209.ericsson.se> <201304251935.r3PJZKXe3439225@shell01.TheWorld.com> In-Reply-To: <201304251935.r3PJZKXe3439225@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra5QR2WgQWutxdTlj1ksXp4oc2Dy mLz/K7PHkiU/mQKYorhsUlJzMstSi/TtErgyLuxtYS9oY61oenmWuYHxC3MXIyeHhICJxLqP 09ghbDGJC/fWs3UxcnEICRxmlNh34SETSEJIYAmjxJ5JCl2MHBxsAhYS3f+0QcIiAtoSP1ac YQMJMwuoS1xdHAQSFgaqON9ykhmixFLi5vLzLBC2k8SWJTvBbBYBVYmTzyFO4BXwlVjf9Zwd Yu1OoE2PGsDWcgo4SCxf2gtmMwLd9v3UGjCbWUBc4taT+UwQNwtILNlzHuoXUYmXj/+xQtiK Eu1PGxgh6nUkFuz+xAZha0ssW/gaarGgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRPTcx Mye93GgTIzA6Dm75rbqD8c45kUOM0hwsSuK8M6QqA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwchuoquQ83ZR5RmbWwWlPl1d5aRfwX/vavfOQ7Lc33VzrdpusM3h8vrl12t1vS2wcX+St 7i9WC+XYdi1JjtlFVSZuRrh5D8PD96efHzlvXrcnqm6l055ZM15//n724ix1trAF6Ul23FtX bxMoYD63u8diY4jNVNvz2uej63qrf595k5B/JrpGR4mlOCPRUIu5qDgRAMxVyRhcAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:46:28 -0000 Hi, >>> DES C7 In a session description, no endpoint of a transport >>> association may be used multiple times. >>> >>> Such duplication is not defined by [RFC4566]. Some SBCs do not >>> support such duplication (ultimately, because it was not supported by >>> [RFC2327]), and they reject SDP specifying duplicated transport >>> association endpoints. This desideratum was suggested by Cullen >>> Jennings. >>=20 >> I don't understand what is meant by this desiderata. > > "Don't specify the same address/port in two m=3D lines." Well, we do that in bundle (in the second offer). Regards, Christer From christer.holmberg@ericsson.com Thu Apr 25 12:58: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 C67D421F93D4 for ; Thu, 25 Apr 2013 12:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, 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 Y4+xhbO2I4Uq for ; Thu, 25 Apr 2013 12:58:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06F5521F8ED8 for ; Thu, 25 Apr 2013 12:58:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-3d-51798ae5a3f6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F2.D1.10459.5EA89715; Thu, 25 Apr 2013 21:58:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 21:58:29 +0200 From: Christer Holmberg To: "'Dale R. Worley'" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQFmli+cVnxjNCEKSb6lvFRbbnJjk2rcwgAJ8SaCAAAZ0AA== Date: Thu, 25 Apr 2013 19:58:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C360983@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35BC40@ESESSMB209.ericsson.se> <201304231935.r3NJZ24T3171577@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1BB@ESESSMB209.ericsson.se> <201304251933.r3PJXdJA3428532@shell01.TheWorld.com> In-Reply-To: <201304251933.r3PJXdJA3428532@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre7TrspAg09PbCymLn/MYvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHy7UO2glbmiq2v1rI3MK5l6mLk5JAQMJF4 3PaYDcIWk7hwbz2QzcUhJHCYUeLPk1eMEM4SRokrzxuAOjg42AQsJLr/aYM0iAhoS/xYcYYN JMwsoC5xdXEQSFgYqOJ8y0lmiBJLiZvLz7NA2E4SW1qOs4LYLAKqEq8fzAKL8wr4Smy+85kV YtVmJokfT9eBHcQp4CDReXw5mM0IdNz3U2vAjmYWEJe49WQ+1AMCEkv2nGeGsEUlXj7+xwph K0q0P21ghKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkb2 3MTMnPRyw02MwAg5uOW37g7GU+dEDjFKc7AoifNOl6oMFBJITyxJzU5NLUgtii8qzUktPsTI xMEp1cAoHCv3OWft47knO66XPM/cdtO6d2WviXHpifAD3Fdn52vcdE/XP3zDyWLihJCm3iU/ T+taFO9esfnb7v037i16xh130CFz8xn51zpPXZ5L3YlUnz5v3iT35UXHLGyEtmcWnlg88/5z 0SwTXdt8MZvEmTPqD8i+2FrXt9SvjX1B2FvD43eUuJZbKbEUZyQaajEXFScCAAd7y9deAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 19:58:35 -0000 Hi, =20 >> So, as we will not move forward with draft-bundle, I guess DES C3 is=20 >> fulfilled, right? > > I'm not asking "Does the current proposal have this desideratum?" but rat= her "Is this property, which I think we need, actually needed?" Fair enough, but currently we do have the property, no matter whether we th= ink it's needed or not :) Regards, Christer From christer.holmberg@ericsson.com Thu Apr 25 13:00: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 D33D221F9659 for ; Thu, 25 Apr 2013 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, 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 Yen-5nc0tGU0 for ; Thu, 25 Apr 2013 13:00:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1809821F9457 for ; Thu, 25 Apr 2013 13:00:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-0f-51798b645b2d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 22.25.03253.46B89715; Thu, 25 Apr 2013 22:00:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Thu, 25 Apr 2013 22:00:36 +0200 From: Christer Holmberg To: "'Dale R. Worley'" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQevTi+cVnxjNCEKSb6lvFRbbnJjnWrcQ Date: Thu, 25 Apr 2013 20:00:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> In-Reply-To: <201304251933.r3PJXuon3430760@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW5Kd2WgwcQ9uhZTlz9msXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyvi+fB1bwQXmiotzzrI2MD5j6mLk5JAQMJF4 MHE2C4QtJnHh3nq2LkYuDiGBw4wSH998ZIJwljBKTD67DyjDwcEmYCHR/U8bpEFEQFvix4oz YGFmAXWJq4uDQMLCQBXnW04yQ5RYStxcfp4FwjaSuHf/GNheFgFViaW7FoPZvAK+Eg+uLGaG WLWNSeLqwitgCU4BB4nbf2awg9iMQMd9P7UGLM4sIC5x68l8qAcEJJbsOc8MYYtKvHz8jxXC VpRof9rACFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzs uYmZOenl5psYgRFycMtvgx2Mm+6LHWKU5mBREuedIVUZKCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFR2a3jo68Iw2el7+FOtfvP9M0rPb9h2TaDPnnnQ2UHXX9E//J9wMEX+U30c25p3Y83 pZc/mK3hkuuK72QotfbonrHb1icg5qL4zrvWUdfmiJU0XbTJ6FFwMpm2s2rN6tqkS3/q/yw0 OrJmYaPW9H9npm8QO3ffdvrVDm+hT7fmLTy496+afOd2JZbijERDLeai4kQASljjyV4CAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 25 Apr 2013 20:00:39 -0000 Hi, >> What do you mean by "known attribute" and a "known codec"?=20 >>=20 >> Any defined attribute/codec is "known". > > By "known attribute" I mean, "an attribute that we can expect most or all= SBCs to understand". I'm a little lost. Why do we, in the bundle context, need to talk about whi= ch codecs SGCs understand? If the SGCs will process media on a codec level = it will indicate in SDP which codecs it support. Regards, Christer From worley@shell01.TheWorld.com Thu Apr 25 15:20: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 6359321F96DD for ; Thu, 25 Apr 2013 15:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=1.117] 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 3Quz6sfL-vKh for ; Thu, 25 Apr 2013 15:20:11 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 864C121F96BC for ; Thu, 25 Apr 2013 15:20:10 -0700 (PDT) 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 r3PMJxtA012338; Thu, 25 Apr 2013 18:20:01 -0400 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 r3PMJvQM3362210; Thu, 25 Apr 2013 18:19:57 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3PMJv6C3392749; Thu, 25 Apr 2013 18:19:57 -0400 (EDT) Date: Thu, 25 Apr 2013 18:19:57 -0400 (EDT) Message-Id: <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <51796D46.9030300@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 25 Apr 2013 22:20:11 -0000 > From: Paul Kyzivat > > Yes - we need a way to signal the demux mechanism to be used. > (Unless there is only one possibility. And we have already disproved that.) We could use different group "semantics" values to indicate the multiplexing mechanism. One endpoint could probe the other to discover which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism. The answer will show which mechanisms the answerer supports. Dale From magnus.westerlund@ericsson.com Thu Apr 25 23:50: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 9CD6E21F9743; Thu, 25 Apr 2013 23:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 QK2M1woNImUR; Thu, 25 Apr 2013 23:50:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA321F856D; Thu, 25 Apr 2013 23:50:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-3c-517a23bab713 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.CC.19728.AB32A715; Fri, 26 Apr 2013 08:50:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 26 Apr 2013 08:50:34 +0200 Message-ID: <517A23B4.3060801@ericsson.com> Date: Fri, 26 Apr 2013 08:50:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> In-Reply-To: <51798419.7070103@nostrum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre4u5apAg5Vr1S32/F3EbjF1+WMW ixcP5jBZXLp4lsmBxWPK742sHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXRv/hJpaCbumK j49msjYw3hDtYuTkkBAwkbj+9zEbhC0mceHeeiCbi0NI4BSjxIWtJ5ghnOWMEheXTwGr4hXQ lri+9RQjiM0ioCqx/PlDZhCbTcBC4uaPRqAaDg5RgWCJra0xEOWCEidnPmEBsUUEFCXaDt8E K2cWqJO4cGM6O0i5sICvxOavchCr5jNK7Fx5DWw8J9Cq5zsfQB0nKbHlRTs7RK+exJSrLYwQ trxE89bZYDOFgOobmjpYJzAKzUKyehaSlllIWhYwMq9iZM9NzMxJLzfaxAgM5INbfqvuYLxz TuQQozQHi5I47wypykAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNsO1lyuli1MzzC/sXL2 0oi4X7dWFOdc4ep7FLHvePOfBcUcrxQ6wv5pTn1s+K7ubs1klu3RfNn/26sFd92q4hPh0M78 WxwxU+BI9wSd7t8d1kvrp+RO5jK6Ovfzxqm2HH9z7rQKTP6yp4Jvw261K5zVvj2FRYeuLpJd ev7i5oy+uWmcGx6FnlFiKc5INNRiLipOBAAk/f62MgIAAA== Cc: "payload@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 26 Apr 2013 06:50:38 -0000 Hi, And to add to that. These limitations are only present given that you actually are using RTP and RTCP multiplexing. You can regain the whole 128 numbers by having RTP and RTCP separated. This quote from RFC 5761: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. I think is clear that you have 96 values for use. The MUST NOT is really to ensure that you will not have issues. Assuming tighter signalling control could have allowed dynamic blocking of the space, but that was deemed to complex and error prone. Regarding the IANA, Mo you have correctly identified the registry as closed and Adam pointed to the relevant text. Is this level of indirection so problematic that this registry needs a Note to the effect? Cheers Magnus On 2013-04-25 21:29, Adam Roach wrote: > On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote: >> I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic. > > I think RFC 3551, section 3 is still the governing text on how RTP/AVP > (and its related profiles) allocates payload types: > >> "This profile reserves payload type numbers in the range 96-127 >> exclusively for dynamic assignment. Applications SHOULD first use >> values in this range for dynamic payload types. Those applications >> which need to define more than 32 dynamic payload types MAY bind >> codes below 96, in which case it is RECOMMENDED that unassigned >> payload type numbers be used first. However, the statically assigned >> payload types are default bindings and MAY be dynamically bound to >> new encodings if needed." > > (With particular emphasis on the final quoted sentence) > > So, _practically_ speaking, the proposed registry update does make a big > difference: it clarifies that 64-71 and 77-95 are off limits. Also, > _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct > codecs, since even the statically assigned payload types can be rebound. > > If you work with teams that are under the mistaken impression that you > cannot dynamically re-bind the first 64 RTP payload types, I would beg > you to disabuse them of that notion. > > /a > > > _______________________________________________ > 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 christer.holmberg@ericsson.com Fri Apr 26 00:44: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 CFCB021F86F4 for ; Fri, 26 Apr 2013 00:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 UefEW3lukcp0 for ; Fri, 26 Apr 2013 00:44:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D655621F8618 for ; Fri, 26 Apr 2013 00:44:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-7b-517a3077b201 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 04.E6.03253.7703A715; Fri, 26 Apr 2013 09:44:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 09:44:55 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4g Date: Fri, 26 Apr 2013 07:44:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> In-Reply-To: <201304252219.r3PMJv6C3392749@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+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW65QVWgwcNZ5hZTlz9msVix4QCr xcsTZQ7MHn/ff2DymLz/K7PHkiU/mQKYo7hsUlJzMstSi/TtErgytvxYxVhwkKNizulzzA2M j9i6GDk5JARMJJbeXMMKYYtJXLi3HiwuJHCYUeLqdd4uRi4gewmjxJ6F+9i7GDk42AQsJLr/ aYPUiAgESmzrOs0KEmYWUJe4ujgIxBQW0JV4vDgGxBQR0JNoOVEDUWwkMbm5iQnEZhFQlXi1 5wTYIl4BX4nPe5+zQCxayigx4+YVsGs4BRwk1l76zghiMwJd9v3UGrBmZgFxiVtP5jNBXCwg sWTPeWYIW1Ti5eN/UJ8oSlydvhyqXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsY2XMTM3PSy803MQLj5eCW3wY7GDfdFzvEKM3BoiTOO0OqMlBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QD4zY77fI1ofVP+NzLGHx0zm9u5tny8YF4S/RDwZK98pu5Lawk uXQeFvaub7D/Hzth95RrU6++XzpDovDKt8WLNj/USgjc9sNIPvXe9r28ziItaxz5Ni0Lq6x4 dXFh+eLQ7fplm2r+uP780/jt1QKPAOVPBZ8e1paf/apnlh4eNzf19vcZx1by3lFiKc5INNRi LipOBAA2A7+gZQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 26 Apr 2013 07:44:58 -0000 Hi, >> Yes - we need a way to signal the demux mechanism to be used. >> (Unless there is only one possibility. And we have already disproved=20 >> that.) > > We could use different group "semantics" values to indicate the multiplex= ing mechanism. One endpoint could probe the other to discover=20 > which mechanisms it supplies by offering a collection of bundles containi= ng no constituents, one for each mechanism. The answer will show=20 > which mechanisms the answerer supports. My idea was the endpoint simply lists the media description proto values th= at it is capable of multiplexing for a given 5-tuple: Example: a=3Dmuxcap: RTP/AVP, SCTP/DTLS ...or something like that. Of course, an endpoint needs to be able to multiplex all media that it inse= rts in a bundle group. But, it may not always insert m- lines for everythin= g it is able to multiplex, so I think an explicit indication would be good. It is important to remember that, whatever you multiplex, all media have to= use the same IP transport (e.g. UDP). Regards, Christer From Simo.Veikkolainen@nokia.com Fri Apr 26 02:22: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 3E72621F988D for ; Fri, 26 Apr 2013 02:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 Qpc3NbS-tMtc for ; Fri, 26 Apr 2013 02:22:44 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E426021F988C for ; Fri, 26 Apr 2013 02:22:43 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r3Q9MRHq006175; Fri, 26 Apr 2013 12:22:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Apr 2013 12:22:27 +0300 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.240]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0328.011; Fri, 26 Apr 2013 09:22:26 +0000 From: To: Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) Thread-Index: AQHOO3h4GI1XUw+H1UKVjshlEllXf5jjVzIggAPSQ4CAAR5VMA== Date: Fri, 26 Apr 2013 09:22:26 +0000 Message-ID: References: <514FA8F7.7060203@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> <517956CB.2040701@cisco.com> In-Reply-To: <517956CB.2040701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJ6f+e0jPWCKW7SGpJea1HxF1+/yLcs1+3lx3oszWyEpFv854jwBDNm5uGBrLhHEq2uJVa1v3Zy3IaDHnDpP8YdeWJoIxth58+K+iDrSfX6VQ02aQvlegHvqg5/RXW70sT2gWMegB3w4ZokmZ6TonQusO76vvQMHR/vQU0QPUC11SVb40uqfcnkx/QGq/+rxh6PjGmIEYoBsFtbNHhKJpsDCi2sWHkj6c1vywSqwUPIuCiLtKIL2Gu8XWL0WJgw3GKD0xnlqe8LYUvX+UUenTVQQ== x-originating-ip: [172.21.81.167] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2013 09:22:27.0189 (UTC) FILETIME=[9191A250:01CE425F] X-Nokia-AV: Clean Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) 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, 26 Apr 2013 09:22:46 -0000 See below [SV]. -----Original Message----- From: ext Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: 25. huhtikuuta 2013 19:16 To: Veikkolainen Simo (Nokia-CTO/Espoo) Cc: mohamed.boucadair@orange.com; aallen@blackberry.com; HKaplan@acmepacket= .com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (d= raft-ietf-mmusic-sdp-miscellaneous-caps-04) On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com wrote: > Below the original and proposed text on the usage of ccap attribute in=20 > Section 3.1.2. of=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 > > This is pretty much the same text I proposed earlier, including Jonathan'= s wording on IN address families. > > --- begin original text --- > The 'ccap' capability attribute allows for expressing alternative > connection address ('c=3D') lines in SDP as part of the SDP capabilit= y > negotiation process. The 'ccap' capability attribute is intended to > be used only when there is no other mechanism available for > negotiating alternative connection address information, such as when > the is different among the alternative addresses (e.g. > "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in > situations where an existing mechanism (such as Interactive > Connectivity Establishment (ICE) [RFC5245]) can be used to select > between different connection addresses (e.g. "IP4" and "IP6" or > different IP addresses within the same IP address family). > --- end original text --- > > --- begin proposed text --- > The 'ccap' capability attribute is intended for offering > alternative connection addresses where the > is "IN" or "PSTN", i.e. selecting between an IP based > bearer or a circuit-switched bearer. > > The 'ccap' attribute MUST NOT be used to indicate more > than one address with an IN network type in actual > or potential configurations for any given media description > (e.g. between "IP4" and "IP6" address families or different > IP addresses within the same IP address family). > --- end proposed text--- I'm ok with the overall restriction but I think the opening wording is over= ly constraining. With that in mind, a slightly modified proposal below: The 'ccap' capability attribute allows for expressing alternative connection address ('c=3D') lines in SDP as part of the SDP capability negotiation process. One of the primary use cases for this is offering alternative connection addresses where the is "IN" or "PSTN", i.e., selecting between an IP based bearer or a circuit-switched bearer. By supporting the "IN" , the 'ccap' attribute enables the signalin= g of multiple IPv4 and IPv6 addresses, however the Standards Track mechanis= m for negotiation of alternative IP addresses in SDP is Interactive Connect= ivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change t= hat and hence the combined set of actual and potential configurations (as d= efined in [RFC5939]) for any given media description MUST NOT use the 'ccap= ' attribute to negotiate more than one address with an IN network type (i.e= ., it is not permissible to select between "IP4" and "IP6" address families= or different IP addresses within the same IP address family). [SV] I think your proposal makes the intent clearer; I'll edit the text acc= ordingly. Simo > > Also, since no alternative port numbers can be offered, add this sentence= at the end the of the last paragraph to clarify how alternative IP and PST= N media descriptions are offered: > > This document does not define any mechanism for negotiating or > describing different port numbers and hence the port number from the > "m=3D" line MUST be used by default. Exceptions to this default can b= e > provided by extension mechanisms or network type specific rules. > This draft defines an exception when the network type is "PSTN", in > which case the port number is replaced with 9 (the "discard" port) as > described in Session Decription Protocol (SDP) Extension For Setting > Up Audio and Video Media Streams over Circuit-Switched Bearers in the > Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. > --- begin new text --- > An endpoint offering alternative IP and PSTN bearers MUST include the > IP media description in the actual configuration (IP address in the "= c=3D" line > and port number in the "m=3D" line), and the PSTN media descriptions = in the > potential configuration. > --- end new text --- Looks good. Thanks -- Flemming > Regards, > Simo > > > -----Original Message----- > From: ext Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 17. huhtikuuta 2013 17:33 > To: mohamed.boucadair@orange.com > Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com;=20 > HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;=20 > christer.holmberg@ericsson.com > Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 > IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) > > > On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote: >> Hi Felmming, >> >> Because it does not allow to indicate an alternate port number. > Correct - a connection address does not provide a port number; a differen= t capability would be needed for that. >> This makes it a no working solution for various scenarios. > No - it simply means that you would need to define another capability to = convey port numbers if you wanted such a solution (however we have ICE as t= he complete solution for that and the WG has not indicated a desire to chan= ge that). > >> The text which triggered this discussion was confusing. I hope the updat= ed version will be much more clear and reflect what have been discussion so= far in this thread. > I have asked Simo to update the draft. > > Thanks > > -- Flemming > > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy=E9 : samedi >>> 13 avril 2013 02:40 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : >>> Simo.Veikkolainen@nokia.com; aallen@blackberry.com;=20 >>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org;=20 >>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data=20 >>> Capability (ccap) and IP-addresses >>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> >>> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Simo, >>>> >>>> I'm in favor of restricting the alternative address to PSTN. >>> Can you elaborate on why ? >>> >>> We have defined a generic connection data capability as part of a=20 >>> general capability negotiation framework. What's the point of that=20 >>> if the only value it can convey is PSTN ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> This is coherent whit your first bullet below. >>>> >>>> If you share the text changes you are proposing, this would be more >>> easier to review. >>>> Thanks for taking care of this issue. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De=20 >>>>> la part >>> de >>>>> Simo.Veikkolainen@nokia.com >>>>> Envoy=E9 : lundi 8 avril 2013 08:35 >>>>> =C0 : fandreas@cisco.com; aallen@blackberry.com;=20 >>>>> HKaplan@acmepacket.com Cc : jonathan@vidyo.com; mmusic@ietf.org;=20 >>>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection=20 >>>>> Data Capability (ccap) and IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> Recapping the discussion so far: >>>>> >>>>> >>>>> - ICE is the way to negotiate between different IP addresses.=20 >>>>> There >>> seems >>>>> to be no disagreement here. >>>>> >>>>> - since no alternative port number can be expressed, in practice=20 >>>>> the IN address needs to go to the actual configuration (address in=20 >>>>> the c=3D line >>> and >>>>> port number in the m=3D line), and the alternative PSTN address in=20 >>>>> the potential configurations. Also here, there seems to be no disagre= ement. >>>>> >>>>> - then, whether the "ccap" attribute should be limited to carry=20 >>>>> only >>> PSTN >>>>> addresses, or also other types. I'm with Flemming on this one; SDP >>> capneg >>>>> framework is already fragmented enough, and limiting the=20 >>>>> connection >>> address >>>>> capability to PSTN addresses only would again be targeted for a=20 >>>>> single >>> use >>>>> case only, whereas we should strive for general solutions. >>>>> >>>>> Simo >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>>>> Behalf >>> Of >>>>> ext Flemming Andreasen >>>>> Sent: 25. maaliskuuta 2013 3:32 >>>>> To: Andrew Allen >>>>> Cc: jonathan@vidyo.com; mmusic@ietf.org;=20 >>>>> christer.holmberg@ericsson.com >>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>> >>>>> >>>>> On 3/24/13 1:33 PM, Andrew Allen wrote: >>>>>> There is also nothing that prevents people from defining their=20 >>>>>> own >>>>> proprietary attributes to do such a thing but that is not part of=20 >>>>> an >>> IETF >>>>> standard and is not approved usage. >>>>> Agreed. >>>>> >>>>>> If we really feel the need to discourage further such usage I=20 >>>>>> suppose >>> we >>>>> could add some text stating that if CCAP s received containing an=20 >>>>> IN net type and an IN net type is present in the corresponding=20 >>>>> Connection Attribute then the CCAP attribute MUST be ignored. >>>>> I think that gets complicated quickly for a questionable gain. I'd=20 >>>>> prefer the "MUST NOT" described below with an explanation as to=20 >>>>> why it's there; as you note, ultimately people either decide to be=20 >>>>> spec compliant or not. >>>>> >>>>> -- Flemming >>>>>> That way compliant implementations would not perfom the=20 >>>>>> discouraged >>>>> behavior. >>>>>> Andrew >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time >>>>>> To: Christer Holmberg >>>>>> Cc: Jonathan Lennox ; mmusic@ietf.org >>>>> >>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and I= P- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>> On 3/23/13 5:24 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In general I agree that having multiple ways of doing the same=20 >>>>>>> thing >>> is >>>>> not a good thing, and I don't have any strong feelings regarding=20 >>>>> the >>> ccap >>>>> usage. >>>>>>> But, no matter what we say, what would actually prevent people=20 >>>>>>> from >>>>> using ccap, in the same way they are using ANAT and altc? :) >>>>>> There's no port signaling capability with ccap, but other than=20 >>>>>> that, >>> the >>>>>> only thing that prevents people from using this to signal=20 >>>>>> alternative IP-addresses is the existence of a "MUST NOT" in the spe= c. >>>>>> >>>>>> -- Flemming >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on=20 >>>>>>> behalf of >>>>> Jonathan Lennox [jonathan@vidyo.com] >>>>>>> Sent: Friday, 22 March 2013 10:00 PM >>>>>>> To: Flemming Andreasen >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>> Currently, the deployed SIP world has three mechanisms to allow=20 >>>>>>> some >>>>> flavor of negotiation among multiple IP addresses: ICE, altc=20 >>>>> (despite >>> the >>>>> general disapproval of the working group), and ANAT (despite its=20 >>>>> deprecation). >>>>>>> I think that adding ccap as a fourth member of this set would be=20 >>>>>>> a >>>>> terrible idea; and as far as I can tell, no one wants to do that. >>>>> So we need to make it clear that that it MUST NOT be used for that pu= rpose. >>>>>>> In the formulation below, I think I'd say that a given media >>> description >>>>> MUST NOT indicate more than one address with an IN network type,=20 >>>>> across >>> all >>>>> its configurations (actual and potential). >>>>>>> Obviously, different media descriptions (m=3D line blocks) can=20 >>>>>>> have >>>>> different addresses. >>>>>>> In practice, given the port number issue that started this=20 >>>>>>> thread, I >>>>> suspect this means that the SDP offer will need to put the IN=20 >>>>> address in the actual configuration (in the c=3D line), and the PSTN >>>>> address(es) will >>> be >>>>> in the potential configurations. >>>>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> Still waiting for more comments on this, especially from the=20 >>>>>>>> people >>>>> that >>>>>>>> were very vocal in their complaints previously: Now is the time=20 >>>>>>>> to >>>>> speak up. >>>>>>>> Regardless, a few comments on the below: >>>>>>>> 1) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>>> more >>> "IP4" >>>>>>>> addresses in a given SDP. >>>>>>>> 2) It allows the use of "ccap" to be used to indicate one or=20 >>>>>>>> more >>> "IP6" >>>>>>>> addresses in a given SDP. >>>>>>>> >>>>>>>> Nit-picking a bit on the actual text, which I think is important: >>>>>>>> The "ccap" attribute is not what is being to select between=20 >>>>>>>> different IP-addresses; the use of a "ccap" attribute in a=20 >>>>>>>> potential >>>>> configuration >>>>>>>> ("pcfg") is what is being used for this. Is the restriction=20 >>>>>>>> that we >>>>> want >>>>>>>> here: >>>>>>>> a) A potential configuration MUST NOT reference more than one "cca= p" >>>>>>>> attribute with a network type of "IN" ? >>>>>>>> b) All potential configurations for a particular media=20 >>>>>>>> description >>> MUST >>>>>>>> NOT reference more than one "ccap" attribute with a network=20 >>>>>>>> type of >>>>> "IN" ? >>>>>>>> c) Something else ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote: >>>>>>>>> I am OK with either of these proposals >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>>> On >>>>> Behalf Of Simo.Veikkolainen@nokia.com >>>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM >>>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org >>>>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>>>>>> IP- >>>>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> I went through the discussion, and my reading is that there is >>>>> agreement on not allowing ccap to be used for alternative IP=20 >>>>> address negotiation. >>>>>>>>> That could be made clear in the text e.g. by modifying the=20 >>>>>>>>> second >>>>> sentence Flemming quoted to read: >>>>>>>>> >>>>>>>>> The 'ccap' attribute MUST NOT be used to select >>>>>>>>> between different IP connection addresses (e.g. between >>>>>>>>> "IP4" and "IP6" address families or different IP address= es >>>>>>>>> within the same IP address family). >>>>>>>>> >>>>>>>>> >>>>>>>>> The ccap attribute should be able to carry either an IP or=20 >>>>>>>>> PSTN >>>>> address; that way either a PSTN or an IP bearer could be offered=20 >>>>> as the highest priority configuration (in the "m=3D" line). =20 >>>>> However, if we want >>> to >>>>> clarify the intended use of ccap, we could modify the first=20 >>>>> sentence to >>>>> read: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended for offering >>>>>>>>> alternative connection addresses where the >>>>>>>>> is "IN" or "PSTN", i.e. selecting between an IP based >>>>>>>>> bearer or a circuit-switched bearer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Simo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 >>>>>>>>> On >>>>> Behalf Of ext Flemming Andreasen >>>>>>>>> Sent: 19. maaliskuuta 2013 8:24 >>>>>>>>> To: mmusic >>>>>>>>> Subject: [MMUSIC] Connection Data Capability (ccap) and=20 >>>>>>>>> IP-addresses >>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> As you may have seen, there has recently been some list=20 >>>>>>>>> discussion >>> on >>>>> the "connection data capability" defined in >>>>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread=20 >>>>>>>>> in=20 >>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.h >>>>>>>>> t >>>>>>>>> ml) >>>>>>>>> >>>>>>>>> To recap, the connection data capability ("ccap") provides >>> capability >>>>> negotiation capabilities for what amounts to the "c=3D" line in=20 >>>>> regular >>> SDP, >>>>> and as such enables negotiation of network type (such as "IN") and >>>>> IP- address information (v4 and v6 addresses). The Standards Track=20 >>>>> mechanism for negotiating and determining alternative IP-address=20 >>>>> information today >>> is >>>>> ICE, and hence the draft currently includes the following wording: >>>>>>>>> >>>>>>>>> The 'ccap' capability attribute is intended to >>>>>>>>> be used only when there is no other mechanism available = for >>>>>>>>> negotiating alternative connection address=20 >>>>>>>>> information, such >>> as >>>>> when >>>>>>>>> the is different among the alternative=20 >>>>>>>>> addresses >>> (e.g. >>>>>>>>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used= in >>>>>>>>> situations where an existing mechanism (such as Interact= ive >>>>>>>>> Connectivity Establishment (ICE) [RFC5245]) can be=20 >>>>>>>>> used to >>>>> select >>>>>>>>> between different connection addresses (e.g. "IP4" and = "IP6" >>> or >>>>>>>>> different IP addresses within the same IP address family= ). >>>>>>>>> >>>>>>>>> >>>>>>>>> The above text has led to some confusion as to exactly when=20 >>>>>>>>> and what >>>>> "ccap" can be used for. More specifically, is it/should it ever be >>> allowed >>>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under=20 >>>>> what circumstances ? >>>>>>>>> If you have an opinion, please let us know. >>>>>>>>> >>>>>>>>> A couple of points to keep in mind: >>>>>>>>> - The current document has been WGLC'ed without comment ~6=20 >>>>>>>>> months >>> ago. >>>>>>>>> - 3GPP has a dependency on the document (however I'm not sure=20 >>>>>>>>> if >>> that >>>>> dependency includes the above "IN" feature) >>>>>>>>> - The connection data capability is defined in a general=20 >>>>>>>>> manner to >>> be >>>>> generally useful in line with the overall capability negotiation >>> framework >>>>> (as opposed to targeted at one specific use case with one specific >>> value) >>>>>>>>> - There are scenarios where ICE cannot be used, even if=20 >>>>>>>>> implemented >>>>> (e.g. ice-mismatch). >>>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the >>> absence >>>>> of ICE support >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- 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 >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> ----- >>> - >>>>>>>>> This transmission (including any attachments) may contain >>> confidential >>>>> information, privileged material (including material protected by=20 >>>>> the solicitor-client or other applicable privileges), or=20 >>>>> constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information=20 >>>>> from your system. Use, dissemination, distribution, or=20 >>>>> reproduction of this transmission by unintended recipients is not=20 >>>>> authorized and may be unlawful. >>>>>>>>> . >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>> -- >>>>>>> Jonathan Lennox >>>>>>> jonathan@vidyo.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> --- This transmission (including any attachments) may contain=20 >>>>>> confidential >>>>> information, privileged material (including material protected by=20 >>>>> the solicitor-client or other applicable privileges), or=20 >>>>> constitute >>>>> non- >>> public >>>>> information. Any use of this information by anyone other than the >>> intended >>>>> recipient is prohibited. If you have received this transmission in >>> error, >>>>> please immediately reply to the sender and delete this information=20 >>>>> from your system. Use, dissemination, distribution, or=20 >>>>> reproduction of this transmission by unintended recipients is not=20 >>>>> authorized and may be unlawful. >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> 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 Apr 26 07:31: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 80BBE21F99D7 for ; Fri, 26 Apr 2013 07:31:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0zkvyboIKzD for ; Fri, 26 Apr 2013 07:31:38 -0700 (PDT) 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 D274621F99D6 for ; Fri, 26 Apr 2013 07:31:37 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id UbDp1l0090cZkys53eXcQQ; Fri, 26 Apr 2013 14:31:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id UeXc1l00n3ZTu2S3WeXcWx; Fri, 26 Apr 2013 14:31:36 +0000 Message-ID: <517A8FC8.3030501@alum.mit.edu> Date: Fri, 26 Apr 2013 10:31:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <5178614A.1090207@alum.mit.edu> <201304251933.r3PJXMnt3433409@shell01.TheWorld.com> In-Reply-To: <201304251933.r3PJXMnt3433409@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=1366986696; bh=jpRQrQgDej2lDRCzu+mxTWHlwew27KBKpZ5YtTurWIQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=btDjWhWbOrgagaQrtOdCXnwQrEwfx8jaPO/vZ0egjb3OeKZ/xD7jR/LRV9LTwp+o5 qlBlaghQjgaQB1FxWqL7KDLsWB1NfITuIs0k9ru5usjrjnHNfzuJZ66fK+NHpI0Th1 1kcE0qwe51/B+x7fMQ2lH59Wdkm5AAFmkIDStndUrgW6b81wLzpSKhXl4O4dCTNkYq vXspw1/2ZAERS6SJ5yxL57VKW8jzMGvBuBF/r0X9BzCHs6Gtgra0nWCzGtSQkT1ka/ 28MPnAUryd6mo1c7XsGY4PAidKv+E89f+qZM90g+7AbpDeip50iYBL4G6tI8W+4CUJ /IR7AL7jyuNrg== Subject: Re: [MMUSIC] Feedback requested on requirements 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, 26 Apr 2013 14:31:38 -0000 On 4/25/13 3:33 PM, Dale R. Worley wrote: >> From: Paul Kyzivat > >>> I mean the latter. The intended parsing is: >>> >>> (non-DES) C5 SBCs generally pass through attributes that they do not... > >> What evidence do you have to support this assertion? >> AFAIK this is far from universally true. > > That's what I've been told, but I haven't surveyed the market very > thoroughly. > > What do you think would be a more accurate statement? I think Hadriel may be better equipped to answer this. Thanks, Paul From ari.keranen@ericsson.com Fri Apr 26 08:02: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 677DA21F9961 for ; Fri, 26 Apr 2013 08:02:48 -0700 (PDT) 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 VeaMOQHz02ko for ; Fri, 26 Apr 2013 08:02:47 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F821F995A for ; Fri, 26 Apr 2013 08:02:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-e8-517a9715b5f9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 06.33.03253.5179A715; Fri, 26 Apr 2013 17:02:46 +0200 (CEST) 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; Fri, 26 Apr 2013 17:02:46 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7B3742878; Fri, 26 Apr 2013 18:02:45 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EB6AF54CF7; Fri, 26 Apr 2013 18:02:44 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F98B546C5; Fri, 26 Apr 2013 18:02:44 +0300 (EEST) Message-ID: <517A9714.1010302@ericsson.com> Date: Fri, 26 Apr 2013 18:02:44 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> <51784997.3040207@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra7Y9KpAg3PXeCwebJ/LaLH/4m1W i6nLH7M4MHtM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgymi+e5itYLZURe+dL6wN jJdEuhg5OSQETCS2zFjNDmGLSVy4t56ti5GLQ0jgFKPEhI2nGUESQgIbGCWOtStBJHYzStz8 9J8VwlnHKHFh1noWCGcFo8SGtkdgs3gFtCUeLpoD1s4ioCpx6PF+ZhCbTcBe4uaE60A1HByi AskS/3d4Q5QLSpyc+YQFxBYR0JPY3zGNEWQms0A/o8S0FRfBZgoLuEvsWf6GHWLZW0aJru1/ wBKcAr4SMy6dB+tmFrCVuDDnOpQtL9G8dTYzxHNqElfPbWKG+EdV4uq/V4wTGEVnIVk+C0n7 LCTtCxiZVzGy5yZm5qSXm29iBMbDwS2/DXYwbrovdohRmoNFSZx3hlRloJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbGLpZXhg15HPs8n+9Wv3nNmpHfkH/q/NsV33U11rtpaRralYjN2tii bWBZEfrL8vGWLi7BJ9VaSr0KGW+ftm+ujdwY+d3gd5DNzOV9dyQrhCVOCT88KVH682/ME6tb hSXCs20ZlNdvu7RQ/fCX7ekb32juUFq3boVpRLFnvH/3uyUGet2bo0OVWIozEg21mIuKEwGv 0PESVQIAAA== Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 26 Apr 2013 15:02:48 -0000 On 4/25/13 10:55 AM, Ali C. Begen (abegen) wrote: > > On Apr 25, 2013, at 6:07 AM, Ari Keränen wrote: > >> On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote: >>> >>> On Apr 24, 2013, at 7:27 AM, Ari Keränen >>> wrote: >>> >>>> Hi, >>>> >>>> I reviewed the draft and noticed that in the intro section you >>>> mention a possible DoS attack using the delayed duplication >>>> functionality, but it's not discussed at all in the security >>>> considerations section. Should that be addressed too? >>>> >>> >>> Really? the whole section talks about what could happen if someone >>> could modify the SDP (number of dup streams, delays, etc.). >>> Especially the last paragraph mentions this. is it not clear? >> >> Not really. I guess I was expecting something more for a "new series of denial-of-service attacks" than what was described in the security section. To make this more clear, perhaps you could use the term DoS also in the security section, where applicable. >> >> Especially the last section talks about software bug or misconfiguration, but couldn't an active attacker also do this? >> > > I will change the text as follows. let me know if there are objections. > > OLD: > > Another security risk is due to possible software misconfiguration or > a software bug where a large number of duplicates could be > unwillingly signaled in the 'duplication-delay' attribute. In > applications where this attribute is to be used, it is a good > practice to put a hard limit both on the number of duplicate streams > and the total delay introduced due to duplication regardless of what > the SDP description specifies. > > NEW: > > Another security risk is due to possible software misconfiguration or > a software bug where a large number of duplicates could be > unwillingly signaled in the 'duplication-delay' attribute. Similarly, an attacker can use this attribute to start a denial-of-service attack by signaling and sending too many duplicated streams. In > applications where this attribute is to be used, it is a good > practice to put a hard limit both on the number of duplicate streams > and the total delay introduced due to duplication regardless of what > the SDP description specifies. > What I was thinking is that can an attacker trick someone supporting this feature into sending big set of duplicate streams (instead of just a single stream) to a target? That is, is there possible amplification due to this extension? Probably not? Or is there some additional DoS risk for signaling duplicate streams and then sending them (as the NEW text says) - instead of just sending if you can do that anyway? I'm guessing no.. If those aren't big DoS attack concerns, probably the first part of the security considerations is actually more DoS'ish. If that's the case, then maybe modify the text with something like: OLD However, these require intercepting and rewriting the packets carrying the SDP [...] NEW However, this kind of DoS attacks require intercepting and rewriting the packets carrying the SDP [...] Or maybe the intro text just makes one more worried than you actually need to be with this extension. Cheers, Ari From pkyzivat@alum.mit.edu Fri Apr 26 08:13: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 BA0ED21F995C for ; Fri, 26 Apr 2013 08:13:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO2h+wAYHhzt for ; Fri, 26 Apr 2013 08:13:24 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4F21F9940 for ; Fri, 26 Apr 2013 08:13:22 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id Uc5g1l0031GhbT85DfDNMk; Fri, 26 Apr 2013 15:13:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id UfDN1l00Q3ZTu2S3TfDNYj; Fri, 26 Apr 2013 15:13:22 +0000 Message-ID: <517A9991.3060901@alum.mit.edu> Date: Fri, 26 Apr 2013 11:13:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> <201304251934.r3PJYupZ3410480@shell01.TheWorld.com> In-Reply-To: <201304251934.r3PJYupZ3410480@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=1366989202; bh=9JTE4FtVgizA6kqjYZPwdw0mM9In47UHyPxWNWwoI4Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T+5jdxzASQLjNe2mShQ1PIMfi9iMaXH/Lko1ENjcmRmC32FRfaIdIHwqWD9eGxPtw +0Ygv3Yh6+huQNpUoigwZQjWVyk/4nzTQBIgk+Zx5fWaR7NhFCLjHqMmKwuRa21i2L Gq1J0zlsjR1Qngm9c9ESaaWH5PUiob5dkOmWvtkqSAb0gUHBBBkTXY50U03QRzeWgY AqJ/lDY47+kRjodi+yyZWUj67FphmNPeCovj+p83AU2CK7wulO0c2nSvK7/V6nSzp4 B5d3Iz9bR4Tw1RYzhO1GqEkO5TX8jp2mgl2eFxCjyelGS29+ToE3jbF8/QPFUow8oy guU0kbFjegNcQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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: Fri, 26 Apr 2013 15:13:24 -0000 Inline On 4/25/13 3:34 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> This has come up in CLUE, and pertains to cases where not all media >> processing equipment is at the same address. In such cases bundling may >> be supported, but more than one bundle may be required. >> >> When this happens on the offering end the offerer can propose multiple >> bundles from the beginning. But when it is the answerer that needs >> things in separate bundles then it will need to "split" (partition) the >> offered bundle into multiple bundles. You can view this as a variant of >> (1)+(3) below. > > Some further thoughts on splitting an offered bundle: > > One consideration is that when the answerer wants to split an offered > bundle, how does it do so in a way that takes into account what the > offerer wants? > > For instance: > > 1. A offers a bundle 1,2,3,4. > > 2. B cannot bundle 3,4 with 1,2. > > 3. So B replies with bundle 1,2 and rejects 3,4 (or accepts them > unbundled). > > 4. Now B offers bundle 1,2 and bundle 3,4. > > 5. A can accept both bundles, so A accepts bundle 1,2 and bundle 3,4. Yeah, this is what I had in mind. > This is somewhat inefficient, since it takes two O/A cycles, but it's > simple, since A doesn't need to signal to B in some way what bundlings > it is willing to accept (e.g., with the hierarchial bundling concept > I've talked about). > > Now suppose A wants to bundle 1,2,3,4 and 5,6,7,8, but B wants to > bundle 1,2,5,6 and 3,4,7,8. The best bundling that can be achieved is > in four pairs, bundle 1,2, bundle 3,4, bundle 5,6, and bundle 7,8. > The best possible pattern for A and B to negotiate this would be > something like this: This is "best" in terms of maximizing the possible bundle sizes while minimizing the number of O/A cycles. > 1. A offers bundle 1,2,3,4 and bundle 5,6,7,8. > > 2. B accepts bundle 1,2 and bundle 5,6 and rejects 3, 4, 7, and 8. > > 3. B offers bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8. > (Although it is willing to bundle 3,4 with 7,8, it remembers from A's > offer that it was unwilling to do so. So B is limited to bundling the > four m= lines into two pairs.) This seems a reasonable strategy. > 4. A accepts bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8. > > We have to make sure that A doesn't attempt to start a third cycle to > see if it can get 1,2 bundled with 3,4, etc. Another possibility would be for B offer bundles 1,2 and 5,6 because they already are in place, and 3,4,7,8 in hopes that it might be acceptable. Then A would refuse 7,8 and start another offer with 7,8 as a separate bundle. This is less efficient in this case, but makes fewer assumptions about the capabilities of A. This seems like a bad choice. I only bring it up because past experience with O/A has shown that it is generally better for an offerer to say what they want without making value judgements about the other party. It becomes especially important if it turns out that the party you are sending the offer to turns out to be different from the one you talked to last. (That probably is nonsense here if these O/A cycles are back-to-back.) In all of the above, the behavior of B only makes sense if B feels it *needs* all of these streams. Another possibility is that B simply rejects the streams it can't accept when bundled as proposed, but doesn't initiate another O/A cycle. Then if A feels those are important, *it* can send another offer with them separately bundled. Having both as options makes things complicated. It could result in both sides waiting for the other to act. And having A make the second offer becomes a sort of "fetch a rock" exercise. But having B make the second offer means it may need to take on faith "I don't know if these streams are important, but my peer wanted them so I'll try to establish them." These cases requiring multiple O/A cycles to get things arranged as desired are starting to smell to me like the kinds of situations that preconditions were designed for. Perhaps a new "bundle" precondition would provide a way to sort out responsibilities and realize when to keep trying and when to give up. But many consider preconditions too heavy weight to use in practice. And they could prove difficult in JSEP. > But if either side initiates a re-offer for some other reason, the new > offer should be the biggest bundling the offerer is willing to > support. You mean, in the above case, after having agreed on bundles 1,2 ; 3/4 ; 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer 1,2,5,6 ; 3,4,7,8,9 ??? I *think* the new offer should include the new bundles in their current operational form, with only one address/port per bundle. Doing otherwise would disrupt the functioning of the current streams. Stream 9 could be added to one of the existing bundles in the offer, but should have a separate address/port. That will probably break a scenario that is trying to do a 3pcc transfer. I suspect that doing such a thing with bundled streams is going to be *hard*, and will need to be considered separately. Thanks, Paul From abegen@cisco.com Fri Apr 26 08:15: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 95F3121F9029 for ; Fri, 26 Apr 2013 08:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 iOiXZy39v8Rp for ; Fri, 26 Apr 2013 08:14:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5F121F97F7 for ; Fri, 26 Apr 2013 08:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4101; q=dns/txt; s=iport; t=1366989299; x=1368198899; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=onImBVkDZqkkzygqggCQdmUa/y9EXjw3bGL2ufbaMvo=; b=I4/0mAuylIOxGAMaO7/e6zKXmcqqQd8eJFZMu5mJbNgOCyA0kZG/t86Q yyjL6DPXeFLB+WkXKixbQ4PrjyswiO73JkIKHb9BwR+/WOQ1+lHIDwhDR t6G2DHfyaehBnwKFVFO3f0Phqd1zxi/LsVNWsofNlklotIjjT5WxC9hQQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAA6ZelGtJXG8/2dsb2JhbABRgmYhvm+BAhZ0gh8BAQEDAXkFCwIBCBgKJDIlAgQOBQiIBgYBvwuNW4EEAjEHgm1hA4han2yDDoFrPQ X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="203449743" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2013 15:14:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3QFEw1i006367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 15:14:58 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 10:14:58 -0500 From: "Ali C. Begen (abegen)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01 Thread-Index: AQHOMh+OrJd+p16ntUKckcdJFFsN55jk0xuAgACHcACAAPSDgIAAtQcAgAIJswCAAANrAA== Date: Fri, 26 Apr 2013 15:14:58 +0000 Message-ID: References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> <51784997.3040207@ericsson.com> <517A9714.1010302@ericsson.com> In-Reply-To: <517A9714.1010302@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99731DB0D572C24F98180D0B6311E49A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 26 Apr 2013 15:15:00 -0000 On Apr 27, 2013, at 12:02 AM, Ari Ker=E4nen wrot= e: > On 4/25/13 10:55 AM, Ali C. Begen (abegen) wrote: >>=20 >> On Apr 25, 2013, at 6:07 AM, Ari Ker=E4nen wr= ote: >>=20 >>> On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote: >>>>=20 >>>> On Apr 24, 2013, at 7:27 AM, Ari Ker=E4nen >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I reviewed the draft and noticed that in the intro section you >>>>> mention a possible DoS attack using the delayed duplication >>>>> functionality, but it's not discussed at all in the security >>>>> considerations section. Should that be addressed too? >>>>>=20 >>>>=20 >>>> Really? the whole section talks about what could happen if someone >>>> could modify the SDP (number of dup streams, delays, etc.). >>>> Especially the last paragraph mentions this. is it not clear? >>>=20 >>> Not really. I guess I was expecting something more for a "new series of= denial-of-service attacks" than what was described in the security section= . To make this more clear, perhaps you could use the term DoS also in the s= ecurity section, where applicable. >>>=20 >>> Especially the last section talks about software bug or misconfiguratio= n, but couldn't an active attacker also do this? >>>=20 >>=20 >> I will change the text as follows. let me know if there are objections. >>=20 >> OLD: >>=20 >> Another security risk is due to possible software misconfiguration or >> a software bug where a large number of duplicates could be >> unwillingly signaled in the 'duplication-delay' attribute. In >> applications where this attribute is to be used, it is a good >> practice to put a hard limit both on the number of duplicate streams >> and the total delay introduced due to duplication regardless of what >> the SDP description specifies. >>=20 >> NEW: >>=20 >> Another security risk is due to possible software misconfiguration or >> a software bug where a large number of duplicates could be >> unwillingly signaled in the 'duplication-delay' attribute. Similarly,= an attacker can use this attribute to start a denial-of-service attack by = signaling and sending too many duplicated streams. In >> applications where this attribute is to be used, it is a good >> practice to put a hard limit both on the number of duplicate streams >> and the total delay introduced due to duplication regardless of what >> the SDP description specifies. >>=20 >=20 > What I was thinking is that can an attacker trick someone supporting this= feature into sending big set of duplicate streams (instead of just a singl= e stream) to a target? That is, is there possible amplification due to this= extension? Probably not? If someone is signaling and sending way too many streams to you, you gotta = discontinue this stream. E.g., if you see an SDP that signals 5 dup streams= , there is likely something wrong. This could be a bug or an attack, either= case, you should not accept this stream. I think this is pretty obvious.=20 >=20 > Or is there some additional DoS risk for signaling duplicate streams and = then sending them (as the NEW text says) - instead of just sending if you c= an do that anyway? I'm guessing no.. If SDP is hacked into, sky is the limit in terms of what harm you can cause= .=20 >=20 > If those aren't big DoS attack concerns, probably the first part of the s= ecurity considerations is actually more DoS'ish. If that's the case, then m= aybe modify the text with something like: >=20 > OLD > However, these > require intercepting and rewriting the packets carrying the SDP [...] > NEW > However, this kind of DoS attacks > require intercepting and rewriting the packets carrying the SDP [...] >=20 I would not change this text since it is a pretty standard text for sdp att= ributes. >=20 > Or maybe the intro text just makes one more worried than you actually nee= d to be with this extension. >=20 >=20 > Cheers, > Ari From dohsu@cisco.com Fri Apr 26 08: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 095B221F99E4 for ; Fri, 26 Apr 2013 08:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 5UPxZP97Io92 for ; Fri, 26 Apr 2013 08:27:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 93BD821F99B0 for ; Fri, 26 Apr 2013 08:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1039; q=dns/txt; s=iport; t=1366990049; x=1368199649; h=from:to:cc:subject:date:message-id:mime-version; bh=Dbp7c+JiKiqynwKWxcQHZFJX2FvMKtAeUuVJeH76ujA=; b=MbDy/IIqXFQcBpm3mKbAlQU31G79xOcnfQJY8/+nIGg4hMN2GmMjxG1p zV7zAulO0dGdDDJ7vAAN7dANkNgiNK48fPFk9YlO2caxYxyjWQCNpEyzP 6kj6kHWzT+TNOhxbruxMNukp+APBL4ULOsdEIkmI6tLZRDAxnlsat6Fa0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAIScelGtJV2Z/2dsb2JhbABRgkNEvm+BAhZ0giEBBHkSAQsBAhxWJwQBDQ2IDL8SjmExgnRhA4han2yDDoIo X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208,217";a="203291230" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Apr 2013 15:27:13 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3QFRDK1001275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 15:27:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 10:27:13 -0500 From: "Dong Hsu (dohsu)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Ali C. Begen (abegen)" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-01 Thread-Index: AQHOQpKGd/E6IJy2OkqjvOgskmrVbw== Date: Fri, 26 Apr 2013 15:27:12 +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.2.130206 x-originating-ip: [10.131.69.118] Content-Type: multipart/alternative; boundary="_000_CB7FC00E9258DF42A7D6F57D4DCFD90203A35ED7xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: mmusic Subject: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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, 26 Apr 2013 15:27:45 -0000 --_000_CB7FC00E9258DF42A7D6F57D4DCFD90203A35ED7xmbrcdx14ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have received this draft and do not have any comments as right now. Best Regards, -- Dong --_000_CB7FC00E9258DF42A7D6F57D4DCFD90203A35ED7xmbrcdx14ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <59AC97146CD4AC4F9B5F6C34725B013A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I have received this draft and do not have any comments as right now.<= /div>

Best  Regards,

-- Dong
--_000_CB7FC00E9258DF42A7D6F57D4DCFD90203A35ED7xmbrcdx14ciscoc_-- From pkyzivat@alum.mit.edu Fri Apr 26 08:27: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 7EBA521F99ED for ; Fri, 26 Apr 2013 08:27:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbPoZBcyjVOa for ; Fri, 26 Apr 2013 08:27:48 -0700 (PDT) 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 D269B21F9871 for ; Fri, 26 Apr 2013 08:27:47 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id UaQz1l00A1swQuc53fTnP4; Fri, 26 Apr 2013 15:27:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id UfTn1l00B3ZTu2S3bfTnP0; Fri, 26 Apr 2013 15:27:47 +0000 Message-ID: <517A9CF2.2080504@alum.mit.edu> Date: Fri, 26 Apr 2013 11:27:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> In-Reply-To: <201304252219.r3PMJv6C3392749@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=1366990067; bh=P56SeGv3cF78lN9pR/5AHN2WO/MmQcd9VAULJvvfA78=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fHw0+Uv5JtsO5WH2n/ujslV8INdIqlWXQzaThAqFRVNkdiDA4UnlJ0vrUqt9xZw8q jEyOCHtHx8lXtSnsn2LMEwqTlVcyd89U/nsjUtepH2sDPE2GUUdilfkrwd/ky80kz7 Z8FjlnXsiPcJrWX7s+5FA+VVXcpwdPedKi4O5SGmFhXW1N1VKQuHfVtmTltblMcyHg jwRyClOrt8TFUBAWCf8BdouLtH0utynux5E2lmmfjMkJGfvaPAyi9WruzMb9H/Oo4t Uqn08QKTwjOS50qPVGdyzv2NA7etUO2dutY0ojtlwfYegIOGvF5uJ2t9y6eecRcwdV eC9Byuu2ybv3Q== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 26 Apr 2013 15:27:48 -0000 On 4/25/13 6:19 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> Yes - we need a way to signal the demux mechanism to be used. >> (Unless there is only one possibility. And we have already disproved that.) > > We could use different group "semantics" values to indicate the > multiplexing mechanism. We *could*. But I suspect it is a sub-optimal mechanism. It doesn't scale very well. It appears that there can be multiple demux mechanisms in use within the same bundle. At least, there can be one for distinguishing data channel packets from RTP packets. And then some other mechanism for sorting out the RTP packets. And it *may* make sense to use SSRC to demux some RTP, and the new RTP extension to sort out some others. (Whether these should coexist is TBD.) So I suspect that the demux indication should be signaled per-m-line, with some rules for when/how the different mechanisms can coexist. > One endpoint could probe the other to > discover which mechanisms it supplies by offering a collection of > bundles containing no constituents, one for each mechanism. The > answer will show which mechanisms the answerer supports. This seems a good argument for not going this way! Thanks, Paul From ari.keranen@ericsson.com Fri Apr 26 08:33: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 4EDA921F98F5 for ; Fri, 26 Apr 2013 08:33:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJKFcycVb8Yh for ; Fri, 26 Apr 2013 08:33:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2D21F9607 for ; Fri, 26 Apr 2013 08:33:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-6b-517a9e614cf8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0D.33.19728.16E9A715; Fri, 26 Apr 2013 17:33:54 +0200 (CEST) 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; Fri, 26 Apr 2013 17:33:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7B6BE2878; Fri, 26 Apr 2013 18:33:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EBAE654CF7; Fri, 26 Apr 2013 18:33:52 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 80493546C5; Fri, 26 Apr 2013 18:33:52 +0300 (EEST) Message-ID: <517A9E60.3010703@ericsson.com> Date: Fri, 26 Apr 2013 18:33:52 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <515F03EF.1030100@ericsson.com> <51770AE0.4030800@ericsson.com> <517849AB.2030703@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW7SvKpAg58uFg+2z2W02P3gO5PF 1OWPWRyYPab83sjqsWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlzPy+h7ngPF/F1M2v2RoY L3N3MXJySAiYSKxdeJURwhaTuHBvPVsXIxeHkMApRokJS1ewQzgbGCV2H13JDOHsZpS4dnce VNk6Rok/t2dBOSsYJXpPbWIHGcYroC1x80QbG4jNIqAqsfTsDjCbTcBe4uaE60A1HByiAskS /3d4Q5QLSpyc+YQFxBYR0JPY3zEN7CZmgYmMEh9+hYHYwgIeEr+vX2GB2PUWKN71AWwmp4Cv xI0lP9ghGmwlLsy5zgJhy0s0b53NDPGcmsTVc5vAbCGge67+e8U4gVF0FpLds5C0z0LSvoCR eRUje25iZk56udEmRmA0HNzyW3UH451zIocYpTlYlMR5Z0hVBgoJpCeWpGanphakFsUXleak Fh9iZOLglGpgXPMub5FJuC2D6Byxv+8uzwrdxXkx8NzNk6e4JnjdyuxuePpXhefMS/MgHlZ1 p7WXG4uuXvD14tkfFxPT1DZ/++9CRQnWrzMLzl5NYLkrZ+rbk/o7clPbPK6uV/OUE6/ZyeZM cjS4nflLXFhh0jynK9ElxWYulw+bpTXELmBoWyg5wfxspWONEktxRqKhFnNRcSIAFTnXiVQC AAA= Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-duplication-grouping-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, 26 Apr 2013 15:33:56 -0000 On 4/25/13 11:19 AM, Ali C. Begen (abegen) wrote: > > On Apr 25, 2013, at 6:07 AM, Ari Keränen wrote: > >> On 4/24/13 9:36 AM, Ali C. Begen (abegen) wrote: >>> >>> On Apr 24, 2013, at 7:27 AM, Ari Keränen wrote: >>>> Alternatively, one could be more explicit >>>> and insert an "a=duplication-delay:0" line before the "a=mid:Ch1" >>>> line. >>>> >>>> This is quite vague. Could add an RFC2119 SHOULD/MUST/RECOMMEND here (and same in the next section) and tell when/why (not) to do it. >>>> >>> >>> I think a MUST would be too strong since it is not really a must. I also think making it a SHOULD would require us to explain when it could be ignored (which is really any time since nothing will break if it is ignored). Putting it would be more like informational purposes. I think "MAY" would be appropriate here. >>> >>> Would that address your concern? >> >> I think the important part is to tell why you should (or may) put it there. Is it, e.g., informational for a human reading the SDP or is there some corner case where this would help? > > It is informational line for humans. Are you ok if we say: > > "Alternatively, one MAY explicitly insert an "a=duplication-delay:0" line before ... for informational purposes." > > >> If there's no real value adding it there, perhaps it's better to not talk about this alternative at all since it will potentially just results in unnecessary differences how it ends up implemented. >> > Even if we dont mention this, one can use this and the SDP would be valid unless we say one MUST NOT be explicit (I think this would be worse to say) Sure, and I wouldn't say MUST NOT either. IMHO, the comment makes the text a bit confusing. However, if you see value of having it there, your proposed text work for me. Cheers, Ari From ari.keranen@ericsson.com Fri Apr 26 08:34: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 DDDCC21F99CD for ; Fri, 26 Apr 2013 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 ehPrMlEm3GLY for ; Fri, 26 Apr 2013 08:34:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 84D2B21F99F8 for ; Fri, 26 Apr 2013 08:34:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-76-517a9e663a26 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FE.33.19728.66E9A715; Fri, 26 Apr 2013 17:34:00 +0200 (CEST) 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; Fri, 26 Apr 2013 17:33:58 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8660F2878; Fri, 26 Apr 2013 18:33:58 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0369354CF7; Fri, 26 Apr 2013 18:33:58 +0300 (EEST) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AF770546C5; Fri, 26 Apr 2013 18:33:57 +0300 (EEST) Message-ID: <517A9E65.8060709@ericsson.com> Date: Fri, 26 Apr 2013 18:33:57 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <515F03F3.6070400@ericsson.com> <51770ADD.6080702@ericsson.com> <51784997.3040207@ericsson.com> <517A9714.1010302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+JvrW7GvKpAg+7F/BYPts9ltNh/8Tar xdTlj1kcmD2m/N7I6rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZZzs3sFecEK+Yuq1A0wN jN2SXYycHBICJhKbTm1ngrDFJC7cW8/WxcjFISRwilHizZuTTBDOBkaJnrfHWSCc3YwSc9f0 MUM46xgl/h+cxQrhrGCU6LzdytjFyMHBK6At8W6NBshcFgFViXnTZoDtYBOwl7g54To7SImo QLLE/x3eIGFeAUGJkzOfsIDYIgJ6Evs7pjGCjGQW6GeUmLbiIjtIQljAXWLP8jfsELvOMUmc 29DLBpLgFPCV+LihgxHEZhawlbgw5zoLhC0v0bx1NjPEc2oSV89tArOFgA66+u8V4wRG0VlI ls9C0j4LSfsCRuZVjOy5iZk56eVGmxiB8XBwy2/VHYx3zokcYpTmYFES550hVRkoJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbGhwUUnmi9Q06YqblJk1V3BLzeZvK6kTJyYtfJom1Qf79ae WeInT30tMfjz2qx9oger771zj6aF8tbIq+lZ/Jz0b86SEOOlt+p+np+8PdX2nVRdXonU2Z1f 2X732Du8mmMf4d+9/8aPP0yH09tKZmbefuPG+dIlbpX45fqWpVXc/QVFVzqWH1JiKc5INNRi LipOBAALdEx7VQIAAA== Cc: "" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 26 Apr 2013 15:34:02 -0000 On 4/26/13 6:14 PM, Ali C. Begen (abegen) wrote: > > On Apr 27, 2013, at 12:02 AM, Ari Keränen wrote: > >> On 4/25/13 10:55 AM, Ali C. Begen (abegen) wrote: >>> >>> On Apr 25, 2013, at 6:07 AM, Ari Keränen wrote: >>> >>>> On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote: >>>>> >>>>> On Apr 24, 2013, at 7:27 AM, Ari Keränen >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I reviewed the draft and noticed that in the intro section you >>>>>> mention a possible DoS attack using the delayed duplication >>>>>> functionality, but it's not discussed at all in the security >>>>>> considerations section. Should that be addressed too? >>>>>> >>>>> >>>>> Really? the whole section talks about what could happen if someone >>>>> could modify the SDP (number of dup streams, delays, etc.). >>>>> Especially the last paragraph mentions this. is it not clear? >>>> >>>> Not really. I guess I was expecting something more for a "new series of denial-of-service attacks" than what was described in the security section. To make this more clear, perhaps you could use the term DoS also in the security section, where applicable. >>>> >>>> Especially the last section talks about software bug or misconfiguration, but couldn't an active attacker also do this? >>>> >>> >>> I will change the text as follows. let me know if there are objections. >>> >>> OLD: >>> >>> Another security risk is due to possible software misconfiguration or >>> a software bug where a large number of duplicates could be >>> unwillingly signaled in the 'duplication-delay' attribute. In >>> applications where this attribute is to be used, it is a good >>> practice to put a hard limit both on the number of duplicate streams >>> and the total delay introduced due to duplication regardless of what >>> the SDP description specifies. >>> >>> NEW: >>> >>> Another security risk is due to possible software misconfiguration or >>> a software bug where a large number of duplicates could be >>> unwillingly signaled in the 'duplication-delay' attribute. Similarly, an attacker can use this attribute to start a denial-of-service attack by signaling and sending too many duplicated streams. In >>> applications where this attribute is to be used, it is a good >>> practice to put a hard limit both on the number of duplicate streams >>> and the total delay introduced due to duplication regardless of what >>> the SDP description specifies. >>> >> >> What I was thinking is that can an attacker trick someone supporting this feature into sending big set of duplicate streams (instead of just a single stream) to a target? That is, is there possible amplification due to this extension? Probably not? > > If someone is signaling and sending way too many streams to you, you gotta discontinue this stream. E.g., if you see an SDP that signals 5 dup streams, there is likely something wrong. This could be a bug or an attack, either case, you should not accept this stream. I think this is pretty obvious. > >> >> Or is there some additional DoS risk for signaling duplicate streams and then sending them (as the NEW text says) - instead of just sending if you can do that anyway? I'm guessing no.. > > If SDP is hacked into, sky is the limit in terms of what harm you can cause. > >> >> If those aren't big DoS attack concerns, probably the first part of the security considerations is actually more DoS'ish. If that's the case, then maybe modify the text with something like: >> >> OLD >> However, these >> require intercepting and rewriting the packets carrying the SDP [...] >> NEW >> However, this kind of DoS attacks >> require intercepting and rewriting the packets carrying the SDP [...] >> > > I would not change this text since it is a pretty standard text for sdp attributes. > OK, in that case the proposed text works for me. Cheers, Ari From pkyzivat@alum.mit.edu Fri Apr 26 09:59: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 BDF6A21F9A6E for ; Fri, 26 Apr 2013 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.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 1TdjOh7ky-aF for ; Fri, 26 Apr 2013 09:59:04 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 5E32121F99D7 for ; Fri, 26 Apr 2013 09:58:59 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Ufvo1l0030SCNGk5BgyyeP; Fri, 26 Apr 2013 16:58:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id Ugyy1l00o3ZTu2S3Vgyyhs; Fri, 26 Apr 2013 16:58:58 +0000 Message-ID: <517AB252.90602@alum.mit.edu> Date: Fri, 26 Apr 2013 12:58:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C361D3A@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=1366995538; bh=gSPaPgqasUNV969mgE5YGs2NmlYIibivKaLZhEWrErk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AG10o7BCCHz9BskNH1bTwxLsrs9eRvDlydlGCsrTbsy3cgPmYvt6gyP2J4uagxnG0 MsuVe5v2H8hFXPNx+uf1o0r6KzjQ0ZKT2r6M/nGH92bv5TcCou6RNWXMvDpjGbYKNv NSQL5iFhIddOennGd6760FgJElJEKiZODUdOIwWlOFwNWrAY5gpXvhypSYx4zqIoS7 06Hihr7T1xUeo+ymiPTRYSRITaPbqGKTUrRr/DNMt1/cVVXDyEvz+KfxP4Q4751zVD qtRQw+8pf1unSMW8b734ifbv/w2Es/+Nx5F5W+yqDy+uFMbxBnYsOdydQqZR7gJ6rR AwmqSUi3ShLaQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 26 Apr 2013 16:59:05 -0000 On 4/26/13 3:44 AM, Christer Holmberg wrote: > Hi, > >>> Yes - we need a way to signal the demux mechanism to be used. >>> (Unless there is only one possibility. And we have already disproved >>> that.) >> >> We could use different group "semantics" values to indicate the multiplexing mechanism. One endpoint could probe the other to discover >> which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism. The answer will show >> which mechanisms the answerer supports. > > My idea was the endpoint simply lists the media description proto values that it is capable of multiplexing for a given 5-tuple: > > Example: a=muxcap: RTP/AVP, SCTP/DTLS > > ...or something like that. That is sufficient *if* there is a single mux/demux algorithm per proto. But I don't think that is true. I think we will need to signal this per-m-line, and specify the demux algorithm(s) for streams that bind to that m-line. > Of course, an endpoint needs to be able to multiplex all media that it inserts in a bundle group. But, it may not always insert m- lines for everything it is able to multiplex, so I think an explicit indication would be good. There may be more than one stream per m-line, but I think we can assume that every stream binds to one m-line. > It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP). Unfortunately SDP has a pretty confusing idea of "transport". The proto field identifies a whole stack of protocol layers. Yes, the lowest layer in the stack for each bundled m-line must be the same. There are more constraints than that. What comes to mind is: - factor the protos of all the m-lines, forming nested groups that share some common lower layers. - for each group that share some common lower layers, a demux algorithm is required that allows packets to be assigned to the appropriate member of that group. - the above is applied recursively until packets have been assigned to a particular m-line. For instance, consider the following: ... c=IN IP4 host.biloxi.com a=group:BUNDLE m1 m2 m3 m4 m=audio 20000 RTP/SAVPF 0 a=mid:m1 a=ssrc:12345 cname:user@example.com a=max-send-ssrc:{*:1} a=max-recv-ssrc:{*:1} ... m=video 20000 RTP/SAVPF 96 98 a=mid:m2 a=ssrc:5678 cname:user@example.com a=max-send-ssrc:{*:1} a=max-recv-ssrc:{*:1} ... m=video 20000 RTP/SAVPF 96 98 a=mid:m3 a=max-send-ssrc:{*:4} a=max-recv-ssrc:{*:4} ... m=application 20000 DTLS/SCTP ... a=mid:m4 ... We have four bundled m-lines. We have one proto (RTP/SAVPF) in three m-lines, and another (DTLS/SCTP) in the other m-line. From a protocol layering perspective we have: m1 m2 m3 m4 ===== ===== ===== ==== SAVPF SAVPF SAVPF SCTP RTP RTP RTP DTLS UDP UDP UDP UDP IP IP IP IP So, the first demux that must be done is to distinguish RTP from DTLS. DTLS has been designed to have a field that distinguishes it from RTP/RTCP/ICE, so that can perhaps be considered a default demux algorithm for that. Because there is only one SCTP m-line, that is enough to identify those packets that should be bound to m4. But we need to use something else to sort out the RTP. In this example, payload type can be used to distinguish audio from video. But there may be cases where that isn't possible. If we want to allow this mechanism, then perhaps we need some way to signal that it should be used. Or *maybe* we could count on it being inferred. Assuming that is used, then it is sufficient to identify those packets that belong to m1. Or, because m1 is marked as having at most one ssrc, and the ssrc value (1234) is specified, that could be used to bind packets to m1. Similarly, RTP packets having ssrc=5678 can be bound to m2. m3 supports multiple unspecified SSRCs. Since there is only one m-line that does, all the packets with pt 96 or 98 and with an ssrc other than 1234 or 5678 can be bound to m3. I'm undecided if we can count on inferring this decision logic from existing signaling options, or if we ought to signal the choices more explicitly. Thanks, Paul From christer.holmberg@ericsson.com Fri Apr 26 10:33: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 940F421F9810 for ; Fri, 26 Apr 2013 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ajz2T+IGrJ4a for ; Fri, 26 Apr 2013 10:33:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 923F221F980C for ; Fri, 26 Apr 2013 10:33:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-93-517aba6bb444 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8B.5D.03253.B6ABA715; Fri, 26 Apr 2013 19:33:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 19:33:30 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4ggAB69ACAACdgzw== Date: Fri, 26 Apr 2013 17:33:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu> In-Reply-To: <517AB252.90602@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW72rqpAg/29uhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx5tMz1oLTIhV3r3WxNDDOEuhi5OSQEDCR eH3zOzuELSZx4d56ti5GLg4hgcOMEqcf7GGEcJYwSkycsJ+1i5GDg03AQqL7nzaIKSKgITFp qxqIySygLnF1cRCIKSygK/F4cQxEgZ5Ey4kakOEiAk4S957cZQOxWQRUJd7v+8YIYvMK+Ep0 /26CWtrOJDFrySJGkF5OAS2Jo0+jQWoYgQ77fmoNE4jNLCAucevJfCaIgwUkluw5zwxhi0q8 fPyPFcJWlPj4ah8jRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0L GFlWMbLnJmbmpJebb2IExsbBLb8NdjBuui92iFGag0VJnHeGVGWgkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsayh9qKMzekMTc+37LFtuZDzNldNddSFMu4FavOVx7XumNgfznluPqta7pz 0zMUjD4xuC5TmcDQmt7N967Cb8fjDS2KWZ2Pn2sqKP0XEZpwKlr9ZKPc4yO3Dl4QKKp3OPoo yPNnZMeXE/e3TzrYutaNd3m0fWtVSxafG7NA6Pe//Qm9Tn7uwUosxRmJhlrMRcWJAJZc6Tdb AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 26 Apr 2013 17:33:33 -0000 Hi, >>>> Yes - we need a way to signal the demux mechanism to be used. >>>> (Unless there is only one possibility. And we have already disproved >>>> that.) >>> >>> We could use different group "semantics" values to indicate the multipl= exing mechanism. One endpoint could probe the other to discover >>> which mechanisms it supplies by offering a collection of bundles contai= ning no constituents, one for each mechanism. The answer will show >>> which mechanisms the answerer supports. >> >> My idea was the endpoint simply lists the media description proto values= that it is capable of multiplexing for a given 5-tuple: >> >> Example: a=3Dmuxcap: RTP/AVP, SCTP/DTLS >> >> ...or something like that. > > That is sufficient *if* there is a single mux/demux algorithm per proto. > > But I don't think that is true. I think we will need to signal this > per-m-line, and specify the demux algorithm(s) for streams that bind to > that m-line. I don't it matters if there are multiple algorithms - the important thing i= s that the endpoint is able to mux/demux the specific proto using A algorit= hm. Otherwise, we can have different values, one for each algorithm. Note that = in my example I used to SDP proto values, but we could use whatever. HOWEVER, before we go into the details, I would like to know whether people= generally think we need a mechanism which allows to list the protos an end= point is able to mux/demux. >> Of course, an endpoint needs to be able to multiplex all media that it i= nserts in a bundle group. But, it may not always insert m- lines for everyt= hing it is able to multiplex, so I think an explicit indication would be go= od. > > There may be more than one stream per m-line, but I think we can assume t= hat every stream binds to one m-line. I am not sure I understand what you mean by "binds to one m-line". However, keep in mind there can be multiple streams per m- line already tod= ay (at least for RTP), so it's not something BUNDLE specific :) >> It is important to remember that, whatever you multiplex, all media have= to use the same IP transport (e.g. UDP). > > Unfortunately SDP has a pretty confusing idea of "transport". > The proto field identifies a whole stack of protocol layers. Yes, and therefor, when we say "must use the same protocol", we need to mak= e it clear that we refer to the Protocol value in the IP header - not the p= roto value in the SDP media description :) I will reply to the rest of your e-mail later, because I need a little more= time to read it :) Regards, Christer From dohsu@cisco.com Fri Apr 26 11:06: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 26B4F21F99F9 for ; Fri, 26 Apr 2013 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 fm8MrqysDfXt for ; Fri, 26 Apr 2013 11:06:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 766BE21F99F8 for ; Fri, 26 Apr 2013 11:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=636; q=dns/txt; s=iport; t=1366999599; x=1368209199; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mh+gtZKv6jrcVD3XuHdtw8+pQVr+A9jUHI/cSxDSbv0=; b=bI6VXgy8+8Wa3igJOaa96PQ3llbZlsh9om7gTYx6u0IPJIL+zpehjOcm sOREjB1Rwub3F8K7VFb0A7QpFMkrdkIdQOapvFedG7X1fSm/vXVubDjXc N1Zcb1FLWDYtGIfRmAQh9Yhrxe5W7wVA1WCvOiY8tpMm+lJSFF0/+N18h 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFANrAelGtJV2b/2dsb2JhbABRgwe+coEFFnSCIQEEeRIBKlYlAgQBDQ2IDL8bjmExB4JtYQOIWp9sgw6CKA X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="203353360" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 26 Apr 2013 18:06:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3QI6cbf025964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 18:06:39 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:06:38 -0500 From: "Dong Hsu (dohsu)" To: "Ali C. Begen (abegen)" , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01 Thread-Index: AQHOMh+OrJd+p16ntUKckcdJFFsN55jk0xuAgACHcACAAPSDgIAAtQcAgAIJswCAAANrAP//7OYA Date: Fri, 26 Apr 2013 18:06:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.131.69.118] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 26 Apr 2013 18:06:40 -0000 Here are the comments I have for this draft: 1. In the definition of duplication-delay attribute, it should clearly state that the value is applied to the delay from previous stream. I knew this is explained in the example but should be state here. 2. Can both attributes co-exist in media and session level? If not, please state it somewhere. If so, does session level exceed media level? 3. For multiple delay values, I would prefer to use space to separate multiple values such as a=3Dduplication-delay:50 100 150 This is more inline with other attributes with multiple values in SDP. Best Regards, -- Dong From worley@shell01.TheWorld.com Fri Apr 26 11:22: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 2181321F9A05 for ; Fri, 26 Apr 2013 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 EO3JdPzaPnoi for ; Fri, 26 Apr 2013 11:22:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1F21F9A03 for ; Fri, 26 Apr 2013 11:22:02 -0700 (PDT) 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 r3QIK18E017363; Fri, 26 Apr 2013 14:20:03 -0400 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 r3QIK1Ns3491481; Fri, 26 Apr 2013 14:20:01 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3QIK09C3505700; Fri, 26 Apr 2013 14:20:00 -0400 (EDT) Date: Fri, 26 Apr 2013 14:20:00 -0400 (EDT) Message-Id: <201304261820.r3QIK09C3505700@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Mo Zanaty (mzanaty)" In-reply-to: <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> (mzanaty@cisco.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 26 Apr 2013 18:22:03 -0000 > From: "Mo Zanaty (mzanaty)" > > I agree with the IANA update below for clarity. But practically > speaking, PAYLOAD will never assign another static payload, so we > are effectively limited to the dynamic range for all modern codecs > unless PAYLOAD decides to reallocate 35-63 from static to dynamic. The range 35 to 63 is already available as a secondary dynamic area, given these sentences from RFC 5761 Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. Strictly speaking, the secondary dynamic area is 35-63, along with 20-24, 27, and 29-30. And the static assignments form a tertiary dyanmic area. (As Adam says, make sure your products work even if statically-assigned PTs are assigned to different codecs.) > I > could only see that happening if products really need to support >32 > codecs. (True codecs, not demux IDs for different streams in > bundles.) People say that real products may use as many as 30 codec numbers now, so I'd want to plan for at least 64 PTs being used. Dale From worley@shell01.TheWorld.com Fri Apr 26 11:22: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 F062F21F9A17 for ; Fri, 26 Apr 2013 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 GnkyOdQ+W2qe for ; Fri, 26 Apr 2013 11:22:05 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F121F9A05 for ; Fri, 26 Apr 2013 11:22:04 -0700 (PDT) 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 r3QIKrRq003265; Fri, 26 Apr 2013 14:20:55 -0400 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 r3QIKq4I3494740; Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3QIKq913501941; Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Date: Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Message-Id: <201304261820.r3QIKq913501941@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Magnus Westerlund In-reply-to: <517A23B4.3060801@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? 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, 26 Apr 2013 18:22:06 -0000 > From: Magnus Westerlund > > Regarding the IANA, Mo you have correctly identified the registry as > closed and Adam pointed to the relevant text. Is this level of > indirection so problematic that this registry needs a Note to the effect? (cleaning up my proposal) I use the IANA registries as the reference for how the various number spaces are managed. The current final rows of the Payload Types table read: 35-71 Unassigned 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Unassigned 96-127 dynamic [RFC3551] I find these to be problematic in several ways: 1) RFC 5761 is not mentioned at all, despite that it provides important modifications of the governing text in RFC 3551. This is a practical problem: Note that Adam quoted the text in RFC 3551, not the text in RFC 5761, and the 3551 text is now incorrect. 2) The range that is reserved for RTCP avoidance is not specified correctly. It's true that the rest of the RTCP avoidance range is marked "Unassigned", but in the context of RFC 3551, that suggests that they can be used as a secondary dynamic assignment area. 3) The range 35-71 should be marked more clearly as the secondary dynamic assignment area. Because of this, I suggest the following changes to this registry: 1) The "Reference" section should be changed from "[RFC3551]" to "[RFC5761][RFC3551]". 2) The final rows should be changed to 35-63 Unassigned/secondary dynamic area [RFC5761] 64-71 Reserved for RTCP conflict avoidance [RFC5761] 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Reserved for RTCP conflict avoidance [RFC5761] 96-127 Dynamic [RFC3551] Dale From suhasietf@gmail.com Fri Apr 26 12:32: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 9D93721F99CC for ; Fri, 26 Apr 2013 12:32:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 J0ZBjWQo84vo for ; Fri, 26 Apr 2013 12:32:34 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C10EA21F99AA for ; Fri, 26 Apr 2013 12:32:33 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id e11so2308697wgh.25 for ; Fri, 26 Apr 2013 12:32:33 -0700 (PDT) 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:cc :content-type; bh=A+qg+utu6yIsiPZk5vKDqydtTwrfpsL85EzXj3hyK0E=; b=e2CBk4fjQLxr+934qbVRuyI401bQTwMlRfAdG9JF09OSPnkH7c7eOEqZ/qiRihnJP6 vee6bRlq/bGA5cDoVvhgl0RCstgYH2hixHxi8faXdE7NoZyXS79dCe5S3Dzvfice64r2 dQXqZH9isiQofNx2LLD3p9XNcflJ0sVm/6j4NZRt4rTkUMu4OtBW6IjCe5xv4QESGwBV MaqUtwbkaKTpQTsCOHiu+rSymU9TVFuW1D8A2s+zlVDeZox9qLr369jXbIWc5gWOO0IA qv3o+9vFcHNsbwOgKqNg1/mJMmmved8Xuk4JnI1tr058vsWeN/U463KaAdwl0brS8Wx0 bVow== MIME-Version: 1.0 X-Received: by 10.180.36.205 with SMTP id s13mr6010482wij.31.1367004752962; Fri, 26 Apr 2013 12:32:32 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 12:32:32 -0700 (PDT) Date: Fri, 26 Apr 2013 12:32:32 -0700 Message-ID: From: Suhas Nandakumar To: jdrosen@cisco.com, Gonzalo.Camarillo@ericsson.com Content-Type: multipart/alternative; boundary=e89a8f642b58b4ec5b04db4898b1 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4091 Related) 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, 26 Apr 2013 19:32:34 -0000 --e89a8f642b58b4ec5b04db4898b1 Content-Type: text/plain; charset=ISO-8859-1 Hello Jonathan, Gonzalo This is a request for reviewing the section 10.3 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --e89a8f642b58b4ec5b04db4898b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jonathan, Gonzalo
=A0=A0
This is a req= uest for reviewing the section
=A0
10.3

<= /div>
of the draft
=A0 =A0
draft-nandakumar-mmu= sic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--e89a8f642b58b4ec5b04db4898b1-- From pkyzivat@alum.mit.edu Fri Apr 26 13:27: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 2ECCF21F99BC for ; Fri, 26 Apr 2013 13:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.212 X-Spam-Level: X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Jb3nux9ThTtA for ; Fri, 26 Apr 2013 13:27:56 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id ACC7A21F99BD for ; Fri, 26 Apr 2013 13:27:52 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Ujhk1l0020QuhwU5BkTsCr; Fri, 26 Apr 2013 20:27:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id UkTr1l00q3ZTu2S3NkTs3L; Fri, 26 Apr 2013 20:27:52 +0000 Message-ID: <517AE347.40401@alum.mit.edu> Date: Fri, 26 Apr 2013 16:27:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C363182@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=1367008072; bh=P/ogm0Dt39z7ZS/8rdl4p4VixeqXOXeJ5ObULokMC2c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IGGaveWg9/oEyMg/NbCL9V1EgQj5dqSiQNUC3PXLvDHk3NQ+EKQRL0MdbEyvdJGwO pca29k/+Gf0wl5s0jrSefMYz+APa6A23WbFekKh2cIXZHOHu4O7zaZXUSzb+slFokz P2vFgJz0h/Kmlb5gQTrdVlCUy4ywYHwuFMV78N0sLe/nrUn7/w5H9VbsQ4UGpH1T+J /E+EEyR6URkaXcVcl8lLHdtQKejusiWJISyKtEUk+DKrkMfx5zctrGsWBQVLHcwFdw UkAkP6NgHBsK89QZnp+nWBgFFdoygxaeL0+VzGWpKB3Ok78VmyxvRZLJvijU/PEwNY 0sAPX5oKkFXMQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 26 Apr 2013 20:27:57 -0000 On 4/26/13 1:33 PM, Christer Holmberg wrote: > > Hi, > >>>>> Yes - we need a way to signal the demux mechanism to be used. >>>>> (Unless there is only one possibility. And we have already disproved >>>>> that.) >>>> >>>> We could use different group "semantics" values to indicate the multiplexing mechanism. One endpoint could probe the other to discover >>>> which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism. The answer will show >>>> which mechanisms the answerer supports. >>> >>> My idea was the endpoint simply lists the media description proto values that it is capable of multiplexing for a given 5-tuple: >>> >>> Example: a=muxcap: RTP/AVP, SCTP/DTLS >>> >>> ...or something like that. >> >> That is sufficient *if* there is a single mux/demux algorithm per proto. >> >> But I don't think that is true. I think we will need to signal this >> per-m-line, and specify the demux algorithm(s) for streams that bind to >> that m-line. > > I don't it matters if there are multiple algorithms - the important thing is that the endpoint is able to mux/demux the specific proto using A algorithm. > > Otherwise, we can have different values, one for each algorithm. Note that in my example I used to SDP proto values, but we could use whatever. My point is that both sides need to *agree* on what mechanism is used to mux/demux the streams - in order to associate each received packet with the correct m-line. So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is not sufficient without saying *how* it will be done. (Except in cases where there is a mutual understanding that there is only one way, or a default way.) > HOWEVER, before we go into the details, I would like to know whether people generally think we need a mechanism which allows to list the protos an endpoint is able to mux/demux. > >>> Of course, an endpoint needs to be able to multiplex all media that it inserts in a bundle group. But, it may not always insert m- lines for everything it is able to multiplex, so I think an explicit indication would be good. >> >> There may be more than one stream per m-line, but I think we can assume that every stream binds to one m-line. > > I am not sure I understand what you mean by "binds to one m-line". > > However, keep in mind there can be multiple streams per m- line already today (at least for RTP), so it's not something BUNDLE specific :) My point is that the *goal* of this exercise is to be able to associate each incoming packet with exactly one of the bundled m-lines. So there must be an unambiguous mapping that does that - "binds" each packet to the m-line it belongs with. >>> It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP). >> >> Unfortunately SDP has a pretty confusing idea of "transport". >> The proto field identifies a whole stack of protocol layers. > > Yes, and therefor, when we say "must use the same protocol", we need to make it clear that we refer to the Protocol value in the IP header - not the proto value in the SDP media description :) > > I will reply to the rest of your e-mail later, because I need a little more time to read it :) OK. Thanks, Paul From suhasietf@gmail.com Fri Apr 26 14:14: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 4F43221F999B for ; Fri, 26 Apr 2013 14:14:04 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 laQK6DkiZfui for ; Fri, 26 Apr 2013 14:14:03 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6D21F99F3 for ; Fri, 26 Apr 2013 14:14:02 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1065162wib.5 for ; Fri, 26 Apr 2013 14:14:00 -0700 (PDT) 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:cc :content-type; bh=PFbcfRfOIL2txr5snEzr/V5vkHRBdbZpDj5gBf0Fszo=; b=plVSewJRUT+37ZhXIhrM32yChDlqCCDci/EOdPFH86Tn/5tce4tWZgpVFUWls8924d 5WV+TMSHd2MW4f2PiuF8HdWxgciiEYzTc8RK5czwjhdqCSzcQ7oj77orRU9mm0EOipn/ hYXvrRXtVFXZP7xXQfVYUCvBSe2DEdTTUbLAlmCAXJgcwu4ii69wDF06NWEwgoh+aTEP txgaxgmkmV9Q8PE52aqfbcIrlZRug8fmOH5eh5x5/T6TqSGviwmDN8f/bx8DO/U6AwpF GuJokHRy2JSklzusq4//37R/nKpcsczg8noIUQvz/c8Htpbl0bXg6ffUF9nBCuQXxpCr OOyg== MIME-Version: 1.0 X-Received: by 10.194.122.166 with SMTP id lt6mr71264921wjb.14.1367010840760; Fri, 26 Apr 2013 14:14:00 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:14:00 -0700 (PDT) Date: Fri, 26 Apr 2013 14:14:00 -0700 Message-ID: From: Suhas Nandakumar To: mmusic-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01227ed891576104db4a03a0 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (ETSI, 3GPP related) 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, 26 Apr 2013 21:14:04 -0000 --089e01227ed891576104db4a03a0 Content-Type: text/plain; charset=ISO-8859-1 Hello Chairs, I request your help in reviewing the following sections or help me point to the appropriate reviewers 5.40, 5.41, 5,42, 5.43, 5.44 5.46 5.8 for the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e01227ed891576104db4a03a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Chairs,
=A0=A0
I request your help in = reviewing the following sections or help me point to the appropriate review= ers
=A0
5.40,
5.41,
5,42,
5.43,
5.44
5.46
5.8

for the draft
=A0 =A0
draft-na= ndakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could inform on your willingness= for reviewing the aforementioned sessions.

It wou= ld be great to have your review feedback/comments/inputs before June 9th 20= 13.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e01227ed891576104db4a03a0-- From suhasietf@gmail.com Fri Apr 26 14:14: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 2555F21F99F6 for ; Fri, 26 Apr 2013 14:14:56 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 5jkagOk4TaBF for ; Fri, 26 Apr 2013 14:14:55 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1AB21F99E4 for ; Fri, 26 Apr 2013 14:14:55 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id c10so1066712wiw.0 for ; Fri, 26 Apr 2013 14:14:50 -0700 (PDT) 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:cc :content-type; bh=aFpqBSFRTrETgbMz7EBi7F/pG1pOZDKU8M0RZozf3xE=; b=fRk93ugjjq+i0UiJXkVb7Zd9a+yFX4oXgph4xVr2caGZIOfNxD3PIOSj1pHHrl9eaV JrxADW+vxn6/k4jLmQqR8kATkFt8h5IeywLed0uej+Mk+DHKceNPae42Q7jMUyZsDjSQ qSzEDBUSrQb3zgqi4zgzmEphoOJA1Ho0GGacJvFjj0v+wC5AVbotNElvjTPQmH3m2dVf 2jqVrv5p2usNfxmQrQVo3WcjBdMnUTje+S8aKDe0RQ/gJ3cwXTx9/6+MVKO0IjrqHL1Q oJ9S3/6iAZTZcqEDAXwnv2VRXWpEYvYUR29eFXHmG1vNhbDh64RFHHWnph8xoFdsxMxD zXpw== MIME-Version: 1.0 X-Received: by 10.194.92.197 with SMTP id co5mr54732135wjb.41.1367010890010; Fri, 26 Apr 2013 14:14:50 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:14:49 -0700 (PDT) Date: Fri, 26 Apr 2013 14:14:49 -0700 Message-ID: From: Suhas Nandakumar To: csp@csperkins.org, van@packetdesign.com, M.Handley@cs.ucl.ac.uk Content-Type: multipart/alternative; boundary=047d7bf0cf5080d4cb04db4a06b2 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4566 Related) 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, 26 Apr 2013 21:14:56 -0000 --047d7bf0cf5080d4cb04db4a06b2 Content-Type: text/plain; charset=ISO-8859-1 Hello Colin, Van, Mark This is a request for reviewing the following sections 5.1, 6.1, 13.1 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/input before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --047d7bf0cf5080d4cb04db4a06b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Colin, Van, Mark
=A0=A0
This is a requ= est for reviewing the following sections
=A0
5.1, 6.1, = 13.1

of the draft
=A0 =A0
= draft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nput before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--047d7bf0cf5080d4cb04db4a06b2-- From suhasietf@gmail.com Fri Apr 26 14:18: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 9752D21F99B3 for ; Fri, 26 Apr 2013 14:18:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 1TzKLcN-3D+o for ; Fri, 26 Apr 2013 14:18:58 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8D21F999E for ; Fri, 26 Apr 2013 14:18:57 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so2379286wgg.28 for ; Fri, 26 Apr 2013 14:18:57 -0700 (PDT) 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:cc :content-type; bh=27htP+5clMBJ5ePAYhyAnkCc5q61L4NoAD1a0D3Sm0g=; b=u6C8dOryUrDlXdFWEDATZduUa3HzAVYL8bXu8x1fxKWdZA6sQIWMmT4nr6kYVCNjyZ 8rabCLea4uLMi8QynuIrHoHCBCpgJaaRgLgypXLTpnPnOKdDtSah7Y7w3e78f+UaT912 PDukGc8rd6FrybIlZZjO3kXynArB/r+OUbrwGsv6Rp+6clK3OpKTQ9clmRT4PCdK5hxf +wq9kj0B94urv4fvf91OM+5G2vFTCki10l2eZRNHqqKtgfrHBrbaSoxeg+7iDrojOnMP eM/dAsYqxWMWNLAHIwslMFukZfOLIHcL1Kb7U8d974NubvpSgCDRDfrrxGUne5znXZ+R r9eQ== MIME-Version: 1.0 X-Received: by 10.194.92.197 with SMTP id co5mr54744273wjb.41.1367011137006; Fri, 26 Apr 2013 14:18:57 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:18:56 -0700 (PDT) Date: Fri, 26 Apr 2013 14:18:56 -0700 Message-ID: From: Suhas Nandakumar To: stewe@stewe.org, jo@acm.org, sato652@oki.com, jose.rey@eu.panasonic.com Content-Type: multipart/alternative; boundary=047d7bf0cf5039b3fc04db4a15a7 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4585 Related) 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, 26 Apr 2013 21:18:58 -0000 --047d7bf0cf5039b3fc04db4a15a7 Content-Type: text/plain; charset=ISO-8859-1 Hello Joerg, Stephan, Noriyuki, Jose This is a request for reviewing the following sections 5.2, 7.1, 8.1 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --047d7bf0cf5039b3fc04db4a15a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Joerg, Stephan, Noriyuki, Jose
=A0=A0
= This is a request for reviewing the following sections
=A0
<= div>5.2, 7.1, 8.1

of the draft
=A0 = =A0
draft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--047d7bf0cf5039b3fc04db4a15a7-- From suhasietf@gmail.com Fri Apr 26 14:19: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 3B6EB21F9A09 for ; Fri, 26 Apr 2013 14:19:44 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 7CfuSZ9nV0Mr for ; Fri, 26 Apr 2013 14:19:43 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD1A21F999E for ; Fri, 26 Apr 2013 14:19:42 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so1069891wie.4 for ; Fri, 26 Apr 2013 14:19:42 -0700 (PDT) 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:cc :content-type; bh=SVzsUNADhplE5t7qPcufLdyer3VXEevHvvFxADahYXk=; b=EYYH37+3HinBNz6TdO2CxLY1qsh9vgqVpnEPb8uEc0+Mou7nBMiUEU3W7qaxr9kF/y Cc6T6IlQr4k2de9HJ/gH6u6P7cBY/2tYpQ4bciIh6HtyMCZqlc46sRkrIGhavOI6uyYM OIsP2JcRS2IRzfgZwEsDEb+LD2f1rDMfKwsvpvBbHjlpsNfB5OFSiS4/XUSY4SLUUjZ+ 9yxxykD5FOPP/LHYc/ufDzm24RTtPBH2FT2dxHdA9yjd3nPnKluobofJEFJX4CIZiDVg xcYp16Um+29AFk6C0KsrXcFmV7Ev+wnwjoPGm6OmUyUhY2cT19oxhPr5x2gkDuUSm2q4 lg9w== MIME-Version: 1.0 X-Received: by 10.180.36.205 with SMTP id s13mr6391084wij.31.1367011182223; Fri, 26 Apr 2013 14:19:42 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:19:42 -0700 (PDT) Date: Fri, 26 Apr 2013 14:19:42 -0700 Message-ID: From: Suhas Nandakumar To: lennox@cs.columbia.edu, jonathan@vidyo.com, jo@netlab.tkk.fi, jo@acm.org Content-Type: multipart/alternative; boundary=e89a8f642b58eba56f04db4a1767 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5576 Related) 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, 26 Apr 2013 21:19:44 -0000 --e89a8f642b58eba56f04db4a1767 Content-Type: text/plain; charset=ISO-8859-1 Hello Jonathan, Joerg, This is a request for reviewing the following sections 5.14, 11.1 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --e89a8f642b58eba56f04db4a1767 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jonathan, Joerg,
=A0=A0
This is a requ= est for reviewing the following sections
=A0
5.14, 11.1= =A0

of the draft
=A0 =A0
draft-nandakumar-mmusic-sdp-mux-attributes-02
= =A0=A0=A0
It will be greatly appreciated if you could inform = on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments= /inputs before June 9th 2013.

The document is avai= lable here:


Thanks in Advance

Regards
Suhas Nandakumar
--e89a8f642b58eba56f04db4a1767-- From suhasietf@gmail.com Fri Apr 26 14:20: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 77BC521F9A17 for ; Fri, 26 Apr 2013 14:20:24 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 c1utslZcT+30 for ; Fri, 26 Apr 2013 14:20:23 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C821F9A09 for ; Fri, 26 Apr 2013 14:20:22 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so3855088wey.25 for ; Fri, 26 Apr 2013 14:20:11 -0700 (PDT) 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:cc :content-type; bh=ShJIvvEvaWFl3sDKD515de2SvfcAy8n67gedAyywl0c=; b=n6uptYdS5N4Ij/ZXgWIFA3EUuii/bqqBCDrnwDB7bxPgrrMODvwbgCHxy0AsaZvoEK BwFd7WIs3JmT+8FM0rq8x+oVQtyaZV16VRVMVBpSW/J9f6JuZ59OXhDeOvlnuWOFM5EI Wzu97uDyeZspih7qtFnydQG2A9zgPV1FI3XUQCl1sEz3BjUHvt+2GX61PdntVf4pkXqQ dc+luAPCJoVcPoebHAwtmAvse9Y0lLzF4LQv3ARLx2pBovxqJOGnC1bzW7E6zyehnGOL LusfHWuHxsh22T38n8PclckKIdFlzv4hlEjx87256wD9OdCJYJAGznF3RpquJJgKpQP2 kgcA== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr6479991wic.29.1367011211727; Fri, 26 Apr 2013 14:20:11 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:20:11 -0700 (PDT) Date: Fri, 26 Apr 2013 14:20:11 -0700 Message-ID: From: Suhas Nandakumar To: jonathan@vidyo.com Content-Type: multipart/alternative; boundary=001a11c2a85aadd86204db4a19f7 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4572 Related) 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, 26 Apr 2013 21:20:25 -0000 --001a11c2a85aadd86204db4a19f7 Content-Type: text/plain; charset=ISO-8859-1 Hello Jonathan, This is a request for reviewing the following sections 5.31 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --001a11c2a85aadd86204db4a19f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jonathan,
=A0=A0
This is a request for= reviewing the following sections
=A0
5.31
of the draft
=A0 =A0
draft-nandakumar-= mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--001a11c2a85aadd86204db4a19f7-- From suhasietf@gmail.com Fri Apr 26 14:20: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 09F1E21F9A1C for ; Fri, 26 Apr 2013 14:20:31 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Hv6nWWMjrgtB for ; Fri, 26 Apr 2013 14:20:30 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2121F9A22 for ; Fri, 26 Apr 2013 14:20:29 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id h11so1221933wiv.4 for ; Fri, 26 Apr 2013 14:20:28 -0700 (PDT) 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:cc :content-type; bh=rLFASVifaCkw7iQ7GYJbO/PIgyVTAPC+iEJ4P1c/GSs=; b=nWH0OF+Ou8jSuRGCb/J/lJklGPPoadhC8bKyXpL7crWm36BkhrQd/fjtgNCMB0IOTS u7nn49CW8KvxgUojtqJzgFtt/Aamn98ih5DAfA7pad76ADhqprOhc8q2FIMhcO4zblwy /SP2g3a8VWjOhxgdu/O09LjeknoaN8uyLgTzvoFu7AhDCswfhhIkHHqr81Zbmuvc8inj 6k1jbEx4I9mLew/xH+6MrCzYYoVmJkC1SANEBi+52NrJ7v9DFkSnK5nBjPP/jOM4cIYy 7p0A7fgEQZoeIDjJKoZ43Q5AzPA3d9/S9L9emQLWUs41qYgMJo5aDm/u359EmgrDauJE ASzQ== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63370632wjc.5.1367011228924; Fri, 26 Apr 2013 14:20:28 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:20:28 -0700 (PDT) Date: Fri, 26 Apr 2013 14:20:28 -0700 Message-ID: From: Suhas Nandakumar To: rkumar@cisco.com, mmostafa@cisco.com Content-Type: multipart/alternative; boundary=089e013d0a3eb4405f04db4a1abe Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3108 Related) 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, 26 Apr 2013 21:20:31 -0000 --089e013d0a3eb4405f04db4a1abe Content-Type: text/plain; charset=ISO-8859-1 Hello Rajesh, Mogamed This is a request for reviewing the following sections 5.39 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e013d0a3eb4405f04db4a1abe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Rajesh, Mogamed
=A0=A0
This is a reque= st for reviewing the following sections
=A0
5.39
<= div>
of the draft
=A0 =A0
draft-nanda= kumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e013d0a3eb4405f04db4a1abe-- From suhasietf@gmail.com Fri Apr 26 14:20: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 BF39D21F9A09 for ; Fri, 26 Apr 2013 14:20:54 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 NpRlONi6zw57 for ; Fri, 26 Apr 2013 14:20:54 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id E01C821F9428 for ; Fri, 26 Apr 2013 14:20:53 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so2381399wgh.18 for ; Fri, 26 Apr 2013 14:20:52 -0700 (PDT) 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=AxU6bKtucaa1fQoeTo4R2QvdK8bRh5XrKRAnITVfxtU=; b=qRC+sx2OgByt88V67PlwcjFGV4R66XCUVDHUr7t6D7KQB7cDr9s47zetZsuj+CG3Cw JoMxuh9Bu88/qGk5Dr6AnKzpAUmk1c4ggPFXR/WWtNojamj9ddbHIQEsErPA7nM0XWx9 geNRa9B2qz4tN/rtmOCCU16xYscGtzkFivRS2FIY6NIVpFizdgYv1f+AnrIQgp4l3IhE uWQhQz6yar121Y9pKSzkwP+9iPqGdpo7UvIvlmBvvZxN2yg1H1U072/CwPi5UF+L+YTU P5JUcygsU6HmKj8YguoTOlG8xOdDLQnMgyN/bIyYfzvyAsZx+E2xRq9C/MlFHY3Q2LBA I0wA== MIME-Version: 1.0 X-Received: by 10.180.94.196 with SMTP id de4mr6451287wib.23.1367011252834; Fri, 26 Apr 2013 14:20:52 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:20:52 -0700 (PDT) Date: Fri, 26 Apr 2013 14:20:52 -0700 Message-ID: From: Suhas Nandakumar To: Gonzalo.Camarillo@ericsson.com, atle.monrad@ericsson.com, mmusic WG Content-Type: multipart/alternative; boundary=f46d044517f521191604db4a1c2f Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3524 Related) 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, 26 Apr 2013 21:20:55 -0000 --f46d044517f521191604db4a1c2f Content-Type: text/plain; charset=ISO-8859-1 Hello Gonzalo, Atle This is a request for reviewing the following sections 10.2 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d044517f521191604db4a1c2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Gonzalo, Atle

This is a request for rev= iewing the following sections
=A0
10.2

of the draft
=A0 =A0
draft-nandakumar-mmus= ic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d044517f521191604db4a1c2f-- From suhasietf@gmail.com Fri Apr 26 14:21: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 D5F0221F9A24 for ; Fri, 26 Apr 2013 14:21:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 EubnkFnDo3uQ for ; Fri, 26 Apr 2013 14:21:45 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C357621F9A22 for ; Fri, 26 Apr 2013 14:21:43 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1070487wib.5 for ; Fri, 26 Apr 2013 14:21:43 -0700 (PDT) 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:cc :content-type; bh=SkUWQxyjBy4j7HBj7TVlC+YebucBNfynQLnh2ClGJhM=; b=rd89akF18G/z7lUWHjM4zfY4w67nKyiySzv78qikBcK0asvEv/bPMgNzVH96b0IzYF Am7AFgBmlZSoLox2jou67gfxy1MV7/vJK95IRfad/D7iMlh2A+jXvQgMaXb/sAk+IGdE naDIGn254HWZ1ruof80vtfyMZdRhbCQxlX0yuygN7xAnSAoMwRSp+IJeEi/jHYNo336H QZ9GG30rulj1oPBqr1ItxM0VwmUF6YU96/LCVL9zscH4VgbrAE8+wYBgetWA2ehLf7EP Jz7zU1BDRy9UNUE5QpiBONfIzpJWt0sETLE2cc2Bz0sc5R/2l8GDuMLDBkDvUCbxFjOi jlDA== MIME-Version: 1.0 X-Received: by 10.180.21.193 with SMTP id x1mr6397850wie.31.1367011302963; Fri, 26 Apr 2013 14:21:42 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:21:42 -0700 (PDT) Date: Fri, 26 Apr 2013 14:21:42 -0700 Message-ID: From: Suhas Nandakumar To: jonathan@vidyo.com, huitema@microsoft.com Content-Type: multipart/alternative; boundary=047d7bb709821e002104db4a1fde Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3605 Related) 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, 26 Apr 2013 21:21:46 -0000 --047d7bb709821e002104db4a1fde Content-Type: text/plain; charset=ISO-8859-1 Hello Christian , Jonathan This is a request for reviewing the following sections 5.13 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --047d7bb709821e002104db4a1fde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello=A0 Christian ,=A0Jonathan
=A0=A0
This is a request for reviewing the fol= lowing sections
=A0
5.13=A0

of the draft
=A0 =A0
draft-nandakumar-mmusic-sdp-mu= x-attributes-02
=A0=A0=A0
It will be greatly apprec= iated if you could inform on your willingness for reviewing the aforementio= ned sessions.

It would be great to have your review feedback/comments= /inputs before June 9th 2013.

The document is avai= lable here:


Thanks in Advance

Regards
Suhas Nandakumar
--047d7bb709821e002104db4a1fde-- From suhasietf@gmail.com Fri Apr 26 14:22: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 9C2DF21F9A14 for ; Fri, 26 Apr 2013 14:22:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 VExLxbFfGjGU for ; Fri, 26 Apr 2013 14:22:13 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9904C21F9A2B for ; Fri, 26 Apr 2013 14:22:12 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so2464864wgh.5 for ; Fri, 26 Apr 2013 14:22:06 -0700 (PDT) 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:cc :content-type; bh=SooSf03X5tIxtnubEL9SvC2XADQojur61luCA2dXnY4=; b=wEx6vcvpnmT4gztPaftANxmiOYTZFBQ9LyOmquHE7cjCbvS/ambpRDEg3pCnH1uUg8 +6rYeBXlxKrxjkQjRWCKlg1XR4zoIG5PrYQ0bBPjwJ8DyI7xypd/ds5NGkAtw7GWPYBF gI6wuYRzLvM6loAM/QCV6c1GiRJNOb8l8QDFJJc7Kjqv62S9UL4ofdT8poSmcqgL8OgE tcrh6261t+FoVpf2ts9xYcTCI8jj3r+8g7498frPeUDs33YYzHgZtKeIzHRf4C45qO+p E94KR03RNhE3h5kHTQ/es0zzGHxs+FcrPHOnZ+rr//RI1u9acjvWqg8aMF3vD1kiswh6 BirQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr507210wid.29.1367011326240; Fri, 26 Apr 2013 14:22:06 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:22:06 -0700 (PDT) Date: Fri, 26 Apr 2013 14:22:06 -0700 Message-ID: From: Suhas Nandakumar To: Magnus.Westerlund@ericsson.com Content-Type: multipart/alternative; boundary=f46d0438914b81324804db4a208b Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RF3890 Related) 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, 26 Apr 2013 21:22:13 -0000 --f46d0438914b81324804db4a208b Content-Type: text/plain; charset=ISO-8859-1 Hello Magnus This is a request for reviewing the following sections 6.3 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d0438914b81324804db4a208b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Magnus
=A0=A0
This is a request for re= viewing the following sections
=A0
6.3

of the draft
=A0 =A0
draft-nandakumar-mmus= ic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d0438914b81324804db4a208b-- From suhasietf@gmail.com Fri Apr 26 14:23: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 EA7D121F9A27 for ; Fri, 26 Apr 2013 14:23:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 KPWCZvY7G7kl for ; Fri, 26 Apr 2013 14:23:05 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2807421F9A24 for ; Fri, 26 Apr 2013 14:23:04 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so710520wgh.5 for ; Fri, 26 Apr 2013 14:23:04 -0700 (PDT) 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:cc :content-type; bh=wFw3Jh+v5ZHCjblcdq4ZLy31FUAKP1Jyo2R1YLWaFig=; b=UNbqmzd6fVWtONh/ozQ9OTnwkmTVVN1gHTlvkWGUfwq07vouzrGOzWHtaXI8/WD/6H zlBdxz7bj85tOnmAcO/wotdC9z6P8xv9LTzDGQkXuqyjRJ+5ya2QG7847z8Yh+Jn3rN0 aIw6zMGwNlerreH1lXBIIK673eXSf6Ieatu7hc/3opPoiZS9w11rRBgJnyVbsbMVE1nh rdwxWynehXxzVcOMaS0c7Yd6vv8oXu9YmrRRjlqWzSNKGa5Gi9KfmI+0GoL8y8SPfTk3 T9vwEV5yzpXyJil955mS1c6ofMfdYL5ozFiyQLmDMMtxOYU6GVPPqvSqH31A88cFbGUo Ahfg== MIME-Version: 1.0 X-Received: by 10.180.94.196 with SMTP id de4mr6457190wib.23.1367011384336; Fri, 26 Apr 2013 14:23:04 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:23:04 -0700 (PDT) Date: Fri, 26 Apr 2013 14:23:04 -0700 Message-ID: From: Suhas Nandakumar To: jari.arkko@piuha.net, carrara@kth.se, fredrik.lindholm@ericsson.com, mats.naslund@ericsson.com, magnus.westerlund@ericsson.com Content-Type: multipart/alternative; boundary=f46d044517f5f7a98e04db4a2372 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4567 Related) 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, 26 Apr 2013 21:23:06 -0000 --f46d044517f5f7a98e04db4a2372 Content-Type: text/plain; charset=ISO-8859-1 Hello Jari, Elisabetta, Fredrik, Mats, Magnus This is a request for reviewing the following sections 5.30 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d044517f5f7a98e04db4a2372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jari,=A0Elisabetta, F<= /span>redrik, Mats, Magnus=A0
=A0= =A0
This is a request for reviewing the following sections
=A0
5.30

of the draft
=A0 =A0
draft-nandakumar-mmusic-sdp-mux-attributes-02
= =A0=A0=A0
It will be greatly appreciated if you could inform = on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments= /inputs before June 9th 2013.

The document is avai= lable here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d044517f5f7a98e04db4a2372-- From suhasietf@gmail.com Fri Apr 26 14:23: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 77BDB21F8443 for ; Fri, 26 Apr 2013 14:23:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 hLUfVehs6GPK for ; Fri, 26 Apr 2013 14:23:41 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8E21F83EF for ; Fri, 26 Apr 2013 14:23:40 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id c10so1084096wiw.8 for ; Fri, 26 Apr 2013 14:23:39 -0700 (PDT) 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:cc :content-type; bh=CKYGX7HSTFKF/0qvYTM5kGFFHp9VmSGOHgVkLLsYH1w=; b=nSXDZ9ZW2/IUTm0YJwzlnzqy1SGsZcSaP4LpsoS/15xq4S8rwpB+maCofdW9UDxk/3 0cm8uLY9HqIAdexxcd8DkZFLXssIROzgW6yUQWAtQUM6iu5Nu4PFQARKxL3EmJI5VMW6 dBNBs4anPwhVBlRORTRo35kfTMo0gjBRo7o7QUbuFh7oWzoKpMLQuaPCG1Gs/oE+RyTf REGsjdoYqmaqtg7hME1iP3PR27SjBujQb0g6g05fVhuPpQ3cAejh5aCBM7fXvzbiSHco EoyjryDoXM9YrpwFiCPooDcfMujoAdPC2WzxDGd3R08roWzMqixICwglu/SsmhxtuIGP Xsew== MIME-Version: 1.0 X-Received: by 10.180.85.103 with SMTP id g7mr6458122wiz.23.1367011419920; Fri, 26 Apr 2013 14:23:39 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:23:39 -0700 (PDT) Date: Fri, 26 Apr 2013 14:23:39 -0700 Message-ID: From: Suhas Nandakumar To: fandreas@cisco.com, dwing@cisco.com, mbaugher@cisco.com Content-Type: multipart/alternative; boundary=f46d043bdce616a24004db4a26b0 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4568 Related) 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, 26 Apr 2013 21:23:41 -0000 --f46d043bdce616a24004db4a26b0 Content-Type: text/plain; charset=ISO-8859-1 Hello Flemming, Dan, Mark This is a request for reviewing the following sections 5.6 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d043bdce616a24004db4a26b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Flemming, Dan, Mark
=A0=A0
This is a r= equest for reviewing the following sections
=A0
5.6

of the draft
=A0 =A0
draft-na= ndakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d043bdce616a24004db4a26b0-- From suhasietf@gmail.com Fri Apr 26 14:24: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 95EA221F9952 for ; Fri, 26 Apr 2013 14:24:04 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 b3IVQyj4FHQ4 for ; Fri, 26 Apr 2013 14:24:03 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC2521F96D4 for ; Fri, 26 Apr 2013 14:24:03 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so2466934wgh.14 for ; Fri, 26 Apr 2013 14:24:00 -0700 (PDT) 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:cc :content-type; bh=E2apo0KBNNF09gW0rpYM64Wo8hh3lPDU3FIcxWO7okY=; b=nnb+JJ1PddxFtXJqEOce9C7A8owXhLEiY1UbEKolYit1duSvJLAAeErZsAVQ+xFkYp Jieqh/I7Ps8ZQZLzrvXY4R1/yb9dp4FWthLyB9NJ8nE2iFTYbZq7z65ozikHw+wN4diG 81n+EkpAC/CJUFeuVH2JTHtJt/SqIW5iPJiA/m34pGroOHJ6IkbgXER/84vucUnRA1CY WxwpVHkFPeH37va23K5o+9TNuJhT+tCctjFgJiCj3G+30FBkbvhr0iy4oWELe4lHAy6C c+ZkYbOfnxkqNCgzv9cE0pzDPb/TYPnJ0XPn4e2iMPE9GcgArCSQjLdCcmhejUuUW1uu mEEw== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63380194wjc.5.1367011440096; Fri, 26 Apr 2013 14:24:00 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:24:00 -0700 (PDT) Date: Fri, 26 Apr 2013 14:24:00 -0700 Message-ID: From: Suhas Nandakumar To: fandreas@cisco.com Content-Type: multipart/alternative; boundary=089e013d0a3e4a7c0404db4a27fb Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3407 Related) 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, 26 Apr 2013 21:24:04 -0000 --089e013d0a3e4a7c0404db4a27fb Content-Type: text/plain; charset=ISO-8859-1 Hello Flemming This is a request for reviewing the following sections 5.20 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e013d0a3e4a7c0404db4a27fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Flemming
=A0=A0
This is a request for = reviewing the following sections
=A0
5.20
of the draft
=A0 =A0
draft-nandakumar-m= music-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e013d0a3e4a7c0404db4a27fb-- From suhasietf@gmail.com Fri Apr 26 14: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 2CED521F9CE2 for ; Fri, 26 Apr 2013 14:24:42 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 g9sZ35jsjawF for ; Fri, 26 Apr 2013 14:24:41 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 70D8C21F9C5C for ; Fri, 26 Apr 2013 14:24:38 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so2379467wgh.11 for ; Fri, 26 Apr 2013 14:24:27 -0700 (PDT) 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:cc :content-type; bh=IWqMKPL0jF1gVuYVlTh0hM2sztPTnaI07uIaRKQSubs=; b=bKE7eChsxDmrFeY0NIV4WUsF7WZ2cSOcg+oDDOf0jr+bhxCV9dohjWuYlnJ4nkKpTv YVLg9s4Q0hCVLvC92Jj7CEE+P420Wu/8mfYaKcTKlZqoUfRlwFlr13MiosUvCzXpPdbA 2ACdg+RvI4vgysJ8onVJCfVjXxVi9mtNscJbxQiwna9g3rHlMLp3sw5jNtDCII2CIYik 4GArhYyi7dH6wLc885za09QS+4+w2NqLXpNwX6a3rT3/LjJVSnqvBhgZ47GEYwY109I6 lqdV2Qq/G2ihV/ZEaP0yIh2Potlx4VGwf3NaIAVQGBY5Q7OZ1eMOhIUd27g9YXclAGjp mzwg== MIME-Version: 1.0 X-Received: by 10.194.92.197 with SMTP id co5mr54759518wjb.41.1367011467050; Fri, 26 Apr 2013 14:24:27 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:24:27 -0700 (PDT) Date: Fri, 26 Apr 2013 14:24:27 -0700 Message-ID: From: Suhas Nandakumar To: casner@acm.org, magnus.westerlund@ericsson.com Content-Type: multipart/alternative; boundary=047d7bf0cf50e5c57a04db4a2881 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3556 Related) 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, 26 Apr 2013 21:24:43 -0000 --047d7bf0cf50e5c57a04db4a2881 Content-Type: text/plain; charset=ISO-8859-1 Hello Stephen, Magnus This is a request for reviewing the following sections 6.2 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --047d7bf0cf50e5c57a04db4a2881 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Stephen, Magnus
=A0=A0
This is a reque= st for reviewing the following sections
=A0
6.2

of the draft
=A0 =A0
draft-nandak= umar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--047d7bf0cf50e5c57a04db4a2881-- From suhasietf@gmail.com Fri Apr 26 14:24: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 8E2FF21F9CE0 for ; Fri, 26 Apr 2013 14:24:50 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 SvLwNV3PpC6W for ; Fri, 26 Apr 2013 14:24:50 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10021F9C5F for ; Fri, 26 Apr 2013 14:24:49 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so3909277wey.11 for ; Fri, 26 Apr 2013 14:24:48 -0700 (PDT) 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:cc :content-type; bh=VWGsMzfBLC4/I3RTiwYaRhfNNfmlIsx6rzdm8LNC+dA=; b=l2ZKwvrBpCb+tBWqsGfYHbmQm8zOpFTAqsK2YeSduCMFJPvh9zdPztFa6OdPkcrRxj CO6cmt3YKh8/yb+ZHrSYbV5Q0uH/3gPq7QvHJDqeUY2gQ5A9Xn0gNjiSWOJxVdV7EaGd ezZeWlhM/xzmSQ3WLeGBge0s42E9gJZoMmIBarLfQ9uzE/y0HWxMi7dS0qtfevftlw63 ZEr01/3o4kaaTS7Pxyz17q4ayp47HLolwgrpmYky1UVjMr9DAqhP6OMsVS8ps5JvGPKZ C6rX5bdFpPrTaj743ZWh9SGHem8snWEGzTDc5Qg7RZYKvdpG+ELZmrLxbnlKl8oIeGiX Flfw== MIME-Version: 1.0 X-Received: by 10.180.85.103 with SMTP id g7mr6461088wiz.23.1367011488458; Fri, 26 Apr 2013 14:24:48 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:24:48 -0700 (PDT) Date: Fri, 26 Apr 2013 14:24:48 -0700 Message-ID: From: Suhas Nandakumar To: Eric Rescorla , jdrosen@jdrosen.net Content-Type: multipart/alternative; boundary=f46d043bdce62c715004db4a2a2e Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5245 Related) 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, 26 Apr 2013 21:24:51 -0000 --f46d043bdce62c715004db4a2a2e Content-Type: text/plain; charset=ISO-8859-1 Hello Jonathan, Eric This is a request for reviewing the following sections 5.11 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d043bdce62c715004db4a2a2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jonathan, Eric
=A0=A0
This is a reques= t for reviewing the following sections
=A0
5.11

of the draft
=A0 =A0
draft-nandak= umar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d043bdce62c715004db4a2a2e-- From suhasietf@gmail.com Fri Apr 26 14: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 ED06F21F9CE3 for ; Fri, 26 Apr 2013 14:25:12 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 drd2oZl+Vobw for ; Fri, 26 Apr 2013 14:25:12 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 351C221F9A14 for ; Fri, 26 Apr 2013 14:25:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so2489443wgh.24 for ; Fri, 26 Apr 2013 14:25:11 -0700 (PDT) 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:cc :content-type; bh=kGraeUrDne0D0CSlyDxlnATC6bQqFGhjKKJJZWh2PXw=; b=xsi5Mij8xV8tcYlMIFJsfovuwBvo+UNNirJ/r3zVWZvmco+qlui+BxCJgRppUe/XSy qvtee8VRs1I6hgwXl1cCxCNtMoWzsk+9Gwb+DyrirJJbhMJK5CFN+rue15DEtBv+P02q X+zCe4Xg70k/qEKVam/WzZYhhODtc6Jwd+lsVrBteE7N6l70zhnkHPMqfGi9J0HGpHar XZ7iYEXGCXMSuoFBod9BeWc18u+jO15JigBsZ9KybIJ+nZO4/+7c2cjtx1VwHVSkULms +HqXJDiTOYtpa6ob/H+PqslgCDJNwsy9DVGZ/yC4NHzbfpAQo+h3aWK4l0yIVW2DoCXT XuLA== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63383411wjc.5.1367011511368; Fri, 26 Apr 2013 14:25:11 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:25:11 -0700 (PDT) Date: Fri, 26 Apr 2013 14:25:11 -0700 Message-ID: From: Suhas Nandakumar To: rcq@boxnarrow.com, finlayson@live555.com Content-Type: multipart/alternative; boundary=089e013d0a3e8a2db204db4a2bdf Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4570 Related) 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, 26 Apr 2013 21:25:13 -0000 --089e013d0a3e8a2db204db4a2bdf Content-Type: text/plain; charset=ISO-8859-1 Hello Bob, Ross This is a request for reviewing the following sections 5.32 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e013d0a3e8a2db204db4a2bdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Bob, Ross

This is a request for reviewi= ng the following sections
=A0
5.32

=
of the draft
=A0 =A0
draft-nandakumar-mmusic-s= dp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e013d0a3e8a2db204db4a2bdf-- From suhasietf@gmail.com Fri Apr 26 14:27: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 6239721F9A30 for ; Fri, 26 Apr 2013 14:27:12 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Gi-aPld6b7Nk for ; Fri, 26 Apr 2013 14:27:11 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60021F9A2A for ; Fri, 26 Apr 2013 14:27:03 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hj19so1083500wib.16 for ; Fri, 26 Apr 2013 14:27:02 -0700 (PDT) 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:cc :content-type; bh=FNdikyj7uyL/somqk2JFaZLXt0Dy+F6Hi2pHFxc1ots=; b=IbYjYqROqap20hDorBvEK1mpHqJDiKMcZuodq7SIEtoHWjkaCVIHz0eNaRpXo5LVhG owVUAublfUWqBw7v+clJRD4epddGiwc+NrB+hHoUd08OGq64EtVi4akSGAvEKJkDn7om MYi5DyH7YWy0RqDaVQYem8L/cwqXIDE7WiPeEVLXerNM6w74KJ6lB2scNLUcPZTU8SH/ LL52pnLpwIwzr9hnKKqHzHX0aZpIKugCwyMRvpJBcMpb91rnlNUbxf6hhtoiq2GqtadH eQ2wnDhooh13rKDeCQ2I2ZX+qXhaCX82KWmwLjvt3irr9Dj/vE7MTMRT6fHSy6UvEBEb xTjA== MIME-Version: 1.0 X-Received: by 10.194.122.166 with SMTP id lt6mr71301531wjb.14.1367011622818; Fri, 26 Apr 2013 14:27:02 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:27:02 -0700 (PDT) Date: Fri, 26 Apr 2013 14:27:02 -0700 Message-ID: From: Suhas Nandakumar To: ben@estacado.net, rohan@rohan.com, Cullen Jennings Content-Type: multipart/alternative; boundary=089e01227ed82e989e04db4a328f Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4975 Related) 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, 26 Apr 2013 21:27:12 -0000 --089e01227ed82e989e04db4a328f Content-Type: text/plain; charset=ISO-8859-1 Hello Ben, Rohan, Cullen This is a request for reviewing the following section 5.45 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e01227ed82e989e04db4a328f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Ben, Rohan, Cullen
=A0=A0
This is a re= quest for reviewing the following section
=A0
5.45

of the draft
=A0 =A0
draft-nan= dakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e01227ed82e989e04db4a328f-- From suhasietf@gmail.com Fri Apr 26 14:28:17 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 7F6B821F9A2F for ; Fri, 26 Apr 2013 14:28:17 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 piKGupsziUeJ for ; Fri, 26 Apr 2013 14:28:17 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 865AA21F9A2C for ; Fri, 26 Apr 2013 14:28:16 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id s43so3989560wey.27 for ; Fri, 26 Apr 2013 14:28:15 -0700 (PDT) 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:cc :content-type; bh=m3fqsw7JwLvFjkrm//eCdo45xZVHwBoJC+UEuecrsQ4=; b=m0XDKBahrTosugvt1VereEGsFpGNTFRBLz0w2U4i/5VazIaQe2MDIH8AM7R87tJ1la XeSKkO9jZ7i2bYVWRu6JDEQR9PbodSkPfCshAEvf0cFOFkVQll4TOfmY2ZIuPr/cmOBH 82UWRJmsfcIFqqHZvgm2BAMsCojO+znhpq1eD9n59ehYzO0/s0vj18Vf1YAJJspokQyA Xw4ZzFFWy+O+Ghv/DaCA0+78y3RSFkliYw778rB3Yot7i3+wQEmB7GQyLfN6bioRmb44 BR9YeqaZ9Oa8CsVkdtkW9qAlHrYniVflh2WoY0gslB4tNsg+MQ22PGek1WAgoHZwFdpG zfJQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr523365wid.29.1367011695509; Fri, 26 Apr 2013 14:28:15 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:28:15 -0700 (PDT) Date: Fri, 26 Apr 2013 14:28:15 -0700 Message-ID: From: Suhas Nandakumar To: ldondeti@qualcomm.com, anja.jerichow@nsn.com Content-Type: multipart/alternative; boundary=f46d0438914b83c6aa04db4a36a0 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5159 Related) 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, 26 Apr 2013 21:28:18 -0000 --f46d0438914b83c6aa04db4a36a0 Content-Type: text/plain; charset=ISO-8859-1 Hello Lakshminath, Anja This is a request for reviewing the following sections 5.36 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d0438914b83c6aa04db4a36a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Lakshminath, Anja=A0
=A0=A0
This is a = request for reviewing the following sections
=A0
5.36

of the draft
=A0 =A0
draft-= nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d0438914b83c6aa04db4a36a0-- From suhasietf@gmail.com Fri Apr 26 14:28: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 0816821F9A2C for ; Fri, 26 Apr 2013 14:28:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 AIRapFyou0hN for ; Fri, 26 Apr 2013 14:28:51 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4279721F99E4 for ; Fri, 26 Apr 2013 14:28:51 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so1084681wiv.13 for ; Fri, 26 Apr 2013 14:28:50 -0700 (PDT) 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:cc :content-type; bh=fpQoK1JHjFvP4h3n+eNJ0cbwA3grlaBoJXUn4ZobrBA=; b=WOHGQ/eXMIsv0tbxAf7l8ppREJSBSml8feH3L0j4i3eTCa1bHl8jUH6afb5GTkq9dK S+WcgUCD2FDBj9+py69Abfz4rQ2lLb2vBUnt8QbdmaeDMAVB0Xvv0u/fVBv/7g44aRO/ H+AXApkW3u8CZnK/DCj2OkkyWzB3c4F8g1u0+hVVAm0ozhy1dPJmQBhnhRAbXp5gDbaK oEg3n6z1jo0znd8n50aLxk1q2S4xNcVsAywJS9Deeox/zlAk9Mey2qZov0DIPU3AQBu5 jbCsfJPD+9wKfYDDbxSBanU82yj2Zqdgmhuh0JCXej9Nx7CjqjTOdxsTOiobdPXVZHC/ mVNQ== MIME-Version: 1.0 X-Received: by 10.194.122.166 with SMTP id lt6mr71289171wjb.14.1367011348926; Fri, 26 Apr 2013 14:22:28 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:22:28 -0700 (PDT) Date: Fri, 26 Apr 2013 14:22:28 -0700 Message-ID: From: Suhas Nandakumar To: Gonzalo.camarillo@ericsson.com Content-Type: multipart/alternative; boundary=089e01227ed8db576c04db4a2156 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4145 Related) 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, 26 Apr 2013 21:28:52 -0000 --089e01227ed8db576c04db4a2156 Content-Type: text/plain; charset=ISO-8859-1 Hello Gonzalo, This is a request for reviewing the following sections 5.35 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e01227ed8db576c04db4a2156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Gonzalo,=A0
=A0=A0
This is a request f= or reviewing the following sections
=A0
5.35
=
of the draft
=A0 =A0
draft-nandakuma= r-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e01227ed8db576c04db4a2156-- From suhasietf@gmail.com Fri Apr 26 14:29: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 E396121F9952 for ; Fri, 26 Apr 2013 14:29:14 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 S9fQOvk1CzuL for ; Fri, 26 Apr 2013 14:29:14 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68B21F9A34 for ; Fri, 26 Apr 2013 14:29:14 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id z11so2383836wgg.8 for ; Fri, 26 Apr 2013 14:29:13 -0700 (PDT) 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:cc :content-type; bh=PeQKlfSmAcT14E755+tCtts8vWKj3ExPLgZfVmmuras=; b=NrZ/aAcE7sqwqhKtrQVmWyr+crRzgSPOlY9IM3kOZBwdKPY554winltRY6O+uC4Hr1 EWtJ1puCeaAtrlbi2DX2gBFF7jk3WadA0KBN/gjv3I7w58GoUP1bRg5ZoE7BnThZMCBH b/up8egyuwK+tNTay1yCed+CpxI44IzmqQX5yL+GrjIaQtloCt7ygAQwFC6sRAYCOYdI ZxQAqdFErTLSa+FWPEOvR8CbPrL8nDwJIiOovon7r7zrIHjBa0zyOY7rzE9UKqXnt/jL HHEVDgFgTiSXfDRBYayB2xlu7/VVNLXwxCmdRgGZzFAr5LnZmEa2IguEd9EHO1PSDEp/ S1sA== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr6504134wic.29.1367011753352; Fri, 26 Apr 2013 14:29:13 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:29:13 -0700 (PDT) Date: Fri, 26 Apr 2013 14:29:13 -0700 Message-ID: From: Suhas Nandakumar To: stewe@stewe.org, ts@thomas-schierl.de, fandreas@cisco.com Content-Type: multipart/alternative; boundary=001a11c2a85af68e0804db4a391e Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5583 Related) 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, 26 Apr 2013 21:29:15 -0000 --001a11c2a85af68e0804db4a391e Content-Type: text/plain; charset=ISO-8859-1 Hello Thomas, Stephan, Flemming This is a request for reviewing the following sections 10.5 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --001a11c2a85af68e0804db4a391e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Thomas, Stephan, Flemming
=A0=A0
This = is a request for reviewing the following sections
=A0
1= 0.5

of the draft
=A0 =A0
d= raft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--001a11c2a85af68e0804db4a391e-- From suhasietf@gmail.com Fri Apr 26 14:30:19 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 58D2921F99E4 for ; Fri, 26 Apr 2013 14:30:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 DbsypCW4g8p9 for ; Fri, 26 Apr 2013 14:30:17 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 71ACA21F9CE5 for ; Fri, 26 Apr 2013 14:30:16 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id e11so714993wgh.0 for ; Fri, 26 Apr 2013 14:30:12 -0700 (PDT) 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:cc :content-type; bh=wc0TlBqhlIJktkYZrLq9EwNnVkUdVeMgd5b89/CbAG8=; b=Hd3Cik6I/wI3oMCd0h0BgF3QGOMAhBwreRMYa00fLLaU3P4HVy18ptxgdgOoOgL7z1 anb8ruQ4h6N/vgkfPamJEXA89pFTaxU1qKO147ty6R2omeOXRZ4Hgf8oHFguCh0FCEAT tgsHkSyy7/L6+ck7Ek5ebFgOX15LUMQF4VTvWzAZq+F5jevYXpawCaaDwvoaY5hfGBd9 crkjc/s0VtjzSpQMFVv6XePDxX705lcoxLcAEVeGYEp+zJrFZjbxjr4C8kwvLmMXR7FO 4iGdOg3pGuWvFOcjE6uycRrImLF9bIKKx3xQo4Inzs1l9MokrcleD2sf0f18I+icJ0SP 5EKw== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63396993wjc.5.1367011812903; Fri, 26 Apr 2013 14:30:12 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:30:12 -0700 (PDT) Date: Fri, 26 Apr 2013 14:30:12 -0700 Message-ID: From: Suhas Nandakumar To: magnus.westerlund@ericsson.com, csp@csperkins.org Content-Type: multipart/alternative; boundary=089e013d0a3e83112f04db4a3d24 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5761 Related) 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, 26 Apr 2013 21:30:19 -0000 --089e013d0a3e83112f04db4a3d24 Content-Type: text/plain; charset=ISO-8859-1 Hello Colin, Magnus This is a request for reviewing the following sections 5.3 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e013d0a3e83112f04db4a3d24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Colin, Magnus
=A0=A0
This is a request= for reviewing the following sections
=A0
5.3

of the draft
=A0 =A0
draft-nandakum= ar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e013d0a3e83112f04db4a3d24-- From abegen@cisco.com Fri Apr 26 14:30: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 A51EE21F9CE5 for ; Fri, 26 Apr 2013 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 C9df9ZQyQZDy for ; Fri, 26 Apr 2013 14:30:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4521F99E4 for ; Fri, 26 Apr 2013 14:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1042; q=dns/txt; s=iport; t=1367011821; x=1368221421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5gzP3kaaUGjbFpHEnp4aT6rA8kaGAXe+LlJMcIXl9ss=; b=DQ1hCpbTPho5ACpFrddFoHHspL+StNS3S9Kw63qEOeDcxU0ta9ALa2iN PU9trAxGKvB12/MkSx2xY3ipg4gQtEOqd0nY1p+tyDHiq7N/DUXwF6IJz JEwRPUryH30xycifswAwym881HC1etUjnlDIxvejwN04yvseTXjTPe0Ig s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFADzxelGtJXG9/2dsb2JhbABRgmYhvnOBBhZ0gh8BAQEDAXkFCwIBCCIkMiUCBA4FCIgGBgG/Do5fAjEHgm1hA4han2yDDoIo X-IronPort-AV: E=Sophos;i="4.87,561,1363132800"; d="scan'208";a="203646528" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 26 Apr 2013 21:30:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3QLULFB020761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 21:30:21 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 16:30:20 -0500 From: "Ali C. Begen (abegen)" To: "Dong Hsu (dohsu)" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01 Thread-Index: AQHOMh+OrJd+p16ntUKckcdJFFsN55jk0xuAgACHcACAAPSDgIAAtQcAgAIJswCAAANrAP//7OYAgAB7+gA= Date: Fri, 26 Apr 2013 21:30:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.120] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0633530195C4564F9E69E1000ED4B35D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-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, 26 Apr 2013 21:30:26 -0000 X-List-Received-Date: Fri, 26 Apr 2013 21:30:26 -0000 On Apr 27, 2013, at 3:06 AM, Dong Hsu (dohsu) wrote: > Here are the comments I have for this draft: >=20 Thanks. > 1. In the definition of duplication-delay attribute, it should clearly > state that the value is applied to the delay from previous stream. I knew > this is explained in the example but should be state here. OK. >=20 > 2. Can both attributes co-exist in media and session level? If not, pleas= e > state it somewhere. If so, does session level exceed media level? >=20 This was discussed before. And it is not without problems if we wanted both= media and session level attribute in the same SDP. I will make this cleare= r in the document. > 3. For multiple delay values, I would prefer to use space to separate > multiple values such as >=20 > a=3Dduplication-delay:50 100 150 I am in different. Does anybody else have an opinion on this? >=20 > This is more inline with other attributes with multiple values in SDP. >=20 > Best Regards, >=20 > -- Dong >=20 From suhasietf@gmail.com Fri Apr 26 14:30: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 5F97B21F9CE6 for ; Fri, 26 Apr 2013 14:30:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 TSst4FhG+Jtv for ; Fri, 26 Apr 2013 14:30:26 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id B281121F99CE for ; Fri, 26 Apr 2013 14:28:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1088222wiv.3 for ; Fri, 26 Apr 2013 14:28:39 -0700 (PDT) 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:cc :content-type; bh=nPpXSnh0jBRbP1T6n4lnnnNGhCdI78w8SuiNbnHzmwA=; b=Y97F5cvL+MoAweJ2+8gH51p0f4sQTKhcxXrpqaynddG6TYA+xvAHw3BoiWBrSdt/va I0PBUmWZpuyu+IG1UrlAKSVCslhCWpoQ0IeHZG9UMDORGa1738OGfQ9NDcqVCVXqBgFr SNWC0Ituq9yyjdH7ZNDKP3vMcFhONUQ11NYzOkTg3lp1ffXaIaoGafj43GWs1NzPZLzh rFFhaIMtM3QBcf5KOPu29ebBrMztJ5silHWsGrf+IqzxN5oc4fu/UuYgDhlHPqEFocek XwX8ORNsZPrwj4RbtUlUjgiXi8XQpMlHXR2oACxAWOXHWE6zDbL/5qAIBt8rFPM9L6+L aa9w== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr524347wid.29.1367011718987; Fri, 26 Apr 2013 14:28:38 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:28:38 -0700 (PDT) Date: Fri, 26 Apr 2013 14:28:38 -0700 Message-ID: From: Suhas Nandakumar To: ingemar.s.johansson@ericsson.com, magnus.westerlund@ericsson.com Content-Type: multipart/alternative; boundary=f46d0438914bea337e04db4a3775 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5506 Related) 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, 26 Apr 2013 21:30:29 -0000 --f46d0438914bea337e04db4a3775 Content-Type: text/plain; charset=ISO-8859-1 Hello Ingemar, Magnus This is a request for reviewing the following sections 5.9 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d0438914bea337e04db4a3775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Ingemar, Magnus
=A0=A0
This is a reque= st for reviewing the following sections
=A0
5.9

of the draft
=A0 =A0
draft-nandak= umar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d0438914bea337e04db4a3775-- From suhasietf@gmail.com Fri Apr 26 14:31: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 6AD0F21F9CE8 for ; Fri, 26 Apr 2013 14:30:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 GCVMvkPizRG1 for ; Fri, 26 Apr 2013 14:30:57 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAB621F9CE9 for ; Fri, 26 Apr 2013 14:30:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hj19so1085283wib.10 for ; Fri, 26 Apr 2013 14:30:36 -0700 (PDT) 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:cc :content-type; bh=FX/TFpDxl9mBbzxbfCV4SidnRwTLXq+bWiBVwA5OAvQ=; b=rDd8qyp0oW3vUaGLZYiuXhZGvHj4lZfxupROFslGdwAv8y8Gmb+doqf0S4zzT8nim2 bKmvP6a0wygHXaelXYWYK25kKNp99LEJYbNm05BxUcqsTDaD3+xWdPztsL3VapSmbPc1 ImxrUvSzgyM+8pfR8haNuYHgNE3AgHAXln23VTlu+9+bQGyh+Kec19mC/DGGCcfd3G4u +Ck47zYi202wmkbusToEXCgS/rZoPVfdtYgxqyAq/tgHwvPV2uUPji5Pkb/EDwMNAxdJ +RLACrQwSbfdRcqQ7BiL8Dpnclqp9rM067UaJkP85wVN2n9pWmoswbgR9zBdVkwr0Vec v+rw== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63398288wjc.5.1367011836884; Fri, 26 Apr 2013 14:30:36 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:30:36 -0700 (PDT) Date: Fri, 26 Apr 2013 14:30:36 -0700 Message-ID: From: Suhas Nandakumar To: csp@csperkins.org Content-Type: multipart/alternative; boundary=089e013d0a3ef0fbfc04db4a3ef2 Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5762 Related) 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, 26 Apr 2013 21:31:02 -0000 --089e013d0a3ef0fbfc04db4a3ef2 Content-Type: text/plain; charset=ISO-8859-1 Hello Jonathan, Joerg, This is a request for reviewing the following sections 5.7 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --089e013d0a3ef0fbfc04db4a3ef2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jonathan, Joerg,
=A0=A0
This is a requ= est for reviewing the following sections
=A0
5.7
<= div>
of the draft
=A0 =A0
draft-nanda= kumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--089e013d0a3ef0fbfc04db4a3ef2-- From suhasietf@gmail.com Fri Apr 26 14:31: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 DD00A21F9CEF for ; Fri, 26 Apr 2013 14:31:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 9h7t5t-bWCeq for ; Fri, 26 Apr 2013 14:31:12 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5058621F9CE9 for ; Fri, 26 Apr 2013 14:31:07 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so2386686wgh.26 for ; Fri, 26 Apr 2013 14:31:06 -0700 (PDT) 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:cc :content-type; bh=s/3Y0IEhOk6mcJFX2uZHfA91ss/dzOXjLRnUVx+oae0=; b=OJTWpqtyzeHEcIAfXi6cIBfj4jxaw6Co7zJpvaATgrD0a9dpz1cO/85SpukWqaLWdA MSh+kJPVo291TLS/DA0itzUHZqWfZYayQuAiVYr1otlaEj33XP3tIZvmlY2zLROu+qDt 8caIkuFFtTH0tdzJ4e0NMeSNK1FOpR8ZhOiLe88KKOW5PaHrE359/yVB+1By8HRUlrPB YM8jBqsEIytV3a+moYJK9pEzFPxDIZGTuQxmUNKsKIU2hruUCRKJLXW7L7kd/LfAyOkT sOjtpONFlPU3l2JHKWvZ8TvzH7Bl/ijtEXfPzXhUIauaYQ5NkFP+Opgk4etvY+S9BujO 9uBw== MIME-Version: 1.0 X-Received: by 10.194.92.197 with SMTP id co5mr54778008wjb.41.1367011866291; Fri, 26 Apr 2013 14:31:06 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:31:06 -0700 (PDT) Date: Fri, 26 Apr 2013 14:31:06 -0700 Message-ID: From: Suhas Nandakumar To: fandreas@cisco.com Content-Type: multipart/alternative; boundary=047d7bf0cf50b1b4a404db4a405d Cc: mmusic WG Subject: [MMUSIC] Review Request- draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5939 Related) 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, 26 Apr 2013 21:31:16 -0000 --047d7bf0cf50b1b4a404db4a405d Content-Type: text/plain; charset=ISO-8859-1 Hello Flemming This is a request for reviewing the following sections 5.28 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/input before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --047d7bf0cf50b1b4a404db4a405d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Flemming
=A0=A0
This is a request for = reviewing the following sections
=A0
5.28
of the draft
=A0 =A0
draft-nandakumar-m= music-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nput before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--047d7bf0cf50b1b4a404db4a405d-- From suhasietf@gmail.com Fri Apr 26 14: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 9D8B421F9CF6 for ; Fri, 26 Apr 2013 14:31:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 SJaM4nhHKsqk for ; Fri, 26 Apr 2013 14:31:28 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4D21F9CE9 for ; Fri, 26 Apr 2013 14:31:26 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so3912800wey.11 for ; Fri, 26 Apr 2013 14:31:26 -0700 (PDT) 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:cc :content-type; bh=6Q27AAVW7lCi9t9YAukWm8OXKoL2/frWsUQv2SpBwgc=; b=fc8Gyxl8jg/4OwYPaJhe3+JxO3eEIu98edP070cwEh9ITzaZCvJb1WlAPdam9NVHZK +isnzZVYCJDT2Reu/BBeiXiI689uBZhMveFYNNIXPJ53o2RMtt3sZiibNJ8Uv/7Rt/eE c4BZN1bDIePeOedA3DTHpod69zD1r9mf9PI5u2IoJLwfJIYunWkMAygLUrTZ80e/AZmE XLlQgwGJmzH8M/uv8y/rX+w0Gp6AhFMatSPKhFmYF3IFgt2ma0qIoI4xn0fZKcCW8us2 1NjedM7stKEnNWjASlvh7QgAoXf/8wiFOl2d4Os/oYBTWSaF3imRqH31eqp/KZrJi1fz TUZw== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr532287wid.29.1367011885946; Fri, 26 Apr 2013 14:31:25 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:31:25 -0700 (PDT) Date: Fri, 26 Apr 2013 14:31:25 -0700 Message-ID: From: Suhas Nandakumar To: christer.holmberg@ericsson.com, staffan.blau@ericsson.com, eburger@standardstrack.com Content-Type: multipart/alternative; boundary=f46d0438914bddc74604db4a419f Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC6714 Related) 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, 26 Apr 2013 21:31:33 -0000 --f46d0438914bddc74604db4a419f Content-Type: text/plain; charset=ISO-8859-1 Hello Christer, Steffan, Eric This is a request for reviewing the following sections 5.22 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d0438914bddc74604db4a419f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Christer, Steffan, Eric
=A0=A0
This is= a request for reviewing the following sections
=A0
5.2= 2

of the draft
=A0 =A0
dra= ft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d0438914bddc74604db4a419f-- From snandaku@cisco.com Fri Apr 26 11:02: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 5EF3F21F99F1 for ; Fri, 26 Apr 2013 11:02:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtSK7cGtTXzP for ; Fri, 26 Apr 2013 11:02:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 92E6421F8DBB for ; Fri, 26 Apr 2013 11:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2635; q=dns/txt; s=iport; t=1366999344; x=1368208944; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/O6WFfwdll06rSeyQfxOA9un0iVmW19CugBhys/w2Xc=; b=AqMOd9ljmx5XXh0FbpfMuZEcx8fBbJZLThp6TeF8Ld+X91cUTjQx9GUJ /APCB5n3buF11h091cwhSKdGNZjxCQItzBaOQ9+s0IddIVpnAER/2yOpI +DCjf5+E/yHdMJbtTRvGe5F1V6Yk1MauhsBBlPKsFtgGSvWsRSxesczFT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAC3AelGtJXHA/2dsb2JhbABRgwc2RL14gQUWdIIfAQEBBHcSAgEIEQQBAQskMhsBAQUDAgQBEggBiAsHBb8PjmE4gm1hA4haj2iQBIFYgTaCKA X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="203554353" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Apr 2013 18:02:24 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3QI2NeP013174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 18:02:23 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.81]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:02:23 -0500 From: "Suhas Nandakumar (snandaku)" To: "mmusic-chairs@tools.ietf.org" , "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-02.txt Thread-Index: AQHOQhU7cac0mmykU0KibZqhF01UdZjoyPBm Date: Fri, 26 Apr 2013 18:02:23 +0000 Message-ID: <37D91FC30D69DE43B61E5EEADD959F1807CB4365@xmb-aln-x12.cisco.com> References: <20130426003015.5595.11202.idtracker@ietfa.amsl.com> In-Reply-To: <20130426003015.5595.11202.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.37.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 26 Apr 2013 14:31:39 -0700 Subject: [MMUSIC] FW: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-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: Fri, 26 Apr 2013 18:02:25 -0000 Hello All=0A= =0A= =A0 A new version of the SDP Attribute Multiplex Draft has been submitted f= or your perusal.=0A= =0A= =A0 The changes include=A0=0A= =A0 =A0 - clarifying the categories with examples=0A= =A0 =A0 - cleaning up category names.=0A= =A0 =A0 - few nits overall.=0A= =0A= We will follow up with emails requesting authors of SDP attributes to revie= w the sections from this draft and provide their valuable feedback on the c= ategorization framework and mux implications.=0A= =0A= Thanks=0A= Suhas=0A= ________________________________________=0A= From: internet-drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Thursday, April 25, 2013 5:30 PM=0A= To: Suhas Nandakumar (snandaku)=0A= Subject: New Version Notification for draft-nandakumar-mmusic-sdp-mux-att= ributes-02.txt=0A= =0A= A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-02.txt=0A= has been successfully submitted by Suhas Nandakumar and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-nandakumar-mmusic-sdp-mux-attributes=0A= Revision: 02=0A= Title: A Framework for SDP Attributes when Multiplexing=0A= Creation date: 2013-04-25=0A= Group: Individual Submission=0A= Number of pages: 55=0A= URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusi= c-sdp-mux-attributes-02.txt=0A= Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sd= p-mux-attributes=0A= Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux= -attributes-02=0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-nandakumar-mmusic= -sdp-mux-attributes-02=0A= =0A= Abstract:=0A= The Session Description Protocol (SDP) provides mechanisms to=0A= describe attributes of multimedia sessions and of individual media=0A= streams (e.g., Real-time Transport Protocol (RTP) sessions) within a=0A= multimedia session. In the RTCWeb WG, there is a need to use a=0A= single 5-tuple for sending and receiving media associated with=0A= multiple media descriptions ("m=3D" lines). Such a requirement has=0A= raised concerns over the semantic implications of the SDP attributes=0A= associated with the RTP Sessions multiplexed over a single transport=0A= layer flow.=0A= =0A= The scope of this specification is to provide a framework for=0A= analyzing the multiplexing characteristics of SDP attributes. The=0A= specification also categorizes existing attributes based on the=0A= framework described herein.=0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= =0A= From suhasietf@gmail.com Fri Apr 26 14:32: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 57B3C21F9CE9 for ; Fri, 26 Apr 2013 14:32:00 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 62T+PhdeZ1Dn for ; Fri, 26 Apr 2013 14:31:59 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD1321F9CEC for ; Fri, 26 Apr 2013 14:31:59 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so716107wgh.1 for ; Fri, 26 Apr 2013 14:31:58 -0700 (PDT) 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:cc :content-type; bh=HmUkvOSDD6hLJcUa/6hrF7hNFN9vdN4DCbY5H6ltkFk=; b=Fz+vvE4a5LFGYVWBupWywKMIUlrwmsjejauLx8IIF+4CD+5wj+BHoATA8cSHkCuSAE yojsdB4491sLmbl/XImr6UcS/wy0qOhLm/9FYi3UfhRifaeML/u8YC1VCtMFDGhZG/eg 0DKPCTW85W2xlI3k6nThnJ9SUyR7HG6AQRZ9NzLdMG6Jt19xSLyvStEmT6Y+9vJB3HwQ TkJZL9ESyFJkNWUimn2Cv3oKF9huBfiVkQqT+8yyfVQE/ilCJYOR4RVENoTHuikrgKj/ Dp2XNgAoK3StXA0q20ids49xvBx/4qpiPFszjH/2IunvfmMls1R0feYX5VJBpdKm7xV6 V1GA== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr533945wid.29.1367011918787; Fri, 26 Apr 2013 14:31:58 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 14:31:58 -0700 (PDT) Date: Fri, 26 Apr 2013 14:31:58 -0700 Message-ID: From: Suhas Nandakumar To: magnus.westerlund@ericsson.com, ingemar.s.johansson@ericsson.com, csp@csperkins.org, piers.ohanlon@oii.ox.ac.uk, carlberg@g11.org.uk Content-Type: multipart/alternative; boundary=f46d0438914bd2bd7a04db4a437d Cc: mmusic WG Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC6679 Related) 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, 26 Apr 2013 21:32:00 -0000 --f46d0438914bd2bd7a04db4a437d Content-Type: text/plain; charset=ISO-8859-1 Hello Magnus, Ingemar, Colin, Piers, Ken This is a request for reviewing the following sections 8.3 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --f46d0438914bd2bd7a04db4a437d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Magnus, Ingemar, Colin, Piers, Ken
=A0=A0
<= div>This is a request for reviewing the following sections
=A0
8.3=A0

of the draft
=A0 =A0<= /div>
draft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar
--f46d0438914bd2bd7a04db4a437d-- From bernard_aboba@hotmail.com Fri Apr 26 14:34: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 A512121F9870 for ; Fri, 26 Apr 2013 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dSJVBZoBTvGH for ; Fri, 26 Apr 2013 14:33:59 -0700 (PDT) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id 425E321F9687 for ; Fri, 26 Apr 2013 14:33:59 -0700 (PDT) Received: from BLU169-W123 ([65.55.116.7]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Apr 2013 14:33:58 -0700 X-EIP: [KIeu5M3Knk6X/OMl+KGRZsn7jlPKg5jX0G8+CyuDl7E=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_77fd41c5-2374-469b-b3ef-3ba8eb5da13d_" From: Bernard Aboba To: Suhas Nandakumar Date: Fri, 26 Apr 2013 14:33:58 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2013 21:33:58.0908 (UTC) FILETIME=[C31273C0:01CE42C5] Cc: mmusic WG Subject: Re: [MMUSIC] Review Request spam 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, 26 Apr 2013 21:34:00 -0000 --_77fd41c5-2374-469b-b3ef-3ba8eb5da13d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me suggest that you do not need to send individual review requests for = every section in the document. =20 Date: Fri=2C 26 Apr 2013 14:31:58 -0700 From: suhasietf@gmail.com To: magnus.westerlund@ericsson.com=3B ingemar.s.johansson@ericsson.com=3B c= sp@csperkins.org=3B piers.ohanlon@oii.ox.ac.uk=3B carlberg@g11.org.uk CC: mmusic@ietf.org Subject: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attribut= es-02 - (RFC6679 Related) Hello Magnus=2C Ingemar=2C Colin=2C Piers=2C Ken This is a request for rev= iewing the following sections 8.3=20 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02=0A= =0A= =0A= =0A= =20 It will be greatly appreciated if you could inform on your willingness for = reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June = 9th 2013.=0A= =0A= =0A= =0A= The document is available here:http://tools.ietf.org/html/draft-nandakumar-= mmusic-sdp-mux-attributes-02 =0A= =0A= =0A= =0A= Thanks in Advance RegardsSuhas Nandakumar=0A= _______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic = --_77fd41c5-2374-469b-b3ef-3ba8eb5da13d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let me suggest that you do not n= eed to send individual review requests for every section in the document. <= BR> =3B

 =3B
<= hr id=3D"stopSpelling">Date: Fri=2C 26 Apr 2013 14:31:58 -0700
From: suh= asietf@gmail.com
To: magnus.westerlund@ericsson.com=3B ingemar.s.johanss= on@ericsson.com=3B csp@csperkins.org=3B piers.ohanlon@oii.ox.ac.uk=3B carlb= erg@g11.org.uk
CC: mmusic@ietf.org
Subject: [MMUSIC] Review Request -= draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC6679 Related)

<= div dir=3D"ltr">Hello Magnus=2C Ingemar=2C Colin=2C Piers=2C Ken
 = =3B =3B
This is a request for reviewing the following section= s
 =3B
8.3 =3B

of the = draft
 =3B  =3B
draft-nandakumar-mmusic-sdp= -mux-attributes-02
=0A= =0A= =0A= =0A=
 =3B =3B =3B
It will be greatly appreciated = if you could inform on your willingness for reviewing the aforementioned se= ssions.

It would be great to have your review feed= back/comments/inputs before June 9th 2013.
=0A= =0A= =0A= =0A=

The document is available here:

 =3B
Thanks in Advance

Regards
Suhas Nandakumar
=0A=
_______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic
= --_77fd41c5-2374-469b-b3ef-3ba8eb5da13d_-- From suhasietf@gmail.com Fri Apr 26 16:22: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 6DD1321F9D1F for ; Fri, 26 Apr 2013 16:22:48 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 FW1jyIeJPodl for ; Fri, 26 Apr 2013 16:22:44 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5D221F9D20 for ; Fri, 26 Apr 2013 16:22:41 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s10so3850570wey.7 for ; Fri, 26 Apr 2013 16:22:37 -0700 (PDT) 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:cc :content-type; bh=KAXXSbe4ageeP/NW9YF68nOjuNottoXeBG4ZJA43yzQ=; b=D4SEM0OG5UmhjgmKIhKOpx9ppP8rURo8a3HWh5EpMEAapPODtIXTLCt2yqAjr3AVrn anYjTdXK0keoLnu6/4dmP8lnVNusbPp7f7cCqR/uqMZW9ta4hRJ0NM9LaI6JukUTj9Dl 7WSvOUn3OHygOLAT1sD+18PJWwtIH/nuSlp/3GvVw/xytfN+K/9lO+GqoBpzKPa/Asl2 ifAtzmOnscKxX1H+iIcpURkQe7iE/bmdqtF4aSwXuyonbsyjcWdiDuu+UZaJIWn2oxNk hrfwK/xRt3jBKtfTo49Zrf2Mj0vZegw5BIaask/3pMJoxRSqVMOJ+UbB876DSz5Y484Q 9Y4w== MIME-Version: 1.0 X-Received: by 10.194.176.195 with SMTP id ck3mr63695639wjc.5.1367018557708; Fri, 26 Apr 2013 16:22:37 -0700 (PDT) Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 16:22:37 -0700 (PDT) Date: Fri, 26 Apr 2013 16:22:37 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , mmusic-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=089e013d0a3e889d2204db4bcf1b Cc: Cullen Jennings , snandaku@cisco.com Subject: [MMUSIC] Call for Review - draft-nandakumar-sdp-attributes-mux (1 Inclusive Email) 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, 26 Apr 2013 23:22:55 -0000 --089e013d0a3e889d2204db4bcf1b Content-Type: text/plain; charset=ISO-8859-1 Hello All, My apologies for flooding your inbox with the review request emails. As suggested, I have included the various sections and the assigned reviewers in the table below as well as a google spreadsheet for the same (link below) Draft Location: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Review Deadline: June 9th 2013 Review Assignment Google Spreadsheet: https://docs.google.com/spreadsheet/pub?key=0Aksfg6M2xJgudGpLZy1MUmx5ajZBdTdKY0JxZVlfZXc&output=html I would greatly appreciate, If the reviewers could inform me on their willingness to review their assigned sections. It would be great to have your feedback/comments before June 9th 2013. Section to Review Primary Reviewers Secondary Reviewers 5.43 MMusic Chairs Bernard Aboba 5.44 MMusic Chairs Roni Even 5.4 MMusic Chairs Christer Holmberg 5.41 MMusic Chairs Christer Holmberg 5.42 MMusic Chairs Gonzalo Camarillo 10.3 Jonathan. Rosenberg, Gonzalo Camarillo 5.14, 11.1 Jonathan. Lennox, Joerge Ott 5.31 Jonathan Lennox 7.2, 9.1 Stephan Wenger, Bo Burman, Magnus Westerlund 10.1 Gonzalo Camarillo, Henning Schulzrinne 5.2, 7.1, 8.1 Joerge Ott, Stephan Wenger Jose Rey, Noriyuki Sato Christer Holmberg, Harald 5.29 Flemming Andreason, Robert Gillman 5.25 Hadriel Kaplan, Paul E Jones 5.39 Rajesh Kumar, Mohamed Mostafa 5.2 Flemming Andreasen 10.2 Gonzalo Camarillo, Atle Monrad 6.2 Stephen L. Casner Magnus Westerlun 5.13 Christian Huitema Jonathan Lennox 5.27 Kevin Almeroth, Roman Caceres, Alan Clark, Robert G Cole Jonathan Lennox 6.3 Magnus Westerlund 5.11 Jonathan Rosenberg EKR 5.35 Gonzalo Camarillo 5.3 Jari Arkko, Fredrick Lindholm, Elisabetta Carrara Magnus Westerlund 5.6 Dan Wing, Flemming Andreasen 5.32 Bon Quinn, Ross Finlayson 5.31 Jonathan Lennox 5.4 Orit Levin, Gonzalo Camarillo Cullen Jennings 5.23 Gonzalo Camarillo 5.19, 14.1 J. Hautakorpi, Gonzalo Camarillo 5.45 Cullen Jennings, Ben Campbell Adam Roach 15.1 Adam H. Li Flemming Andreason, Magnus Westerlund 5.36 Lakshminath Dondeti, Anja Jerichow Dean Willis 5.5, 12.1 Subha Dhesikan, James Polk Gonzalo Camarillo 5.12 David. Singer, Harikishan Desineni 5.9 Magnus Weterlund, Ingemar Johansson 5.24 Paul Kyzivat, Gonzalo Camarillo, Salvatore 10.5 Stephan Wenger, Tom Schierl Flemming Andreason 5.26 Joerge Ott, Julian Chesterfield Eve Schooler 5.3 Magnus Westerlund, Colin Perkins 5.7 Colin Perkins Jason Fischl, Hannes Tschofenig, EKR Cullen Jennings 5.28 Flemming Andreason 10.4 Ali Begen Flemming Andreason 5.38 Magnus Westerlund, Per Frojdh 5.33 Ali C Begen 5.34 Pal Zimmermann, Alan Johnston, Jon Callas Dan Wing 5.37 Dan Wing Dan Wing 5.17 Chris Boulton, Tim Melanchuk, Scott McGlashan Roni Even 5.15 Ingemar Johansson, Kyunghun Jung HTA, Lennox 5.21 A. Begen, D. Wing 5.16, 8.2 Ali C Begen, Bill Ver Steeg 5.18 Ali C Begen 8.4 Roni Even, Frank Xia, Qin Wu 8.3 Magnus Westerlund, Ingemar Johansson, Colin Perkins 5.22 Christer Holmberg 5.1 Dan. Burnett, Saravanan Shanmugham 5.1, 13.1 Colin Perkins, Van Jacobson, Mark Handley Ali C Begen 5.46 MMusic Chairs 5.8 Tom Phelan, Colin Perkins Thanks In Advance Regards Suhas Nandakumar --089e013d0a3e889d2204db4bcf1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,=A0

=A0 My apologies for= flooding your inbox with the review request emails.

=A0 As suggested, I have included the various sections and the assigned = reviewers in the table below as well as a google spreadsheet for the same (= link below)

=A0 Draft Location:=A0


= =A0 Review Deadline:

=A0 =A0 =A0June 9th 2013

=A0Review Assignment Google Spreadsheet:


=A0 I would greatly appreciate, If the r= eviewers could inform me on their willingness to review their assigned sect= ions. It would be great to have your feedback/comments before June 9th 2013= .

=A0=A0
Section to Review Primary Reviewers Secondary Reviewers
5.43 MMusic Chairs Bernard=A0 Aboba
5.44 MMusic Chairs Roni Even
5.4 MMusic Chairs Christer Holmberg
5.41 MMusic Chairs Christer Holmberg
5.42 MMusic Chairs Gonzalo Camarillo
10.3 Jonathan. Rosenberg, Gonzalo Camarillo =A0
5.14, 11.1 Jonathan. Lennox,
=A0Joerge Ott		 =A0
5.31 Jonathan Lennox =A0
7.2, 9.1 Stephan Wenger,
Bo Burman,
Magnus Westerlund		 =A0
10.1 Gonzalo Camarillo,=A0
Henning Schulzrinne		 =A0
5.2, 7.1, 8.1 Joerge Ott,
Stephan Wenger
Jose Rey,
Noriyuki Sato		 =A0
=A0 Christer Holmberg,
Harald		 =A0
5.29 Flemming Andreason,
=A0Robert Gillman		 =A0
5.25 Hadriel Kaplan,
Paul E Jones		 =A0
5.39 Rajesh Kumar,
Mohamed Mostafa		 =A0
5.2 Flemming Andreasen =A0
10.2 Gonzalo Camarillo,
=A0Atle Monrad		 =A0
6.2 Stephen L. Casner Magnus Westerlun
5.13 Christian Huitema Jonathan Lennox
5.27 Kevin Almeroth,
Roman Caceres,
Alan Clark,
Robert G Cole		 Jonathan Lennox
6.3 Magnus Westerlund =A0
5.11 Jonathan Rosenberg EKR
5.35 Gonzalo Camarillo =A0
5.3 Jari Arkko,
Fredrick Lindholm,
Elisabetta Carrara		 Magnus Westerlund
5.6 Dan Wing,
Flemming Andreasen		 =A0
5.32 Bon Quinn,
Ross Finlayson		 =A0
5.31 Jonathan Lennox =A0
5.4 Orit Levin, Gonzalo Camarillo Cullen Jennings
5.23 Gonzalo Camarillo =A0
5.19, 14.1 J. Hautakorpi, Gonzalo Camarillo =A0
5.45 Cullen Jennings,
Ben Campbell		 Adam Roach
15.1 Adam H. Li Flemming Andreason,
Magnus Westerlund
5.36 Lakshminath Dondeti,
Anja Jerichow		 Dean Willis
5.5, 12.1 Subha Dhesikan,
James Polk
Gonzalo Camarillo		 =A0
5.12 David. Singer,
Harikishan Desineni		 =A0
5.9 Magnus Weterlund,
Ingemar Johansson		 =A0
5.24 Paul Kyzivat,
Gonzalo Camarillo,
Salvatore		 =A0
10.5 Stephan Wenger,
Tom Schierl		 Flemming Andreason
5.26 Joerge Ott,
Julian Chesterfield
Eve Schooler		 =A0
5.3 Magnus Westerlund,
Colin Perkins		 =A0
5.7 Colin Perkins =A0
=A0 Jason Fischl,
Hannes Tschofenig,
=A0EKR		 Cullen Jennings
5.28 Flemming Andreason =A0
10.4 Ali Begen Flemming Andreason
5.38 Magnus Westerlund,
Per Frojdh		 =A0
5.33 Ali C Begen =A0
5.34 Pal Zimmermann,
Alan Johnston,
Jon Callas		 Dan Wing
5.37 Dan Wing Dan Wing
5.17 Chris Boulton,
Tim=A0 Melanchuk,
Scott McGlashan		 Roni Even
5.15 Ingemar Johansson,
Kyunghun Jung		 HTA, Lennox
5.21 A. Begen, D. Wing =A0
5.16, 8.2 Ali C Begen,
Bill Ver Steeg		 =A0
5.18 Ali C Begen =A0
8.4 Roni Even,
Frank Xia,
Qin Wu		 =A0
8.3 Magnus Westerlund,
Ingemar Johansson,
=A0Colin Perkins		 =A0
5.22 Christer Holmberg =A0
5.1 Dan. Burnett,
Saravanan Shanmugham		 =A0
5.1, 13.1 Colin Perkins,
Van Jacobson,
Mark Handley		 Ali C Begen
5.46 MMusic Chairs =A0
5.8 Tom Phelan,
Colin Perkins		 =A0


Thanks In Advance

Regards
Suhas Nandakumar
--089e013d0a3e889d2204db4bcf1b-- From martin.thomson@gmail.com Fri Apr 26 20:07: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 35AEC21F9D3D for ; Fri, 26 Apr 2013 20:07:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gidYN3gK3t9m for ; Fri, 26 Apr 2013 20:07:52 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6070A21F9A06 for ; Fri, 26 Apr 2013 20:07:52 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id s47so3232352wey.8 for ; Fri, 26 Apr 2013 20:07:51 -0700 (PDT) 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=XGUs949fjmOcflqTqx1weuYPY36fAl9DTnt9SaUf+NI=; b=bKHBgW2234SX5UXfYx0gxLe7TdUrIBhhqYdDKaJ47rvmQ3y1KXIyuutItXd5XgMUsA OOXCEsQ77baNvdS2eo/Sfihqa8zHgRYxvcfkgUa50kxfgWXhsvQjHvWF9tNO3AbhsLLe b8kS3HNEFjTYSc8s+6m82NtzQFfWWNIwRQMXOSoc67yAZ3/q16a97kdTjbkZceQBefVa cJrhTHJKykKHzHXj97fnAWTE5j0VDU78Larz+ezLJt8uTLzHrZDaiLnPZRHZRX66wmGt BHEk8TSop8BtQ+QDYSu93ZeSlXoxtqo02qfY1SldRrBAULnZzuGgdaLm/NCU0rdClea3 3tYg== MIME-Version: 1.0 X-Received: by 10.180.198.49 with SMTP id iz17mr7268500wic.19.1367032071451; Fri, 26 Apr 2013 20:07:51 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Fri, 26 Apr 2013 20:07:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Apr 2013 20:07:51 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: mmusic WG Subject: Re: [MMUSIC] Review Request spam 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, 27 Apr 2013 03:07:53 -0000 On 26 April 2013 14:33, Bernard Aboba wrote: > Let me suggest that you do not need to send individual review requests for > every section in the document. Yeah, the volume on this list was approaching it, but it just went past "tl;dr". From johnsonhammond1@hushmail.com Sat Apr 27 10:37: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 EEC9321F9838 for ; Sat, 27 Apr 2013 10:37:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmAWMjk28Zvb for ; Sat, 27 Apr 2013 10:37:18 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37C21F9837 for ; Sat, 27 Apr 2013 10:37:18 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id D6FA030AE7 for ; Sat, 27 Apr 2013 17:37:17 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:37:17 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A6074E6739; Sat, 27 Apr 2013 17:37:17 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:37:17 -0400 To: mmusic@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173717.A6074E6739@smtp.hushmail.com> Subject: [MMUSIC] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:33:03 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From martin.thomson@gmail.com Sat Apr 27 14:56: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 26FA621F983A for ; Sat, 27 Apr 2013 14:56:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrFwm8Q3ZPGd for ; Sat, 27 Apr 2013 14:56:51 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18421F9839 for ; Sat, 27 Apr 2013 14:56:51 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id h11so1672395wiv.14 for ; Sat, 27 Apr 2013 14:56:50 -0700 (PDT) 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=6cHeI0hKt7yPAh6nZ0vBGBJi8DSI/upFNgzC3imoDyw=; b=nNgq1Er9Mz/w7SLH7PeNMLxuNRWzf69Z3vF3/zSDLeME+BcbDc5fFA2WZJfoxvgV7+ FyebV1+3v+Oev57IBYqpfwsSvV72uiSxV8xowtmC5NacQwgFR/Aci/75Oq02gUvSHCCg ISv9HDwoSkrrFw2bCpM7n9gN24yNikZyyhRIXpRYQFjYE/Y3z0oWlIdwZuInoUTJpbnN En8rPW7N0j0TsvHUyC14KPqrDVNO0d6WgRvZXTq/af9LImjKK4mngv6IyCoXY+mZLFXB lRfgUAtAQBK3WH9qda2CsbJZBP+jHCGmigj+RcBcVuVA0h+U1Jzrkrc3qGLWLu9mZ2AB wEBg== MIME-Version: 1.0 X-Received: by 10.194.236.169 with SMTP id uv9mr7822695wjc.42.1367099810604; Sat, 27 Apr 2013 14:56:50 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Sat, 27 Apr 2013 14:56:50 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C35F453@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C35F453@ESESSMB209.ericsson.se> Date: Sat, 27 Apr 2013 14:56:50 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions 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, 27 Apr 2013 21:56:52 -0000 I finally found something in all the noise. On 25 April 2013 07:03, Christer Holmberg wrote: >>5. From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session? > > As people have indicated, it prevents a two-time pad attack, and that is also the only reason I can think of. My suggestion is to keep the restriction in list 1 and 2. But, if someone OBJECTS to this, please indicate so. The two-time pad thing is bogus, unless you are using shim (so that you can reuse SSRCs). I think that I would like to OBJECT to this. It is possible to perform decrypt after demux, and there are no inherent problems. I initially wasn't that concerned with people taking this position, because I figured that it would be better to allow for some flexibility in the order of operations. However, it makes multiplexing translators harder to build. It's not a strong objection. After all, we are all in the business of accelerating the heat death of the universe. >> 6. If you start with a m= line with one SDES config (e.g. 32-bit MAC), and then BUNDLE with another SDES line with a different (non overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume fail) > > People have indicated that this would be a failure, and I have seen no one indicate otherwise. But, if someone OBJECTS to this, please indicate so. See above. From christer.holmberg@ericsson.com Mon Apr 29 06:06: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 BBD3721F998F for ; Mon, 29 Apr 2013 06:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 6Ios1vwKv8Kt for ; Mon, 29 Apr 2013 06:06:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16CE521F997D for ; Mon, 29 Apr 2013 06:06:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-4b-517e703ee6df Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C8.CF.10459.E307E715; Mon, 29 Apr 2013 15:06:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 15:06:06 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4ggAB69ACAACdgz4AAEvyAgARXjRA= Date: Mon, 29 Apr 2013 13:06:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C368210@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se> <517AE347.40401@alum.mit.edu> In-Reply-To: <517AE347.40401@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C368210ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvra59QV2gwcxvPBZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+UdSQU9qxad515kaGBuCuxg5OSQETCS2 /F/BCmGLSVy4t56ti5GLQ0jgMKPEwl3zmEESQgJLGCVetep2MXJwsAlYSHT/0wYJiwhoSRy4 cpkFJMwsoC5xdXEQiCksoCvxeHEMiCkioCfRcqIGothP4sP9i0wgNouAqsSks4uYQEp4BXwl nk6rhNj5mkliz9s1YDs5gYY//dIIVs8IdNj3U2vAbGYBcYlbT+YzQRwsILFkz3lmCFtU4uXj f1CPKEp8fLWPEaI+X+L07Hlg9bwCghInZz5hmcAoOgvJqFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGNlzEzNz0ssNNzECI+nglt+6OxhPnRM5xCjNwaIkzjtdqjJQSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2N48/Xtp86vi2Q43dqvsW2md3vzjB9SC/9pZcp9vS6e En+p56/R/7Ljr5+vPKny7PLqqjk2hWaW8rGn48zaFsY+LhF957FhuVXK1fXV7BvdXLPSLrlM SlW6mh+R6ZqhFBF+89a9xA93Z58/84f/S+yrGZy7EmYmHHzi4yL88o+ZvufUtbmvGRqVWIoz Eg21mIuKEwHzk5R1cgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 29 Apr 2013 13:06:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C368210ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think we can separate this into 3 questions: 1) How is a receiver able to demux transport flows associated with differen= t "transport flow usages" (here I consider RTP one usage, the data channel = another, etc). Now, the general first step is of course to separate based on the IP header= Protocol value. But, of course, if you have multiple flows with the same usage (e.g. multip= le RTP flows), that it is not enough. Also, if you have SCTP on top of UDP (as in our case for the data channel),= you need to go up on the SCTP level in order to figure out what it is used= for. 2) How is a receiver able to associated a transport flow with its associate= d SDP m- line. This becomes an issue when multiple m- lines are associated with the same t= ransport flow usage, e.g. when you have multiple m- lines for RTP. 3) How is a receiver able to, within an m- line, identify a media flow. This becomes an issue e.g. when multiple RTP flows are associated with a si= ngle m- line. But, as I said before, this is not a BUNDLE specific problem. Regarding 2) and 3), the most common solutions that have been discussed are= usage of PAYLOAD and/or SSRC. As we know, people have expressed concern ab= out using PAYLOAD, due to the limited number of PT values available. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Friday, April 26, 2013 10:28 PM To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL On 4/26/13 1:33 PM, Christer Holmberg wrote: > > Hi, > >>>>> Yes - we need a way to signal the demux mechanism to be used. >>>>> (Unless there is only one possibility. And we have already >>>>> disproved >>>>> that.) >>>> >>>> We could use different group "semantics" values to indicate the >>>> multiplexing mechanism. One endpoint could probe the other to >>>> discover which mechanisms it supplies by offering a collection of bund= les containing no constituents, one for each mechanism. The answer will sh= ow which mechanisms the answerer supports. >>> >>> My idea was the endpoint simply lists the media description proto value= s that it is capable of multiplexing for a given 5-tuple: >>> >>> Example: a=3Dmuxcap: RTP/AVP, SCTP/DTLS >>> >>> ...or something like that. >> >> That is sufficient *if* there is a single mux/demux algorithm per proto. >> >> But I don't think that is true. I think we will need to signal this >> per-m-line, and specify the demux algorithm(s) for streams that bind >> to that m-line. > > I don't it matters if there are multiple algorithms - the important thing= is that the endpoint is able to mux/demux the specific proto using A algor= ithm. > > Otherwise, we can have different values, one for each algorithm. Note tha= t in my example I used to SDP proto values, but we could use whatever. My point is that both sides need to *agree* on what mechanism is used to mu= x/demux the streams - in order to associate each received packet with the c= orrect m-line. So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is not sufficient wi= thout saying *how* it will be done. (Except in cases where there is a mutua= l understanding that there is only one way, or a default way.) > HOWEVER, before we go into the details, I would like to know whether peop= le generally think we need a mechanism which allows to list the protos an e= ndpoint is able to mux/demux. > >>> Of course, an endpoint needs to be able to multiplex all media that it = inserts in a bundle group. But, it may not always insert m- lines for every= thing it is able to multiplex, so I think an explicit indication would be g= ood. >> >> There may be more than one stream per m-line, but I think we can assume = that every stream binds to one m-line. > > I am not sure I understand what you mean by "binds to one m-line". > > However, keep in mind there can be multiple streams per m- line > already today (at least for RTP), so it's not something BUNDLE > specific :) My point is that the *goal* of this exercise is to be able to associate eac= h incoming packet with exactly one of the bundled m-lines. So there must be an unambiguous mapping that does that - "binds" each packe= t to the m-line it belongs with. >>> It is important to remember that, whatever you multiplex, all media hav= e to use the same IP transport (e.g. UDP). >> >> Unfortunately SDP has a pretty confusing idea of "transport". >> The proto field identifies a whole stack of protocol layers. > > Yes, and therefor, when we say "must use the same protocol", we need > to make it clear that we refer to the Protocol value in the IP header > - not the proto value in the SDP media description :) > > I will reply to the rest of your e-mail later, because I need a little > more time to read it :) OK. Thanks, Paul --_000_7594FB04B1934943A5C02806D1A2204B1C368210ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I think we can separate this into 3 questions:
 
1) How is a receiver able to demux transport flows associate= d with different "transport flow usages" (here I co= nsider RTP one usage, the data channel another, etc).
 
Now, the general first step is of course to separate based on the IP h= eader Protocol value.
 
But, of course, if you have multiple flows with the same usage (e.g. m= ultiple RTP flows), that it is not enough.
 
Also, if you have SCTP on top of UDP (as in our case for the data chan= nel), you need to go up on the SCTP level in order to figure out what it is= used for.
 
 
2) How is a receiver able to associated a transport f= low with its associated SDP m- line.
 
This becomes an issue when multiple m- lines are associated with the s= ame transport flow usage, e.g. when you have multiple m- lines for RTP.
 
 
3) How is a receiver able to, within an m- line, identify a = media flow.
 
This becomes an issue e.g. when multiple RTP flows are associated with= a single m- line. But, as I said before, this is no= t a BUNDLE specific problem.
 
 
Regarding 2) and 3), the most common solutions that have been discusse= d are usage of PAYLOAD and/or SSRC. A= s we know, people have expressed concern about using PAYLOAD, due to the li= mited number of PT values available.
 
Regards,
 
Christer
 
 
 
 
 
 
 
 
-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]
Sent: Friday, April 26, 2013 10:28 PM
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL
 
On 4/26/13 1:33 PM, Christer Holmberg wrote:
>
> Hi,
>
>>>>> Yes - we need a way to signal the demux mechanism= to be used.
>>>>> (Unless there is only one possibility. And we hav= e already
>>>>> disproved
>>>>> that.)
>>>>
>>>> We could use different group "semantics" va= lues to indicate the
>>>> multiplexing mechanism.  One endpoint could prob= e the other to
>>>> discover which mechanisms it supplies by offering a c= ollection of bundles containing no constituents, one for each mechanism.&nb= sp; The answer will show which mechanisms the answerer supports.
>>>
>>> My idea was the endpoint simply lists the media descripti= on proto values that it is capable of multiplexing for a given 5-tuple:
>>>
>>>        Example: a=3Dmu= xcap: RTP/AVP, SCTP/DTLS
>>>
>>> ...or something like that.
>>
>> That is sufficient *if* there is a single mux/demux algorithm= per proto.
>>
>> But I don't think that is true. I think we will need to signa= l this
>> per-m-line, and specify the demux algorithm(s) for streams th= at bind
>> to that m-line.
>
> I don't it matters if there are multiple algorithms - the importa= nt thing is that the endpoint is able to mux/demux the specific proto using= A algorithm.
>
> Otherwise, we can have different values, one for each algorithm. = Note that in my example I used to SDP proto values, but we could use whatev= er.
 
My point is that both sides need to *agree* on what mechanism is used = to mux/demux the streams - in order to associate each received packet with = the correct m-line.
 
So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is no= t sufficient without saying *how* it will be done. (Except in cases where t= here is a mutual understanding that there is only one way, or a default way= .)
 
> HOWEVER, before we go into the details, I would like to know whet= her people generally think we need a mechanism which allows to list the pro= tos an endpoint is able to mux/demux.
>
>>> Of course, an endpoint needs to be able to multiplex all = media that it inserts in a bundle group. But, it may not always insert m- l= ines for everything it is able to multiplex, so I think an explicit indicat= ion would be good.
>>
>> There may be more than one stream per m-line, but I think we = can assume that every stream binds to one m-line.
>
> I am not sure I understand what you mean by "binds to one m-= line".
>
> However, keep in mind there can be multiple streams per m- line <= /div>
> already today (at least for RTP), so it's not something BUNDLE
> specific :)
 
My point is that the *goal* of this exercise is to be able to associat= e each incoming packet with exactly one of the bundled m-lines.
So there must be an unambiguous mapping that does that - "binds&q= uot; each packet to the m-line it belongs with.
 
>>> It is important to remember that, whatever you multiplex,= all media have to use the same IP transport (e.g. UDP).
>>
>> Unfortunately SDP has a pretty confusing idea of "transp= ort".
>> The proto field identifies a whole stack of protocol layers.<= /div>
>
> Yes, and therefor, when we say "must use the same protocol&q= uot;, we need
> to make it clear that we refer to the Protocol value in the IP he= ader
> - not the proto value in the SDP media description :)
>
> I will reply to the rest of your e-mail later, because I need a l= ittle
> more time to read it :)
 
OK.
 
        Thanks,
        Paul
 
 
 --_000_7594FB04B1934943A5C02806D1A2204B1C368210ESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Apr 29 07: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 C627521F9E02 for ; Mon, 29 Apr 2013 07:41:46 -0700 (PDT) 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.900, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, 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 j27TLdsKNv7E for ; Mon, 29 Apr 2013 07:41:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8375121F9E01 for ; Mon, 29 Apr 2013 07:41:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-08-517e86a89ea1 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 21.BD.10459.8A68E715; Mon, 29 Apr 2013 16:41:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 16:41:44 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example Thread-Index: AQHOROerK6zVj1eHRk6swZvbxIJomw== Date: Mon, 29 Apr 2013 14:41:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3682C9@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+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvre6KtrpAg/YTWhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxo4OrYLt4xcM37awNjM2CXYycHBICJhJf zv5mhLDFJC7cW8/WxcjFISRwmFHizsod7BDOEkaJE/tmsXQxcnCwCVhIdP/TBjFFBDQkJm1V AzGZBdQlri4OAjGFBewknnz2BJkoImAvseL+f0aIYj2JiTvCQcIsAqoSd+eeYgKxeQV8JZZ9 +AVmMwId8P3UGjCbWUBc4taT+UwQhwlILNlznhnCFpV4+fgfK8hICQFFieX9chDlOhILdn9i g7C1JZYtfM0MMV5Q4uTMJywTGEVmIZk6C0nLLCQts5C0LGBkWcXInpuYmZNebriJERjmB7f8 1t3BeOqcyCFGaQ4WJXHe6VKVgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYPZTkDRfZOTZK znqhyrv+3001u+bLL6fMfPTNbdqHhxmMm1z/beJLLG24nx/M0XFZr9twtdvXuPhb030WF5tP NrBnviPAsFWh40dYxpQeyae1nx59uat994p8o8MklonFG6Z/KCzZyb2B6eDSLQkxyhaLHvNE 3t67ok7wBZvoBP9HVz3muR19pMRSnJFoqMVcVJwIAE9YBFFBAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example 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, 29 Apr 2013 14:41:47 -0000 Hi, > For instance, consider the following: > > ... > c=3DIN IP4 host.biloxi.com > a=3Dgroup:BUNDLE m1 m2 m3 m4 > m=3Daudio 20000 RTP/SAVPF 0 > a=3Dmid:m1 > a=3Dssrc:12345 cname:user@example.com > a=3Dmax-send-ssrc:{*:1} > a=3Dmax-recv-ssrc:{*:1} > ... > m=3Dvideo 20000 RTP/SAVPF 96 98 > a=3Dmid:m2 > a=3Dssrc:5678 cname:user@example.com > a=3Dmax-send-ssrc:{*:1} > a=3Dmax-recv-ssrc:{*:1} > ... > m=3Dvideo 20000 RTP/SAVPF 96 98 > a=3Dmid:m3 > a=3Dmax-send-ssrc:{*:4} > a=3Dmax-recv-ssrc:{*:4} > ... > m=3Dapplication 20000 DTLS/SCTP ... > a=3Dmid:m4 > ... > > We have four bundled m-lines. We have one proto (RTP/SAVPF) in three > m-lines, and another (DTLS/SCTP) in the other m-line. From a protocol > layering perspective we have: > > m1 m2 m3 m4 > =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D > SAVPF SAVPF SAVPF SCTP > RTP RTP RTP DTLS > UDP UDP UDP UDP > IP IP IP IP > > So, the first demux that must be done is to distinguish RTP from DTLS. > DTLS has been designed to have a field that distinguishes it from > RTP/RTCP/ICE, so that can perhaps be considered a default demux > algorithm for that. Correct. > Because there is only one SCTP m-line, that is enough to identify those > packets that should be bound to m4. In your example there is only one SCTP m- line, and in WebRTC I guess it wi= ll also be the case, but SDP doesn't prevent you from using multiple SCTP m= - lines - unless BUNDLE explicitly forbids it, that is. > But we need to use something else to sort out the RTP. > > In this example, payload type can be used to distinguish audio from > video. But there may be cases where that isn't possible. If we want to > allow this mechanism, then perhaps we need some way to signal that it > should be used. Or *maybe* we could count on it being inferred. Assuming > that is used, then it is sufficient to identify those packets that > belong to m1. > > Or, because m1 is marked as having at most one ssrc, and the ssrc value > (1234) is specified, that could be used to bind packets to m1. > > Similarly, RTP packets having ssrc=3D5678 can be bound to m2. > > m3 supports multiple unspecified SSRCs. Since there is only one m-line > that does, all the packets with pt 96 or 98 and with an ssrc other than > 1234 or 5678 can be bound to m3. > > I'm undecided if we can count on inferring this decision logic from > existing signaling options, or if we ought to signal the choices more > explicitly. At least I think that, based on e-mail discussions, we most likely cannot r= ely on unique payload type values for each RTP flow.=20 (Nothing of course forbids users from using unique payload type values.) Regards, Christer From christer.holmberg@ericsson.com Mon Apr 29 07:44: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 CF8FC21F9E53 for ; Mon, 29 Apr 2013 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 2y+5KQIpPo55 for ; Mon, 29 Apr 2013 07:44:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D14921F9E4C for ; Mon, 29 Apr 2013 07:44:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-be-517e874303d3 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B9.FD.10459.3478E715; Mon, 29 Apr 2013 16:44:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 16:44:19 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4ggAB69ACAACdgz4AAEvyAgARXjRCAACBWzw== Date: Mon, 29 Apr 2013 14:44:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3682DB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se> <517AE347.40401@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C368210@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C368210@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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra5ze12gwe1ZOhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7cIj5oLrWhWth1rYGxgPKHYxcnJICJhI vJ7Uwg5hi0lcuLeerYuRi0NI4DCjxO5PvcwQzhJGif9zfzJ1MXJwsAlYSHT/0wZpEBHQkjhw 5TILSJhZQF3i6uIgEFNYQFfi8eIYEFNEQE+i5UQNRHGYxK/NL1lAbBYBVYkTrVfZQGxeAV+J a7v+MEIs2sAs8enbd7AEp4CfxPKDR8EaGIFO+35qDROIzSwgLnHryXwmiJMFJJbsOc8MYYtK vHz8jxVkr4SAosTyfjmIch2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYxis5BMnYWkZRaSlllI WhYwsqxiZM9NzMxJLzfcxAiMjoNbfuvuYDx1TuQQozQHi5I473SpykAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjDI7ezYJ3217tO2jROaCBRk6XjNkGgt05+hLJ12I3bLpV/YxR6YFN0/G PT6reULKbEukqlNq9pOG/be2LlTZ8jjIeMHrOObpWp81zThmp3sv5ze8+TLbRiR4/RRrA62S EtspV9U503vlXq0++XRnSWDpqUu7rTRviwtmsU6YYd1kYHF8keqUKiWW4oxEQy3mouJEAHD+ J9RcAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL 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, 29 Apr 2013 14:44:21 -0000 Hi, I need to correct 1). The IP header Protocol value will of course only indicate UDP, NOT what is = on top of that (RTP, SCTP, or something else...). Regards, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Monday, 29 April 2013 4:06 PM To: 'Paul Kyzivat' Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL Hi, I think we can separate this into 3 questions: 1) How is a receiver able to demux transport flows associated with differen= t "transport flow usages" (here I consider RTP one usage, the data channel = another, etc). Now, the general first step is of course to separate based on the IP header= Protocol value. But, of course, if you have multiple flows with the same usage (e.g. multip= le RTP flows), that it is not enough. Also, if you have SCTP on top of UDP (as in our case for the data channel),= you need to go up on the SCTP level in order to figure out what it is used= for. 2) How is a receiver able to associated a transport flow with its associate= d SDP m- line. This becomes an issue when multiple m- lines are associated with the same t= ransport flow usage, e.g. when you have multiple m- lines for RTP. 3) How is a receiver able to, within an m- line, identify a media flow. This becomes an issue e.g. when multiple RTP flows are associated with a si= ngle m- line. But, as I said before, this is not a BUNDLE specific problem. Regarding 2) and 3), the most common solutions that have been discussed are= usage of PAYLOAD and/or SSRC. As we know, people have expressed concern ab= out using PAYLOAD, due to the limited number of PT values available. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Friday, April 26, 2013 10:28 PM To: Christer Holmberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL On 4/26/13 1:33 PM, Christer Holmberg wrote: > > Hi, > >>>>> Yes - we need a way to signal the demux mechanism to be used. >>>>> (Unless there is only one possibility. And we have already >>>>> disproved >>>>> that.) >>>> >>>> We could use different group "semantics" values to indicate the >>>> multiplexing mechanism. One endpoint could probe the other to >>>> discover which mechanisms it supplies by offering a collection of bund= les containing no constituents, one for each mechanism. The answer will sh= ow which mechanisms the answerer supports. >>> >>> My idea was the endpoint simply lists the media description proto value= s that it is capable of multiplexing for a given 5-tuple: >>> >>> Example: a=3Dmuxcap: RTP/AVP, SCTP/DTLS >>> >>> ...or something like that. >> >> That is sufficient *if* there is a single mux/demux algorithm per proto. >> >> But I don't think that is true. I think we will need to signal this >> per-m-line, and specify the demux algorithm(s) for streams that bind >> to that m-line. > > I don't it matters if there are multiple algorithms - the important thing= is that the endpoint is able to mux/demux the specific proto using A algor= ithm. > > Otherwise, we can have different values, one for each algorithm. Note tha= t in my example I used to SDP proto values, but we could use whatever. My point is that both sides need to *agree* on what mechanism is used to mu= x/demux the streams - in order to associate each received packet with the c= orrect m-line. So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is not sufficient wi= thout saying *how* it will be done. (Except in cases where there is a mutua= l understanding that there is only one way, or a default way.) > HOWEVER, before we go into the details, I would like to know whether peop= le generally think we need a mechanism which allows to list the protos an e= ndpoint is able to mux/demux. > >>> Of course, an endpoint needs to be able to multiplex all media that it = inserts in a bundle group. But, it may not always insert m- lines for every= thing it is able to multiplex, so I think an explicit indication would be g= ood. >> >> There may be more than one stream per m-line, but I think we can assume = that every stream binds to one m-line. > > I am not sure I understand what you mean by "binds to one m-line". > > However, keep in mind there can be multiple streams per m- line > already today (at least for RTP), so it's not something BUNDLE > specific :) My point is that the *goal* of this exercise is to be able to associate eac= h incoming packet with exactly one of the bundled m-lines. So there must be an unambiguous mapping that does that - "binds" each packe= t to the m-line it belongs with. >>> It is important to remember that, whatever you multiplex, all media hav= e to use the same IP transport (e.g. UDP). >> >> Unfortunately SDP has a pretty confusing idea of "transport". >> The proto field identifies a whole stack of protocol layers. > > Yes, and therefor, when we say "must use the same protocol", we need > to make it clear that we refer to the Protocol value in the IP header > - not the proto value in the SDP media description :) > > I will reply to the rest of your e-mail later, because I need a little > more time to read it :) OK. Thanks, Paul From huitema@microsoft.com Sat Apr 27 23:22: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 C2D2821F980B for ; Sat, 27 Apr 2013 23:22:36 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WE6CZ5xR-l1m for ; Sat, 27 Apr 2013 23:22:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90A21F97D4 for ; Sat, 27 Apr 2013 23:22:35 -0700 (PDT) Received: from BN1BFFO11FD022.protection.gbl (10.58.52.203) by BN1BFFO11HUB007.protection.gbl (10.58.53.117) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sun, 28 Apr 2013 06:22:33 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.53.82) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sun, 28 Apr 2013 06:22:33 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.184]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sun, 28 Apr 2013 06:22:16 +0000 From: Christian Huitema To: Suhas Nandakumar , "jonathan@vidyo.com" Thread-Topic: Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3605 Related) Thread-Index: AQHOQsQehmCfhkktCUSo1ZTkvxF5GJjrK6nQ Date: Sun, 28 Apr 2013 06:22:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0C0658EBtk5ex14mbxc272r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(51874002)(199002)(76482001)(564824004)(33656001)(66066001)(54356001)(53806001)(79102001)(20776003)(512954001)(63696002)(4396001)(51856001)(6806003)(49866001)(55846006)(71186001)(31966008)(16236675002)(46102001)(15202345002)(81342001)(81542001)(47736001)(47976001)(50986001)(80022001)(74366001)(65816001)(16406001)(56776001)(54316002)(77982001)(69226001)(59766001)(56816002)(74662001)(47446002)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB007; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0830866D19 X-Mailman-Approved-At: Mon, 29 Apr 2013 09:00:07 -0700 Cc: mmusic WG Subject: Re: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3605 Related) 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, 28 Apr 2013 06:22:36 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0C0658EBtk5ex14mbxc272r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your analysis of RFC3605 appears correct. -- Christian Huitema From: Suhas Nandakumar [mailto:suhasietf@gmail.com] Sent: Friday, April 26, 2013 2:22 PM To: jonathan@vidyo.com; Christian Huitema Cc: mmusic WG Subject: Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (= RFC3605 Related) Hello Christian , Jonathan This is a request for reviewing the following sections 5.13 of the draft draft-nandakumar-mmusic-sdp-mux-attributes-02 It will be greatly appreciated if you could inform on your willingness for = reviewing the aforementioned sessions. It would be great to have your review feedback/comments/inputs before June = 9th 2013. The document is available here: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 Thanks in Advance Regards Suhas Nandakumar --_000_C91E67751B1EFF41B857DE2FE1F68ABA0C0658EBtk5ex14mbxc272r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your analysis of RFC3605 = appears correct.

 <= /p>

--= Christian Huitema

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Suhas = Nandakumar [mailto:suhasietf@gmail.com]
Sent: Friday, April 26, 2013 2:22 PM
To: jonathan@vidyo.com; Christian Huitema
Cc: mmusic WG
Subject: Review Request - draft-nandakumar-mmusic-sdp-mux-attributes= -02 - (RFC3605 Related)

 

Hello  Christian , Jonathan

  

This is a request for reviewing the following sectio= ns

 

5.13 

 

of the draft

   

draft-nandakumar-mmusic-sdp-mux-attributes-02

   

It will be greatly appreciated if you could inform o= n your willingness for reviewing the aforementioned sessions.

 

It would be great to have your review feedback/comme= nts/inputs before June 9th 2013.

 

The document is available here:

 

 

Thanks in Advance

 

Regards

Suhas Nandakumar

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0C0658EBtk5ex14mbxc272r_-- From eburger@standardstrack.com Sun Apr 28 06:09: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 D242921F8F1E for ; Sun, 28 Apr 2013 06:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 E9g7Xq54JXOw for ; Sun, 28 Apr 2013 06:09:03 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6221F86EB for ; Sun, 28 Apr 2013 06:09:03 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:52851 helo=[192.168.15.163]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UWRLd-0003cz-6i; Sun, 28 Apr 2013 06:09:01 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E1747FD5-F3FE-4274-A9F5-EE8630DEAF95" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Eric Burger In-Reply-To: Date: Sun, 28 Apr 2013 09:08:56 -0400 Message-Id: References: To: Suhas Nandakumar X-Mailer: Apple Mail (2.1503) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Mon, 29 Apr 2013 09:00:08 -0700 Cc: staffan.blau@ericsson.com, mmusic WG , christer.holmberg@ericsson.com Subject: Re: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC6714 Related) 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, 28 Apr 2013 13:09:07 -0000 --Apple-Mail=_E1747FD5-F3FE-4274-A9F5-EE8630DEAF95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I only looked at 5.22. It looks accurate. On Apr 26, 2013, at 5:31 PM, Suhas Nandakumar = wrote: > Hello Christer, Steffan, Eric > =20 > This is a request for reviewing the following sections > =20 > 5.22 >=20 > of the draft > =20 > draft-nandakumar-mmusic-sdp-mux-attributes-02 > =20 > It will be greatly appreciated if you could inform on your willingness = for reviewing the aforementioned sessions. >=20 > It would be great to have your review feedback/comments/inputs before = June 9th 2013. >=20 > The document is available here: > = http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 >=20 >=20 > Thanks in Advance >=20 > Regards > Suhas Nandakumar --Apple-Mail=_E1747FD5-F3FE-4274-A9F5-EE8630DEAF95 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I only looked at 5.22. It looks accurate.

On Apr 26, 2013, at 5:31 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello Christer, Steffan, Eric
  
This is a request for reviewing the following sections
 
5.22

of the draft
   
draft-nandakumar-mmusic-sdp-mux-attributes-02
   
It will be greatly appreciated if you could inform on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/inputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
Suhas Nandakumar

--Apple-Mail=_E1747FD5-F3FE-4274-A9F5-EE8630DEAF95-- From rohan.mahy@gmail.com Sun Apr 28 11:07: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 CC88721F9CFC for ; Sun, 28 Apr 2013 11:07:37 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 ihgJ3UYJKlMe for ; Sun, 28 Apr 2013 11:07:37 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C321F9CFD for ; Sun, 28 Apr 2013 11:07:31 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z16so685241ead.17 for ; Sun, 28 Apr 2013 11:07:30 -0700 (PDT) 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=5+ZTi7yovaO1K1AYrNMmyQ/bmwc2XXkBcLkUrJI2QaA=; b=ecCL56P6U5mXBoKMNL+NczOHLceHF8eg+bHKX4Hhc4FoHJz/sC5A8yHE0Lz/CnnN4R LLCCtnImRVhVJWBSHYe0e++ej/p9EYIILrk3zXrDg+7TpQl8bF3nazk95lkL2cobh+/F d2p+el05RkOvuqCyyHgQQLlqhzUKmVgmFOMUw37sgHtuYVcu52fOZa9szxUFcK5Za/9/ qiFfVJe7zmwtqvMafVgDNRKNaeK2T3vgx8Lr8u++wuXxNHLiy1emfb6gaquXhCDBA6rS ox+mdLCn6QxASWIHo79pK2Lpmqtc+A2L8TG3IrDNTJ3L3kHNPyZKi5cPl3yyDf0Wk3V9 sLXg== MIME-Version: 1.0 X-Received: by 10.14.149.141 with SMTP id x13mr114487422eej.31.1367172450798; Sun, 28 Apr 2013 11:07:30 -0700 (PDT) Received: by 10.15.25.8 with HTTP; Sun, 28 Apr 2013 11:07:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Apr 2013 19:07:30 +0100 Message-ID: From: Rohan Mahy To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=089e0163449846f9f604db6fa4d3 X-Mailman-Approved-At: Mon, 29 Apr 2013 09:00:07 -0700 Cc: ben@estacado.net, Cullen Jennings , mmusic WG , Rohan Mahy Subject: Re: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC4975 Related) 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, 28 Apr 2013 18:07:37 -0000 --089e0163449846f9f604db6fa4d3 Content-Type: text/plain; charset=ISO-8859-1 Hi Suhas, I read the section of your draft. As you stated, the SDP attributes used for MSRP are not relevant to RTP or any future or current RTP muxing attributes. Regards, -rohan On Fri, Apr 26, 2013 at 10:27 PM, Suhas Nandakumar wrote: > Hello Ben, Rohan, Cullen > > This is a request for reviewing the following section > > 5.45 > > of the draft > > draft-nandakumar-mmusic-sdp-mux-attributes-02 > > It will be greatly appreciated if you could inform on your willingness for > reviewing the aforementioned sessions. > > It would be great to have your review feedback/comments/inputs before June > 9th 2013. > > The document is available here: > http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02 > > > Thanks in Advance > > Regards > Suhas Nandakumar > --089e0163449846f9f604db6fa4d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Suhas,
I read the section of your dr= aft. As you stated, the SDP attributes used for MSRP are not relevant to RT= P or any future or current RTP muxing attributes.
Regards,
-roh= an


On Fri,= Apr 26, 2013 at 10:27 PM, Suhas Nandakumar <suhasietf@gmail.com&g= t; wrote:
Hello Ben, Rohan, Cullen=A0=A0
This is a request for reviewing the following section
=A0
5.45

of the draft
=A0 = =A0
draft-nandakumar-mmusic-sdp-mux-attributes-02
=A0=A0=A0
It will be greatly appreciated if you could in= form on your willingness for reviewing the aforementioned sessions.

It would be great to have your review feedback/comments/i= nputs before June 9th 2013.

The document is available here:


Thanks in Advance

Regards
S= uhas Nandakumar

--089e0163449846f9f604db6fa4d3-- From pkyzivat@alum.mit.edu Mon Apr 29 10: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 48C4121F9E43 for ; Mon, 29 Apr 2013 10:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.763 X-Spam-Level: X-Spam-Status: No, score=0.763 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.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 D8FYrHzL1oBc for ; Mon, 29 Apr 2013 10:05:59 -0700 (PDT) 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 EC4F821F9E47 for ; Mon, 29 Apr 2013 10:05:58 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id Vt3P1l0060EZKEL51t5yBS; Mon, 29 Apr 2013 17:05:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id Vt5y1l0053ZTu2S3Mt5yvf; Mon, 29 Apr 2013 17:05:58 +0000 Message-ID: <517EA875.1020002@alum.mit.edu> Date: Mon, 29 Apr 2013 13:05:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3682C9@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=1367255158; bh=8JUmJIggvGYMtuJm4Q6mSlBFgChTsGVR9B4gSQCFmXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eRYCY/eD+LGIXxrX2/5QM+v0lLShVHaYuSkpKaqq/Ire54ZVKiMwQ19k8qZiN8q7q XOoNh8hqPKEYaXYuWQSzwEuu/jG87NnxoFl2/B8wu4jLnJKU0/8b6/G7Xb7kmpBG6/ 9kAUKs38GShWZ6KnfSKtDlJpg0pZyVXrY8RD/5c4nD1/JEs9/XY/ADvVW6dTA35Jkq ipwJ4P6WL1DMwKM8smZSW081ltwTHUJyRVuK/AfcVgT7BLZ06Cmx7nl31MQjHPz6q7 AWqKKAEqVf4m1rKJkRx34AysFTDyw2cUhnEWNcbJ92K++KLc3kIEWGR3ZkVkmMiyIx pV6wWWihXNxTA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example 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, 29 Apr 2013 17:06:04 -0000 On 4/29/13 10:41 AM, Christer Holmberg wrote: > > Hi, > >> For instance, consider the following: >> >> ... >> c=IN IP4 host.biloxi.com >> a=group:BUNDLE m1 m2 m3 m4 >> m=audio 20000 RTP/SAVPF 0 >> a=mid:m1 >> a=ssrc:12345 cname:user@example.com >> a=max-send-ssrc:{*:1} >> a=max-recv-ssrc:{*:1} >> ... >> m=video 20000 RTP/SAVPF 96 98 >> a=mid:m2 >> a=ssrc:5678 cname:user@example.com >> a=max-send-ssrc:{*:1} >> a=max-recv-ssrc:{*:1} >> ... >> m=video 20000 RTP/SAVPF 96 98 >> a=mid:m3 >> a=max-send-ssrc:{*:4} >> a=max-recv-ssrc:{*:4} >> ... >> m=application 20000 DTLS/SCTP ... >> a=mid:m4 >> ... >> >> We have four bundled m-lines. We have one proto (RTP/SAVPF) in three >> m-lines, and another (DTLS/SCTP) in the other m-line. From a protocol >> layering perspective we have: >> >> m1 m2 m3 m4 >> ===== ===== ===== ==== >> SAVPF SAVPF SAVPF SCTP >> RTP RTP RTP DTLS >> UDP UDP UDP UDP >> IP IP IP IP >> >> So, the first demux that must be done is to distinguish RTP from DTLS. >> DTLS has been designed to have a field that distinguishes it from >> RTP/RTCP/ICE, so that can perhaps be considered a default demux >> algorithm for that. > > Correct. > >> Because there is only one SCTP m-line, that is enough to identify those >> packets that should be bound to m4. > > In your example there is only one SCTP m- line, and in WebRTC I guess it will also be the case, but SDP doesn't prevent you from using multiple SCTP m- lines - unless BUNDLE explicitly forbids it, that is. I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is via SCTP port. That depends on there being a way to specify the SCTP with DTLS/SCTP. That has come and gone from the SDP proposal for SCTP. If we were talking about just plain SCTP then I don't think bundling makes any sense. And for SCTP/DTLS I suppose it might be possible to bundle with some other things running over DTLS. I'm not sure if we want to think about that now. >> But we need to use something else to sort out the RTP. >> >> In this example, payload type can be used to distinguish audio from >> video. But there may be cases where that isn't possible. If we want to >> allow this mechanism, then perhaps we need some way to signal that it >> should be used. Or *maybe* we could count on it being inferred. Assuming >> that is used, then it is sufficient to identify those packets that >> belong to m1. >> >> Or, because m1 is marked as having at most one ssrc, and the ssrc value >> (1234) is specified, that could be used to bind packets to m1. >> >> Similarly, RTP packets having ssrc=5678 can be bound to m2. >> >> m3 supports multiple unspecified SSRCs. Since there is only one m-line >> that does, all the packets with pt 96 or 98 and with an ssrc other than >> 1234 or 5678 can be bound to m3. >> >> I'm undecided if we can count on inferring this decision logic from >> existing signaling options, or if we ought to signal the choices more >> explicitly. > > At least I think that, based on e-mail discussions, we most likely cannot rely on unique payload type values for each RTP flow. What I saw from the discussions was the possibility of bundling *one* audio m-line and *one* video m-line, and potentially running multiple flows within each of those. In that usage, using PT for demux is feasible. > (Nothing of course forbids users from using unique payload type values.) Its unclear to me how the usage of bundlling is going to evolve. So I don't have a clear idea how much flexibility we need to allow for a multitude of different demux strategies. BTW, another demux strategy appears if you use bundling with the shim proposal. To me the key is to provide a framework for signalling the mux/demux strategy in SDP. And part of that is deciding whether the strategy is declarative or negotiated in O/A. (It is hard for me to see how it could be *negotiated* in one O/A cycle. So I'm imagining that the offer makes a proposal and it succeeds or fails - with failure meaning no bundling.) Thanks, Paul From martin.thomson@gmail.com Mon Apr 29 11:13: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 45ADB21F9A5D for ; Mon, 29 Apr 2013 11:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 IgDpVHJ5WeW7 for ; Mon, 29 Apr 2013 11:13:19 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7C28521F9A48 for ; Mon, 29 Apr 2013 11:13:19 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id m6so3082021wiv.7 for ; Mon, 29 Apr 2013 11:13:18 -0700 (PDT) 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=dsgc1wHvi6UV5itEkPB12okXQPpmFiKczGFKTU/7OAw=; b=F4ig+09V1TajWHezCtovuOg/WeWJquoXOX/bm9Nd1vv+NvvNRTRhBzbRVRBgSLjkln e3nfTg+OgSZhorg4Rd65a0XVp82/6bEokAVVS9fgdZQ+Ct/nCRcASyOg5xq8djZheaTx tVxyrVZhIOkqZJx/ofZATv5IjXtNAHJ3H/t/fwdwkSBCdyHe//mzV0yQ8TNhHFZJzPbh ewiKhb3fBkKpZuXHGPN9w7PPGNJAc1I2VJbnPS8XYwnrEUT7vm99fYH4L6Ej8x/UlNG0 ggAE2ht4Q6BH0prx7aSP+b9Gd1J8IoD197V7hB9CPtC4UGg2c13KbHhpXKR1qhZmrm3F Xr/w== MIME-Version: 1.0 X-Received: by 10.180.198.49 with SMTP id iz17mr19653488wic.19.1367259198722; Mon, 29 Apr 2013 11:13:18 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 29 Apr 2013 11:13:18 -0700 (PDT) In-Reply-To: <517EA875.1020002@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> Date: Mon, 29 Apr 2013 11:13:18 -0700 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 and DATA CHANNEL - Paul's example 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, 29 Apr 2013 18:13:20 -0000 On 29 April 2013 10:05, Paul Kyzivat wrote: > On 4/29/13 10:41 AM, Christer Holmberg wrote: >> In your example there is only one SCTP m- line, and in WebRTC I guess it >> will also be the case, but SDP doesn't prevent you from using multiple SCTP >> m- lines - unless BUNDLE explicitly forbids it, that is. > > I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is > via SCTP port. That depends on there being a way to specify the SCTP with > DTLS/SCTP. That has come and gone from the SDP proposal for SCTP. I don't care whether SDP supports it or not, I care whether it makes sense to do it at all. There's a reason why you might not want to mux SCTP - it's a protocol with multiplexing support. Multiplexing outside of it is at best a crude thing to do and at worst a way to dilute congestion signals. I can understand how you can conceive of scenarios where different application layer protocols don't play well together enough that you want more aggressive separation. I don't see significant value in supporting those scenarios. That doesn't completely preclude the future use of SCTP port for demux, but it does constrain complexity. From pkyzivat@alum.mit.edu Mon Apr 29 12:32: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 AB07121F9BB4 for ; Mon, 29 Apr 2013 12:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 DFQxZaYIAVRY for ; Mon, 29 Apr 2013 12:32:35 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id BD06321F9BB2 for ; Mon, 29 Apr 2013 12:32:33 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id VrUZ1l00A0EZKEL5DvYZqB; Mon, 29 Apr 2013 19:32:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id VvYZ1l00A3ZTu2S3MvYZNb; Mon, 29 Apr 2013 19:32:33 +0000 Message-ID: <517ECAD0.90803@alum.mit.edu> Date: Mon, 29 Apr 2013 15:32:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@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=1367263953; bh=cyBii9/S1jkIXGzsQNk9uQAKLmV5r/L1yuJZjFfk1TE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kjnke/IMdvnd1ukRWl4ZrvgGIfAmk8WpSowcVwZkyAucOYa3Z1qMuWNegsSbhlFEZ ZX6I7w8krD9c2Q1IY7Z53ua41iUDsaxOosYPPWhDltKXtpSgpJ2SF3oz3HKOGOYNQG 9VxlK1hFhy5S/fXe0zgj0Ro9zMiQYVR7y6dRrNu8+zhGqwlBu4ah7x62ec71LwW4R3 DJ1V+dYaKD+blwmJXcL1qrf3FHQZvkFrnyuld5NkVT7E5/Qed5YQfQvzqjZbSidiUE vJ7BPJZPgNZOA4hgZ5E70gUCgsB/6KYmuPBbYDJflfikOJTO5no77UHh57ldrsAyNZ YOTwtzzrmI7hQ== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example 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, 29 Apr 2013 19:32:40 -0000 On 4/29/13 2:13 PM, Martin Thomson wrote: > On 29 April 2013 10:05, Paul Kyzivat wrote: >> On 4/29/13 10:41 AM, Christer Holmberg wrote: >>> In your example there is only one SCTP m- line, and in WebRTC I guess it >>> will also be the case, but SDP doesn't prevent you from using multiple SCTP >>> m- lines - unless BUNDLE explicitly forbids it, that is. >> >> I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is >> via SCTP port. That depends on there being a way to specify the SCTP with >> DTLS/SCTP. That has come and gone from the SDP proposal for SCTP. > > I don't care whether SDP supports it or not, I care whether it makes > sense to do it at all. > > There's a reason why you might not want to mux SCTP - it's a protocol > with multiplexing support. Multiplexing outside of it is at best a > crude thing to do and at worst a way to dilute congestion signals. > > I can understand how you can conceive of scenarios where different > application layer protocols don't play well together enough that you > want more aggressive separation. I don't see significant value in > supporting those scenarios. > > That doesn't completely preclude the future use of SCTP port for > demux, but it does constrain complexity. I agree with you that there doesn't seem to be any obvious need for this, at least not now. I don't think we need to expend effort specifying how to do this sort of multiplexing now. For example, it may be sufficient to register a default sctp port for data channel over sctp, and assume that any other uses of DTLS/SCTP will either have to register their own default port or else specify a way of explicitly signaling the port. My point was only to indicate another reason to design in a flexible mechanism for signaling the multiplexing mechanism(s). Thanks, Paul From pkyzivat@alum.mit.edu Mon Apr 29 12:41: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 3DF1B21F9A99 for ; Mon, 29 Apr 2013 12:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 43ZgZWbbbBhz for ; Mon, 29 Apr 2013 12:41:53 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 1AADF21F9AEA for ; Mon, 29 Apr 2013 12:41:52 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id VnNn1l0050mv7h059vhrmR; Mon, 29 Apr 2013 19:41:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Vvhr1l00y3ZTu2S3Xvhrbs; Mon, 29 Apr 2013 19:41:51 +0000 Message-ID: <517ECCFF.6040706@alum.mit.edu> Date: Mon, 29 Apr 2013 15:41:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@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=1367264511; bh=JqNpT7/rdzc5BBxBzArrm7ZXGWGsAzUpFmAI5M9B+ZU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g41mReo8CwMHtts/6A8qgxpndvXv9fJdEXXRGGHXbIIxC7oZOnZcC1IC+xeM/ZNVf t/7IAqS0A1xBroBxZ0ovpFmo8t52KqTM9GCze3HtXGjJ+lBZyVv4CUPc2XdP1c5CS5 tr3q/HX6pCS7FPWl6DTWQwRtyhkogNT2pBLLPFbx5lR+pS9oMbuHvSdBkoVUQKSr4n oBegUnCh2e0teh3zbcXFdH4Xb58RZzwQ0l9vVv91RPaB9l7z2XsxENsg3qy85DuWP4 iOeaRjqWDDJcRZdtvxaAdA8THA5K8a7ymd5z/0mW6ep4Y20ZZsI6uv0pUDvzvTAkfA JwSTn/3j2XONg== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example 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, 29 Apr 2013 19:41:59 -0000 One more thing - a question for all: Do you agree that there is a need to support more than one way to demux RTP, and hence a need to signal what way is to be used? Or do you think we will be able to reach agreement on a single algorithm, so that signaling of the algorithm isn't required? Thanks, Paul On 4/29/13 2:13 PM, Martin Thomson wrote: > On 29 April 2013 10:05, Paul Kyzivat wrote: >> On 4/29/13 10:41 AM, Christer Holmberg wrote: >>> In your example there is only one SCTP m- line, and in WebRTC I guess it >>> will also be the case, but SDP doesn't prevent you from using multiple SCTP >>> m- lines - unless BUNDLE explicitly forbids it, that is. >> >> I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is >> via SCTP port. That depends on there being a way to specify the SCTP with >> DTLS/SCTP. That has come and gone from the SDP proposal for SCTP. > > I don't care whether SDP supports it or not, I care whether it makes > sense to do it at all. > > There's a reason why you might not want to mux SCTP - it's a protocol > with multiplexing support. Multiplexing outside of it is at best a > crude thing to do and at worst a way to dilute congestion signals. > > I can understand how you can conceive of scenarios where different > application layer protocols don't play well together enough that you > want more aggressive separation. I don't see significant value in > supporting those scenarios. > > That doesn't completely preclude the future use of SCTP port for > demux, but it does constrain complexity. > From worley@shell01.TheWorld.com Mon Apr 29 14: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 49FF921F9C23 for ; Mon, 29 Apr 2013 14:59:58 -0700 (PDT) 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.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 nZ2vFslLmiOf for ; Mon, 29 Apr 2013 14:59:52 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E421F9C25 for ; Mon, 29 Apr 2013 14:59:48 -0700 (PDT) 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 r3TLxFWc005032; Mon, 29 Apr 2013 17:59:17 -0400 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 r3TLxFnt3751968; Mon, 29 Apr 2013 17:59:15 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3TLxCQT3757057; Mon, 29 Apr 2013 17:59:12 -0400 (EDT) Date: Mon, 29 Apr 2013 17:59:12 -0400 (EDT) Message-Id: <201304292159.r3TLxCQT3757057@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <517A9991.3060901@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> <201304251934.r3PJYupZ3410480@shell01.TheWorld.com> <517A9991.3060901@alum.mit.edu> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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, 29 Apr 2013 21:59:58 -0000 > From: Paul Kyzivat > > I only bring it up because past experience > with O/A has shown that it is generally better for an offerer to say > what they want without making value judgements about the other party. It > becomes especially important if it turns out that the party you are > sending the offer to turns out to be different from the one you talked > to last. (That probably is nonsense here if these O/A cycles are > back-to-back.) The difficulty in this case with always offering everything you want is that the process never ends: Each endpoint *wants* to bundle m= lines that the other endpoint can't accept. OTOH, you have to worry about the possiblity that at this moment, the other endpoint is not the endpoint you negotiated with previously. A solution is that if the endpoint is sending an offer to effect bundling between m= lines that it disconnected from an *immediately* preceding offer, the endpoint should offer no bundling that was not proposed in the preceding offer. New offers generated for other reasons would offer all the bundling the endpoint is willing to support. > In all of the above, the behavior of B only makes sense if B feels it > *needs* all of these streams. Another possibility is that B simply > rejects the streams it can't accept when bundled as proposed, but > doesn't initiate another O/A cycle. Then if A feels those are important, > *it* can send another offer with them separately bundled. The difficulty with that is that A doesn't know whether B rejected them because it couldn't deal with the bundling or because B was unable to utlize the m= line for some other reason. A would have to send a number of probes to determine the answer. > But having B make the second > offer means it may need to take on faith "I don't know if these streams > are important, but my peer wanted them so I'll try to establish them." B would only include the stream in a second offer if B would have accepted the stream un-bundled, which means that B knows that A wants the stream (whether or not A considers it "important") and that B can support it, in which case we assume that the penalty for supporting the stream without bundling is lower than the penalty for not supporting the stream at all. > These cases requiring multiple O/A cycles to get things arranged as > desired are starting to smell to me like the kinds of situations that > preconditions were designed for. Perhaps a new "bundle" precondition > would provide a way to sort out responsibilities and realize when to > keep trying and when to give up. But many consider preconditions too > heavy weight to use in practice. And they could prove difficult in JSEP. It does resemble precondition situations. But we can arrange for exactly two O/A cycles to determine the maximal bundling that both endpoints can support. > > But if either side initiates a re-offer for some other reason, the new > > offer should be the biggest bundling the offerer is willing to > > support. > > You mean, in the above case, after having agreed on bundles 1,2 ; 3/4 ; > 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer > 1,2,5,6 ; 3,4,7,8,9 ??? > > I *think* the new offer should include the new bundles in their current > operational form, with only one address/port per bundle. Doing otherwise > would disrupt the functioning of the current streams. Stream 9 could be > added to one of the existing bundles in the offer, but should have a > separate address/port. > > That will probably break a scenario that is trying to do a 3pcc > transfer. I suspect that doing such a thing with bundled streams is > going to be *hard*, and will need to be considered separately. The question is whether B thinks A might have been replaced by A'. Now that you mention it, if B adds stream 9 (generating a new offer for internal reasons), then it is very unlikely that A has been replaced. But if B receives an offerless INVITE (demanding that B produce an offer), then A might well have been replaced. If B receives an offer, there are three cases: The offer may be from an A', in which case it's OK if B gives the best response it can (according to the previous plan), and does a re-offer if it needs to create new bundles to split an offered bundle. The offer may be from A, generated for internal reasons, in which case it looks very much like the previous SDP. But, e.g., added m= lines may be bundled in a way that B can't accept and may require B to produce a second offer. The offer may be from A, generated due to receiving an offerless INVITE from an intermediate 3PCC controller, in which case (we assume) it specifies the maximal bundling that A can support. That may require B to produce a second offer. So it looks like we can soften the rules to: If an endpoint makes an offer for what it sees as a new dialog, or due to receiving an offerless INVITE, it must offer the maximal bundling it supports. If an endpoint receives an offer, it answers with the maximal bundling that it supports that is a subset of the offered bundling. (I say "subset", as the answer necessarily has no more bundles than the offer.) The endpoing may then make a second offer that offers the maximal bundling that it supports that is compatible with the received offer. ("Compatible" in the sense of bundling no two m= lines that were not bundled in the offer.) Dale From worley@shell01.TheWorld.com Mon Apr 29 15:00: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 3E04F21F9C37 for ; Mon, 29 Apr 2013 15:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 zpbweoGZHGN2 for ; Mon, 29 Apr 2013 15:00:06 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5081221F9C26 for ; Mon, 29 Apr 2013 15:00:06 -0700 (PDT) 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 r3TLxxvs008240 for ; Mon, 29 Apr 2013 18:00:01 -0400 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 r3TLxwLV3759373 for ; Mon, 29 Apr 2013 17:59:58 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3TLxwMs3753609; Mon, 29 Apr 2013 17:59:58 -0400 (EDT) Date: Mon, 29 Apr 2013 17:59:58 -0400 (EDT) Message-Id: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org Subject: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets 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, 29 Apr 2013 22:00:12 -0000 Moving this proposal over from the RTCWEB mailing list, updating and correcting it: I was working on an essay based on the assumption that a single video capture is carried over a single m= line (with the various component streams (simulcast, FEC, layered encoding, etc.) sent using different SSRCs)... But many existing systems don't work that way. It would be nice to correct that, but basing our solution on that assumption isn't the quick way to get products to market. ;-) So we can't assume a small number of m= lines, which implies that we can't safely require that each m= line has a disjoint set of payload types, which implies that we can't demultiplex based on PT. If multiplexing based on payload type is unworkable, how about the following technique. (Forgive me if someone else has already proposed it.) Each SSRC is demultiplexed based on an RTCP SDES item that specifies the mapping between the SSRC and the m= line via which it is presented to the application layer. When a media stream with new SSRC is sent, the sender inserts an RTCP SDES item with a special multiplexing "item type". The SDES item contains the SSRC value and the identifier of the m= line via which that SSRC is obtained from the application layer. For reliability, the sender resends this SDES item occasionally. The receiver keeps a table which maps the SSRCs to the m= lines via which each SSRC is to be presented to the application. Entries in the table are added/updated when the multiplexing SDES items are received. Since SDES items are meant to describe the "source" of the media stream, using an SDES item to identify how the media is supplied by the application is probably within the semantic definition of SDES. (If people don't like that, we could define another RTCP packet type.) For each stream, this mechanism only adds one 8 byte SDES item periodically in the RTCP (given that RTCP packets often contain SDES packets, so the SDES packet header isn't charged to carrying this item). The overhead is reduced to 4 bytes if the RTCP periodically contains SDES items for that SSRC anyway, and we don't have to charge the 4 bytes carryig the SSRC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUX=11 | length=1 |0|m= line seq. | NULL=0 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | ... | 2 With dexterous use of pseudo-UTF-8 encoding to encode sequence numbers, an 8 byte item suffices for the typical case, but we still support multiplexing an unlimited number of m= lines. m= line identifiers from 1 to 127 are represented +-+-+-+-+-+-+-+-+ |0 s s s s s s s| +-+-+-+-+-+-+-+-+ while identifiers from 128 to 2047 are represented +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 s s s s s|1 0 s s s s s s| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and larger identifiers can be encoded if necessary. These look like UTF-8 encodings of characters, so they shouldn't choke code that interprets SDES items (the data values in SDES items are UTF-8-encoded strings). We could even support multiplexing m= lines that specify multiple addresses or ports by encoding a second identifier, which counts the address or port in the group (starting at 1). This method allows multiplexing to support whatever use of m= lines the overlying application supports/requires, since it places no restrictions on the SDP or RTP usage. One interesting observation is that in order to make this work in 3PCC situations, the m= line identifiers can't be the sequence number of the m= line in the SDP in the offer/answer exchange, because the sender of RTCP may be different than the endpoint sending the offer/answer, and may see different SDP. So we need the m= line identifier to be invariant when a 3PCC assembles/disassembles aggregated SDP. One choice for that is to make the m= line index be the sequence number of the m= line *within the m= lines in the bundle*, since all of the m= lines in a bundle are routed to the same media-generating endpoint. (This problem afflicts all methods that specify a demultiplexing index, including SHIM (draft-westerlund-avtcore-transport-multiplexing-05), KUMQUAT (draft-worley-sdp-bundle-05), and even draft-rosenberg-rtcweb-rtpmux-00.) Unfortunately, using m= line position within the bundle as the m= line index, rather than using m= line position within the overall SDP, makes demultiplexing unstable while bundling is changing due to a new offer/answer exchange, because the demultiplexing index for an SSRC will change. However, only m= lines whose transport is changing will be affected by this instability. Dale From worley@shell01.TheWorld.com Mon Apr 29 15:00: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 98A5021F9C3F for ; Mon, 29 Apr 2013 15:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 gHq0Ta5TaKPC for ; Mon, 29 Apr 2013 15:00:20 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAB721F9C3B for ; Mon, 29 Apr 2013 15:00:20 -0700 (PDT) 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 r3TM0HEd008771; Mon, 29 Apr 2013 18:00:19 -0400 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 r3TM0HUd3752976; Mon, 29 Apr 2013 18:00:17 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3TM0GmX3712511; Mon, 29 Apr 2013 18:00:16 -0400 (EDT) Date: Mon, 29 Apr 2013 18:00:16 -0400 (EDT) Message-Id: <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Feedback requested on requirements 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, 29 Apr 2013 22:00:30 -0000 > From: Christer Holmberg > > I'm a little lost. Why do we, in the bundle context, need to talk > about which codecs SGCs understand? If the SGCs will process media > on a codec level it will indicate in SDP which codecs it support. If an SBC reprocesses media, then a bundled session can be initiated through it only if the SBC explicitly supports bundle. But if the SBC does not reprocess media, but only *edits* what media descriptions it permits in the SDP that it passes through, then bundling can succeed as long as the bundling specification does not require any element that the SBC removes. Dale From martin.thomson@gmail.com Mon Apr 29 16:03: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 CBAA321F9B5E for ; Mon, 29 Apr 2013 16:03:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tiGRQZHgL3W for ; Mon, 29 Apr 2013 16:03:13 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9655821F9B79 for ; Mon, 29 Apr 2013 16:03:11 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t9so5356623wey.5 for ; Mon, 29 Apr 2013 16:03:00 -0700 (PDT) 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=tvThjkKgKmLPuAS08RhINs1tB0Dgj1QWGaclawbjQLY=; b=ygmd8VFnUFyd63m1jAC12YRI3PKOy+SRCVbaBSbk+/z5kTIlOZDBgsmXpd1/wxf5AR XcwLWuhptN3TS9fod4InjGb/lb6XXsd87+Iuhhf9Asoduq/+zbWKR642eCdq6RpmBMtG KSUriG16zL4qXCQPgUWpR4gTaIG449xjiD7AZJGeI93RY6pGBTpHnEo9viUXGVQ79j7x KqLQT6cp14YJtYEOvtrgIEqEBOV711b5mJakLi9Ke9acGiH55xqNG49Z9gqJmRVJsZ9X PAD6mWRbvNzu1hmDcUfiMCZeMoiHWWwmvSas9du5v/cGdmd4TY4SkTiH8MUSRqKbHmDI q8WQ== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr15691026wic.32.1367276580661; Mon, 29 Apr 2013 16:03:00 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Mon, 29 Apr 2013 16:03:00 -0700 (PDT) In-Reply-To: <517ECCFF.6040706@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> <517ECCFF.6040706@alum.mit.edu> Date: Mon, 29 Apr 2013 16:03:00 -0700 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 and DATA CHANNEL - Paul's example 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, 29 Apr 2013 23:03:14 -0000 On 29 April 2013 12:41, Paul Kyzivat wrote: > One more thing - a question for all: > > Do you agree that there is a need to support more than one way to demux RTP, > and hence a need to signal what way is to be used? > > Or do you think we will be able to reach agreement on a single algorithm, so > that signaling of the algorithm isn't required? There is agreement in avtcore to build two demux schemes. The need to signal the choice of demux scheme has already been made for us. Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh and protocol if you've got this DTLS thingy))" and then have a SHIMBUNDLE grouping. That would be actively antisocial. From christer.holmberg@ericsson.com Tue Apr 30 00: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 C839D21F972B for ; Tue, 30 Apr 2013 00:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 L2yiZzDrFIm3 for ; Tue, 30 Apr 2013 00:31:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3321F8454 for ; Tue, 30 Apr 2013 00:31:26 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-ea-517f734d2a4f Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E6.5E.03253.D437F715; Tue, 30 Apr 2013 09:31:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 09:31:25 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [MMUSIC] Feedback requested on requirements Thread-Index: AQHOQevTi+cVnxjNCEKSb6lvFRbbnJjnWrcQgAZrVnmAAJ8XsA== Date: Tue, 30 Apr 2013 07:31:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C368754@ESESSMB209.ericsson.se> References: <201304231530.r3NFU9mB3237170@shell01.TheWorld.com> <201304231858.r3NIwQYx3263944@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C35D1A5@ESESSMB209.ericsson.se> <201304251933.r3PJXuon3430760@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36098D@ESESSMB209.ericsson.se> <201304292200.r3TM0GmX3712511@shell01.TheWorld.com> In-Reply-To: <201304292200.r3TM0GmX3712511@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+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra5vcX2gQfMOU4upyx+zWLw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZczZP52tYBNbxdLbzUwNjA2sXYycHBICJhLX W6+yQ9hiEhfurWfrYuTiEBI4zCjRfe4TE4SzhFFi1ed5QB0cHGwCFhLd/7RBTBEBTYmOBTkg JrOAusTVxUEgY4SBCs63nGQGsUUELCVuLj/PAmE7STx/v5sNxGYRUJVYN+c7E4jNK+ArseRX GzvEpg3MEk/W/QC7h1PAQeJV7w+wQYxAt30/tQasgVlAXOLWk/lMEDcLSCzZc54ZwhaVePn4 H9RfihJXpy+HqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sq RvbcxMyc9HLzTYzA+Di45bfBDsZN98UOMUpzsCiJ85bk1wcKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYNzLZG7oeuz9C6X0VawL4uem3Oxb0yjJWltnOImHq5GT/e6hL3HPG498kXy+IuPd 3Lkb79qp3r/63PVa4L3LlenW0+9pfPHTbN2TM0f91ata19g9rs0LbgvWf3Qpep+yzGlRtLPz DZFZNSfPt++pdIx/8TR82t8zH0+stS8zKTyQvPnoE4awi++VWIozEg21mIuKEwGcSnQcXQIA AA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Feedback requested on requirements 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, 30 Apr 2013 07:31:33 -0000 Hi, >> I'm a little lost. Why do we, in the bundle context, need to talk=20 >> about which codecs SGCs understand? If the SGCs will process media on=20 >> a codec level it will indicate in SDP which codecs it support. > > If an SBC reprocesses media, then a bundled session can be initiated thro= ugh it only if the SBC explicitly supports bundle. > > But if the SBC does not reprocess media, but only *edits* what media desc= riptions it permits in the SDP that it passes through,=20 > then bundling can succeed as long as the bundling specification does not = require any element that the SBC removes. I still don't get it :) If an SBC needs to reprocess media, it obviously need to support the codecs= used. But, that is true no matter whether BUNDLE is used or not. Regards, Christer From magnus.westerlund@ericsson.com Tue Apr 30 00:53: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 E76DF21F9B24 for ; Tue, 30 Apr 2013 00:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, 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 JaXDw4pu7we0 for ; Tue, 30 Apr 2013 00:53:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7221F9A3E for ; Tue, 30 Apr 2013 00:53:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-47-517f785b0527 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1D.A9.10459.B587F715; Tue, 30 Apr 2013 09:52:59 +0200 (CEST) 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; Tue, 30 Apr 2013 09:52:58 +0200 Message-ID: <517F7859.4060600@ericsson.com> Date: Tue, 30 Apr 2013 09:52:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com> In-Reply-To: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vje6oj7Q4P4SUYupyx+zWLw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZUxacJWpYIZPxYrFD1gbGHdadzFyckgImEjM mrSVCcIWk7hwbz1bFyMXh5DAKUaJzTNWsEM4yxklWm51s4NU8QpoS5xvPQhmswioSrRdXw1m swlYSNz80QjUzcEhKhAssbU1BqJcUOLkzCcsIGERAU2JjgU5IGFmAWGJC+ePg+0VFnCVWNL6 BaxTSMBe4saKcJAwp4CDxL0fu6BOk5TY8qKdHaJVT2LK1RZGCFteonnrbGYQWwjosIamDtYJ jEKzkCyehaRlFpKWBYzMqxjZcxMzc9LLDTcxAoP04JbfujsYT50TOcQozcGiJM5blF8fKCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoGxgT/IQ/zJ78Ky+4fX3SotiOec1yu+eP+SZMvtzmxn We0Pn2WQtu1cw2Vu5shhEX4hJN2OP8ySN/FZ9K97zHYCGSbcKrl/fq9QOiXFHHiwZKZvyo7O o8aTsqaIFiVK715cyNImNc23uFRcofViepyZ+lkdo0yJ/7pflm/x/rVDeVHivfNHXiixFGck GmoxFxUnAgCkr3MZIAIAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets 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, 30 Apr 2013 07:53:17 -0000 Hi Dale, I do agree that part of a solution is the possibility to bind one or a set of SSRCs to a particular usage that is signalled somehow. However, there is several different types of bindings that is needed here. Just binding to a m= line is likely short sighted, restrictive and incomplete. I support your proposal of including a level of indirection enabling us to avoid having to update the SDP for any addition of SSRCs, which a a=ssrc based solution would require. However, SDP is not the only signalling solution, it is the currently dominating one, but if you ever is going enable us of breaking out of the SDP trap, we need to ensure that the solutions around are not SDP specific. Thus, using SDES items for in stream bindings are something I support, but the label should be done in such a way that it can be handled as labels for a particular purpose and thus be included in other signalling solutions. Then the next question is what intentions of bindings that you intended to do. There are several different ones that I see we have need in the near future. So lets look at some examples: - Application related usage of video streams, for example if a SSRC is currently carrying a main video or a thumbnail and thus which negotiated constraints it tries to adhere to. - Is the this SSRC part of a simulcast set, and if which quality strata does it carry - Is this SSRC a related repair or retransmission stream to another primary media carrying SSRC. One issue is that for example the first can easily be a dynamic process, some implementations will reconfigure a SSRC between application purpose due to user or application input. Just these three above examples points to one very clear issues in making progress here. We must try to clearly define the usage different people see. See which is the same, which is orthogonal and which must be possible to have in place at the same time. This is the realization we have come to with in the discussion around the SRCNAME proposal: http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname This discussion has proven the importance of having common terminology and I hope we can make progress with the grouping taxonomy, because that document will discuss both object names and different possible relation ships between these different types of object, like RTP sessions, SSRCs, FEC groups. Early version of grouping taxonomy that do need work. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/ Simulcast proposal https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-simulcast/ Our review of known use cases for richer grouping and naming: https://datatracker.ietf.org/doc/draft-burman-rtcweb-mmusic-media-structure/ I think all of these are relevant. I think one important question here is if you really want and think it is possible to bind have each different usage or purpose for an RTP media stream (specific SSRC) can be captured with its own unique Media Description (m= block)? I also think it is important to realize that a particular SSRC may at the same time have multiple relationships, for example it can be the primary for a retransmission, part of a FEC group, be a particular simulcast quality strata. Please don't bind identifier and group ides to SDP concepts. Lets use a level of indirection that both enables usage without SDP in certain cases, and which can be bound to other signalling solutions in the future. Cheers Magnus On 2013-04-29 23:59, Dale R. Worley wrote: > Moving this proposal over from the RTCWEB mailing list, updating and > correcting it: > > I was working on an essay based on the assumption that a single video > capture is carried over a single m= line (with the various component > streams (simulcast, FEC, layered encoding, etc.) sent using different > SSRCs)... But many existing systems don't work that way. It would be > nice to correct that, but basing our solution on that assumption isn't > the quick way to get products to market. ;-) So we can't assume a > small number of m= lines, which implies that we can't safely require > that each m= line has a disjoint set of payload types, which implies > that we can't demultiplex based on PT. > > If multiplexing based on payload type is unworkable, how about the > following technique. (Forgive me if someone else has already proposed > it.) > > Each SSRC is demultiplexed based on an RTCP SDES item that > specifies the mapping between the SSRC and the m= line via which > it is presented to the application layer. > > When a media stream with new SSRC is sent, the sender inserts an RTCP > SDES item with a special multiplexing "item type". The SDES item > contains the SSRC value and the identifier of the m= line via which > that SSRC is obtained from the application layer. For reliability, > the sender resends this SDES item occasionally. > > The receiver keeps a table which maps the SSRCs to the m= lines via > which each SSRC is to be presented to the application. Entries in the > table are added/updated when the multiplexing SDES items are received. > > Since SDES items are meant to describe the "source" of the media > stream, using an SDES item to identify how the media is supplied by > the application is probably within the semantic definition of SDES. > (If people don't like that, we could define another RTCP packet type.) > > For each stream, this mechanism only adds one 8 byte SDES item > periodically in the RTCP (given that RTCP packets often contain SDES > packets, so the SDES packet header isn't charged to carrying this > item). The overhead is reduced to 4 bytes if the RTCP periodically > contains SDES items for that SSRC anyway, and we don't have to charge > the 4 bytes carryig the SSRC. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > header |V=2|P| SC | PT=SDES=202 | length | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > chunk | SSRC | > 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MUX=11 | length=1 |0|m= line seq. | NULL=0 | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > chunk | ... | > 2 > > With dexterous use of pseudo-UTF-8 encoding to encode sequence > numbers, an 8 byte item suffices for the typical case, but we still > support multiplexing an unlimited number of m= lines. m= line > identifiers from 1 to 127 are represented > > +-+-+-+-+-+-+-+-+ > |0 s s s s s s s| > +-+-+-+-+-+-+-+-+ > > while identifiers from 128 to 2047 are represented > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 0 s s s s s|1 0 s s s s s s| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and larger identifiers can be encoded if necessary. > > These look like UTF-8 encodings of characters, so they shouldn't choke > code that interprets SDES items (the data values in SDES items are > UTF-8-encoded strings). > > We could even support multiplexing m= lines that specify multiple > addresses or ports by encoding a second identifier, which counts the > address or port in the group (starting at 1). > > This method allows multiplexing to support whatever use of m= lines > the overlying application supports/requires, since it places no > restrictions on the SDP or RTP usage. > > One interesting observation is that in order to make this work in 3PCC > situations, the m= line identifiers can't be the sequence number of > the m= line in the SDP in the offer/answer exchange, because the > sender of RTCP may be different than the endpoint sending the > offer/answer, and may see different SDP. So we need the m= line > identifier to be invariant when a 3PCC assembles/disassembles > aggregated SDP. One choice for that is to make the m= line index be > the sequence number of the m= line *within the m= lines in the > bundle*, since all of the m= lines in a bundle are routed to the same > media-generating endpoint. > > (This problem afflicts all methods that specify a demultiplexing > index, including SHIM > (draft-westerlund-avtcore-transport-multiplexing-05), KUMQUAT > (draft-worley-sdp-bundle-05), and even > draft-rosenberg-rtcweb-rtpmux-00.) > > Unfortunately, using m= line position within the bundle as the m= line > index, rather than using m= line position within the overall SDP, > makes demultiplexing unstable while bundling is changing due to a new > offer/answer exchange, because the demultiplexing index for an SSRC > will change. However, only m= lines whose transport is changing will > be affected by this instability. > > Dale > _______________________________________________ > 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 christer.holmberg@ericsson.com Tue Apr 30 00:57: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 A4D3421F9B6E for ; Tue, 30 Apr 2013 00:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 a7NgEZn9vl2i for ; Tue, 30 Apr 2013 00:57:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F332B21F9B2C for ; Tue, 30 Apr 2013 00:57:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-cf-517f794fe2c2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 80.4A.10459.F497F715; Tue, 30 Apr 2013 09:57:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 09:57:03 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL - Multiple SCTP m- lines Thread-Index: Ac5FeAhS7c9Sd3NUTVufnvM05JFzDw== Date: Tue, 30 Apr 2013 07:57:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3687B8@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+JvrW5AZX2gwao33BbXzvxjtJi6/DGL xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZRx7/Zy5YAJfxYK7sxkb GB/wdjFyckgImEicfvKPDcIWk7hwbz2QzcUhJHCYUaLj43p2CGcJo0TP/zbmLkYODjYBC4nu f9ogDSICoRJtF/cxgoSZBdQlri4OAgkLC7hJLGhuZIYocZf4v3AzE4StJ9H26zNYnEVAVWLS 9sksIDavgK/E/s7XYDWMQDd8P7UGzGYWEJe49WQ+E8RtAhJL9pxnhrBFJV4+/scKYStKXJ2+ nAniBE2J9bv0IVoVJaZ0P2SHGC8ocXLmE5YJjCKzkEydhdAxC0nHLCQdCxhZVjGy5yZm5qSX G25iBEbAwS2/dXcwnjoncohRmoNFSZy3KL8+UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj RsMbV5t5c7899pyh9dp+8veIiw8rNzqst2Seu6F5ykP72d+1LP8v91qzzEZ+9Q6Vu19qZq7e NE+pgWHe5PcXnr/bdkWj8+f8kOCUJfpK1cqPyjX9OJ7ayUTLcbhqJH/UktnbPedX6PavxfkX s+dlPvrBulatlLnO8M/qvc6BGQe9Sm4yWNWyKLEUZyQaajEXFScCAMy+SM5OAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Multiple SCTP m- lines 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, 30 Apr 2013 07:57:11 -0000 SGksDQoNCj4+PiBJbiB5b3VyIGV4YW1wbGUgdGhlcmUgaXMgb25seSBvbmUgU0NUUCBtLSBsaW5l LCBhbmQgaW4gV2ViUlRDIEkgZ3Vlc3MgDQo+Pj4gaXQgd2lsbCBhbHNvIGJlIHRoZSBjYXNlLCBi dXQgU0RQIGRvZXNuJ3QgcHJldmVudCB5b3UgZnJvbSB1c2luZyANCj4+PiBtdWx0aXBsZSBTQ1RQ IG0tIGxpbmVzIC0gdW5sZXNzIEJVTkRMRSBleHBsaWNpdGx5IGZvcmJpZHMgaXQsIHRoYXQgaXMu DQo+Pg0KPj4gSSBhZ3JlZS4gSWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoYXQsIHRoZW4gdGhlIG9i dmlvdXMgd2F5IChmb3IgDQo+PiBEVExTL1NDVFApIGlzIHZpYSBTQ1RQIHBvcnQuIFRoYXQgZGVw ZW5kcyBvbiB0aGVyZSBiZWluZyBhIHdheSB0byANCj4+IHNwZWNpZnkgdGhlIFNDVFAgd2l0aCBE VExTL1NDVFAuIFRoYXQgaGFzIGNvbWUgYW5kIGdvbmUgZnJvbSB0aGUgU0RQIHByb3Bvc2FsIGZv ciBTQ1RQLg0KPg0KPiBJIGRvbid0IGNhcmUgd2hldGhlciBTRFAgc3VwcG9ydHMgaXQgb3Igbm90 LCBJIGNhcmUgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBkbyBpdCBhdCBhbGwuDQo+DQo+IFRo ZXJlJ3MgYSByZWFzb24gd2h5IHlvdSBtaWdodCBub3Qgd2FudCB0byBtdXggU0NUUCAtIGl0J3Mg YSBwcm90b2NvbCB3aXRoIG11bHRpcGxleGluZyBzdXBwb3J0LiAgTXVsdGlwbGV4aW5nIG91dHNp ZGUgb2YgaXQgaXMgYXQgYmVzdCBhIGNydWRlIHRoaW5nIHRvIGRvIGFuZCBhdCB3b3JzdCBhIHdh eSB0byBkaWx1dGUgY29uZ2VzdGlvbiBzaWduYWxzLg0KPg0KPiBJIGNhbiB1bmRlcnN0YW5kIGhv dyB5b3UgY2FuIGNvbmNlaXZlIG9mIHNjZW5hcmlvcyB3aGVyZSBkaWZmZXJlbnQgYXBwbGljYXRp b24gbGF5ZXIgcHJvdG9jb2xzIGRvbid0IHBsYXkgd2VsbCB0b2dldGhlciBlbm91Z2ggdGhhdCB5 b3Ugd2FudCBtb3JlIGFnZ3Jlc3NpdmUgc2VwYXJhdGlvbi4gIEkgZG9uJ3Qgc2VlIHNpZ25pZmlj YW50IHZhbHVlIGluIHN1cHBvcnRpbmcgdGhvc2Ugc2NlbmFyaW9zLg0KPg0KPiBUaGF0IGRvZXNu J3QgY29tcGxldGVseSBwcmVjbHVkZSB0aGUgZnV0dXJlIHVzZSBvZiBTQ1RQIHBvcnQgZm9yIGRl bXV4LCBidXQgaXQgZG9lcyBjb25zdHJhaW4gY29tcGxleGl0eS4NCg0KWW91IGNhbiB1c2UgdGhl ICJidWlsdCBpbiIgU0NUUCBtdWx0aXBsZXhpbmcgc3VwcG9ydCAtIGFzIGxvbmcgYXMgYWxsIHVz YWdlcyBzaGFyZSB0aGUgc2FtZSBTRFAgbWVkaWEgZGVzY3JpcHRpb24gcHJvdG8gdmFsdWUuIElm IHlvdSwgeW91IG5lZWQgc2VwYXJhdGUgbS0gbGluZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQo= From magnus.westerlund@ericsson.com Tue Apr 30 02:44: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 9F9FF21F9B39 for ; Tue, 30 Apr 2013 02:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=-3.100, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 eA5gQhqgMkAl for ; Tue, 30 Apr 2013 02:44:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7D21F9B38 for ; Tue, 30 Apr 2013 02:44:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-f6-517f9289183a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3B.1D.10459.9829F715; Tue, 30 Apr 2013 11:44:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 30 Apr 2013 11:44:41 +0200 Message-ID: <517F9288.4050507@ericsson.com> Date: Tue, 30 Apr 2013 11:44:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mmusic (E-mail)" , suhasietf@gmail.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+JvrW7npPpAgyUHNCymLn/MYrFzbgez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx6MQvpoL7dhXn5ixgbWA8aNTFyMkhIWAi sefaQlYIW0ziwr31bF2MXBxCAqcYJc4vvMgMkhASWM4osf6EP4jNK6AtseJjEzuIzSKgKnHy +WUwm03AQuLmj0agZg4OUYFgia2tMRDlghInZz5hAbFFBGwkVh6+C2YLCzhIzL8xix1ir6TE lhftYDazgJ7ElKstjBC2vETz1tlQJ2hLNDR1sE5g5J+FZOwsJC2zkLQsYGRexciem5iZk15u uIkRGGAHt/zW3cF46pzIIUZpDhYlcd6i/PpAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwh C8POK9e+O2q4veZoQ/MBufNVz+zCzjPt2dJfUCv9ckc225vXH68bppewLvAtLBEp098gdlaR d3Kvz/bwf3eeKG2WOmx6fcnR/tot9/+X3+VSNMvYJtTNtP+UTei+C79zjYzi58nV9sybx8qr rf9G/IZv+JXGb+8zK7ava6pianiy4b2DJaMSS3FGoqEWc1FxIgC6fopM/gEAAA== Subject: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-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, 30 Apr 2013 09:44:57 -0000 Hi, Here is my review of the introduction and those sections related to RFCs that I have been part of writing as requested (5.3, 5.9, 6.2, 6.3, 8.3). I would have to note that although it is good to solicit reviews it would have been desirable to not CC the WG mailing list for each solicitation. 1) Section 1) However, in the RTCWeb WG, a requirement has arisen to multiplex several RTP Sessions over a single transport layer flow. I wished this was the part there was strong consensus because, the only solution on the table that tries to solve this issue is: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ What so far been most discussed is having multiple media types in one RTP session. That also implies multiple SDP Media Descriptions (m= blocks) describing one RTP session. There are a very important distinction here. Something I will return to. 2) Section 3: The specific problem is that there are attribute combinations which make sense when specified on independent m-lines -- as with classical SDP -- that do not make sense when those m-lines are then multiplexed over the same transport. I think this must be clarified to discuss one particular case: do not make sense when those m-lines are then jointly describing an RTP session over one specific transport. If you want to describe the issues of having multiple RTP sessions over the same transport, then you gets a different problem, as having multiple RTP sessions over the same transport requires some method for explicitly indicating which RTP session a particular RTP/RTCP packet belongs to as well as its signaling attribute. In fact almost the whole problem that arises in SDP signaling can go away as long as one enforces one m-line equals one RTP session. The "only" issue that remains under a paradigm of one m-line equeals one RTP session, and then using SHIM multiplexing are the SDP parameters that describe the common transport, i.e. ports, protocols, ICE, flow level QoS and aggregate bandwidths. 3) Section 4: o Attributes related to media content such as media type, encoding schemes, payload types. o Attributes specifying media transport characteristics like RTP/ RTCP port numbers, network addresses, QOS. o Metadata description attributes capturing session timing and origin information. o Attributes establishing relationships between media streams such as grouping framework This is clearly one way of classifying them. However, for the task in hand I think it would make more sense to maybe classify them in relation to: * Transport level: Specifying the underlying transport and protocol, such as ICE. * RTP Session level: RTP/RTCP extensions, payload types * Media Stream level: Identities, bandwidth, purpose, timing * Releationships: Grouping information I think using a two part classification might help: One for describing what scope a parameter has, and some might have more than one scope, and in that scope discuss the perceived impact on the attribute according to the proposed handling, i.e. normal, not recommended, identical, sum, special. The transport class should possibly be changed to "select one". 4) I also think your classes are assuming a bit of the solution as it appears to include make a difference for things that you think needs to be different to work with legacy, but if multiple media lines form one RTP session in the end must have a particular result. For example the difference between Transport and Identical is actually encoding that difference. If you have no legacy you could set all transport parameters identical over all the m-lines that are part of a common RTP session. Only if might encounter legacy do you need to have a different behavior. Thus a potential would be to separate the required behavior for legacy resulting in fallback into separate RTP sessions compared to forming a common one. For example a=candidate LEGACY: Unique BUNDLE: Identical I have not analyzed if this would expose new information, or if the transport category is sufficient to capture this difference? 5) Section 5.3: Appears correct. This is clearly a transport and RTP session affecting parameter. 6) Section 5.9: Identical works, but as being an RTP session level parameter one can see two interpretations here: A) RTP session level only, i.e. is reduced size RTCP enable for the RTP session. Then it should truly be identical. B) That is both an enabling and an indication of intent/allowance to use it related to the RTP media streams specified under this m-line. Thus the RTP session would be enabled for reduced size RTCP as soon as any m-line includes it and the peer acks it, while the individual m= lines indicates if it should be used. I don't know if that level of indication is necessary. Just pointing out that this is not a clear cut classification. 7) Section 6.1: For b=AS isn't normal and SUM a conflict? b=AS has two impacts, it will specify the RTCP bandwidth unless b=RR and/or b=RS is used. Thus it is a RTP session parameter. It is also one of these paramters that I gotten the feeling that people applies for an individual media stream, rather than a session aggregate. We also have the directionality issue here. In which directions does it applies? Note these issues arise from the unclear specification of b=AS rather than anything else. 8) Section 6.2: SUM is a reasonable classification. However, for a multi-stream environment it is not clear that an application actually need the sum of all RR and RS, as there is significant efficiency benefits in sharing RTCP bandwidth for multiple flows compared to needing to reach statistical feedback timeliness goals individually. Thus, you might want to have different values for a BUNDLE compared to a legacy case. 9) Section 6.3: First of all TIAS has no defined Offer/Answer usage. I know it is used in O/A context but that is not well defined. In fact it can't be providing accurate information of expected bit-rate for RTP level, only on media level prior to packetization. I would also note that a=maxprate is missing. It is an integral part of the solution that can't be ignored. The intention of TIAS is that you take the media level bit-rate and then multiply the known per-packet overhead for the selected transport with the maxprate value to determine the worst case bit-rate from the transport to more accurately capture the required usage. Thus, these values can't be SUMMED independently and then multiplied. That would inflate the value significantly. Multiply first then sum must be applied to even get close. This still ignores the fact that this is a send side declaration, and not intended for receiver negotiation. 9) Section 8.3: The capabilitiy to use ECN is a combination of transport and RTP session. I would note that it does requires certain additional SDP paremters such as the a=ecn-capable-rtp: attribute. I think these should be more explicitly be listed together. Especially as they don't appear to be mentioned otherwise in the document. As this is something you enable on RTP session level, I think it is need to arrive in identical parameters in a bundle case. And they can actually be identical in a legacy case also. I don't really see an reason for trying to use ECN with RTP for some RTP media streams and not all. 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 Tue Apr 30 05:16: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 7FC5521F9A6C for ; Tue, 30 Apr 2013 05:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oMxlEUbmWGFz for ; Tue, 30 Apr 2013 05:16:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E36C921F966A for ; Tue, 30 Apr 2013 05:16:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-a4-517fb6255fe3 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9A.47.19728.526BF715; Tue, 30 Apr 2013 14:16:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 14:16:37 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines? Thread-Index: Ac5Fm5YzG97WvrBuR0q4LrredSKh4Q== Date: Tue, 30 Apr 2013 12:16:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C368D88@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvra7atvpAg9P9TBbXzvxjtJi6/DGL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxa551wRLhigXvtzM2MD4R6mLk5JAQMJF4 dXkiE4QtJnHh3nq2LkYuDiGBw4wSTzZNg3KWMEoc+P+XtYuRg4NNwEKi+582SIOIgK7EorMP 2EHCzALqElcXB4GEhQUCJd5O28QIURIksWTGLChbT6JzWhsbiM0ioCpx4Mg0sL28Ar4STWca 2UFsRqAbvp9aAxZnFhCXuPVkPtRtAhJL9pxnhrBFJV4+/scKYStKXJ2+nAniBE2J9bv0IVoV JaZ0P2SHGC8ocXLmE5YJjCKzkEydhdAxC0nHLCQdCxhZVjGy5yZm5qSXG21iBIb6wS2/VXcw 3jkncohRmoNFSZw3fUV9oJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjL1LjvjEPV0jNG/z RCVOngNTNlUvn/t549NMtbkRQcGRUSdOVJ/bvthpZ7lk5uab955vL56SdyhKPrlX0mrvba1/ yYd9RArt3CQnK71uXs194vHf05v/nFEV8lm7soo/Kkvhz7R14jWvVPgi47e8U7SML1ml/KnZ +MwCqU7zXpcfQVM+MdQ+UGIpzkg01GIuKk4EAFDplBVDAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines? 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, 30 Apr 2013 12:16:59 -0000 SGksDQoNCj4+IEFzIHBlb3BsZSBoYXZlIGluZGljYXRlZCwgaXQgcHJldmVudHMgYSB0d28tdGlt ZSBwYWQgYXR0YWNrLCBhbmQgdGhhdCBpcyBhbHNvIHRoZSBvbmx5IHJlYXNvbiBJIGNhbiB0aGlu ayBvZi4gTXkgc3VnZ2VzdGlvbiBpcyB0byBrZWVwIHRoZSByZXN0cmljdGlvbiBpbiBsaXN0IDEg YW5kIDIuIEJ1dCwgaWYgc29tZW9uZSBPQkpFQ1RTIHRvIHRoaXMsIHBsZWFzZSBpbmRpY2F0ZSBz by4NCj4NCj4gVGhlIHR3by10aW1lIHBhZCB0aGluZyBpcyBib2d1cywgdW5sZXNzIHlvdSBhcmUg dXNpbmcgc2hpbSAoc28gdGhhdCB5b3UgY2FuIHJldXNlIFNTUkNzKS4NCj4NCj4gSSB0aGluayB0 aGF0IEkgd291bGQgbGlrZSB0byBPQkpFQ1QgdG8gdGhpcy4gIEl0IGlzIHBvc3NpYmxlIHRvIHBl cmZvcm0gZGVjcnlwdCBhZnRlciBkZW11eCwgYW5kIHRoZXJlIGFyZSBubyBpbmhlcmVudCBwcm9i bGVtcy4NCj4NCj4gSSBpbml0aWFsbHkgd2Fzbid0IHRoYXQgY29uY2VybmVkIHdpdGggcGVvcGxl IHRha2luZyB0aGlzIHBvc2l0aW9uLCBiZWNhdXNlIEkgZmlndXJlZCB0aGF0IGl0IHdvdWxkIGJl IGJldHRlciB0byBhbGxvdyBmb3Igc29tZSBmbGV4aWJpbGl0eSBpbiB0aGUgb3JkZXIgb2Ygb3Bl cmF0aW9ucy4gIEhvd2V2ZXIsIGl0IG1ha2VzIG11bHRpcGxleGluZyB0cmFuc2xhdG9ycyBoYXJk ZXIgdG8gYnVpbGQuDQo+DQo+IEl0J3Mgbm90IGEgc3Ryb25nIG9iamVjdGlvbi4gQWZ0ZXIgYWxs LCB3ZSBhcmUgYWxsIGluIHRoZSBidXNpbmVzcyBvZiBhY2NlbGVyYXRpbmcgdGhlIGhlYXQgZGVh dGggb2YgdGhlIHVuaXZlcnNlLg0KPg0KPj4+IDYuIElmIHlvdSBzdGFydCB3aXRoIGEgbT0gbGlu ZSB3aXRoIG9uZSBTREVTIGNvbmZpZyAoZS5nLiAzMi1iaXQgDQo+Pj4gTUFDKSwgYW5kIHRoZW4g QlVORExFIHdpdGggYW5vdGhlciBTREVTIGxpbmUgd2l0aCBhIGRpZmZlcmVudCAobm9uIA0KPj4+ IG92ZXJsYXBwaW5nKSBTREVTIGNvbmZpZyAoZS5nLiA4MC1iaXQgTUFDKSwgd2hhdCBoYXBwZW5z PyAoYXNzdW1lIA0KPj4+IGZhaWwpDQo+Pg0KPj4gUGVvcGxlIGhhdmUgaW5kaWNhdGVkIHRoYXQg dGhpcyB3b3VsZCBiZSBhIGZhaWx1cmUsIGFuZCBJIGhhdmUgc2VlbiBubyBvbmUgaW5kaWNhdGUg b3RoZXJ3aXNlLiBCdXQsIGlmIHNvbWVvbmUgT0JKRUNUUyB0byB0aGlzLCBwbGVhc2UgaW5kaWNh dGUgc28uDQo+DQo+IFNlZSBhYm92ZS4NCg0KUmVnYXJkaW5nIHVzaW5nIHRoZSBzYW1lIFNERVMg a2V5LCBpdCBpcyBpbXBvcnRhbnQgdG8gcmVtZW1iZXIgdGhhdCwgaWYgdGhlcmUgaXMgYSBmYWxs YmFjayAoaWUgdGhlIHJlbW90ZSBlbmRwb2ludCBkb2VzIG5vdCBzdXBwb3J0IEJVTkRMRSwgYW5k IHRoZSBTRFAgYW5zd2VyIHdpbGwgY29udGFpbiBkaWZmZXJlbnQgcG9ydHMpLCB0aGVyZSB3aWxs IGJlIGRpZmZlcmVudCBSVFAgc2Vzc2lvbnMsIGluIHdoaWNoIGNhc2UgdHdvLXRpbWUgcGFkIGJl Y29tZXMgYW4gaXNzdWUuDQoNClNvLCBvbmUgd2F5IGZvcndhcmQgd291bGQgYmU6DQoNCjEuIElu IHRoZSBmaXJzdCBvZmZlciwgd2hlbiBpdCBpcyBzdGlsbCB1bmtub3duIHdoZXRoZXIgdGhlIHJl bW90ZSBlbmRwb2ludCBzdXBwb3J0cyBCVU5ETEUsIHVzZSBkaWZmZXJlbnQgU0RFUyBrZXlzLg0K DQoyLiBJbiB0aGUgc2Vjb25kIG9mZmVyLCBpZiB0aGUgcmVtb3RlIGVuZHBvaW50IGluZGljYXRl ZCBzdXBwb3J0IG9mIEJVTkRMRSwgYWxsb3cgc3dpdGNoaW5nIHRvIGEgc2luZ2xlIFNERVMga2V5 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo= From christer.holmberg@ericsson.com Tue Apr 30 06:26: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 725AB21F9AC5 for ; Tue, 30 Apr 2013 06:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 se51cVoL82lG for ; Tue, 30 Apr 2013 06:26:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BAAB321F9778 for ; Tue, 30 Apr 2013 06:26:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-89-517fc68c76ab Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BB.5A.03253.C86CF715; Tue, 30 Apr 2013 15:26:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Tue, 30 Apr 2013 15:26:36 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: mandate RTP/RTCP multiplexing? Thread-Index: Ac5FpkrHryzI/aQNT0iUvXy00zH5hw== Date: Tue, 30 Apr 2013 13:26:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C368E12@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C368E12ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW7vsfpAg49HmS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCk7drAUPJSs2DH1HEsD40OxLkZODgkBE4kTy3ezQdhiEhfu rQeyuTiEBA4zSjxfMZMFwlnCKHH79jLGLkYODjYBC4nuf9ogDSIC6hJf9/Ywg9jCAvoSG8/1 sUPETSR+vZvODGHrSfz9/o0dpJVFQFWid3YISJhXwFdiysJ3YHsZgfZ+P7WGCcRmFhCXuPVk PhPEPQISS/acZ4awRSVePv7HCmErSlydvhyqPl/iZtNcJoiZghInZz5hmcAoNAvJqFlIymYh KYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGNlzEzNz0svNNzECg/7glt8GOxg33Rc7 xCjNwaIkzpu7rz5QSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OfWO8r29Rd01x1uQOuTvu8 rWHFhvpHDss2+zTYhVWlaOtabll56IbvzplPArZbGdYeO+v/+NiiW42X5oRyXL7mIdc8af/p syf/53+MDbn0qLXS7fO09IXy29fwSPzvFV3+c96fp9MWx/M5REw7udD8vsHKqFkrppx9cOFU avn7pWU8m9J36/tuU2Ipzkg01GIuKk4EABz2Ft9IAgAA Subject: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? 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, 30 Apr 2013 13:26:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C368E12ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As currently indicated in BUNDLE, and SDP offer for RTP must contain an rtc= p-mux attribute, indicating support of RTP/RTCP multiplexing. However, it is currently optional to include it in the SDP answer. There has been some discussions on whether we should MANDATE the usage of r= tcp-mux whenever BUNDLE is enabled. Would anyone OBJECT to that? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C368E12ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As currently indicated in BUNDLE, and SDP offer for = RTP must contain an rtcp-mux attribute, indicating support of RTP/RTCP mult= iplexing.

 

However, it is currently optional to include it in t= he SDP answer.

 

There has been some discussions on whether we should= MANDATE the usage of rtcp-mux whenever BUNDLE is enabled.

 

Would anyone OBJECT to that?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C368E12ESESSMB209erics_-- From magnus.westerlund@ericsson.com Tue Apr 30 07:44: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 9621A21F9B35 for ; Tue, 30 Apr 2013 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_19=0.6, 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 EZwbBCMiAM+n for ; Tue, 30 Apr 2013 07:44:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 973A221F9ABE for ; Tue, 30 Apr 2013 07:44:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-41-517fd8c4eceb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 89.9C.10459.4C8DF715; Tue, 30 Apr 2013 16:44:20 +0200 (CEST) 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; Tue, 30 Apr 2013 16:44:19 +0200 Message-ID: <517FD8C2.307@ericsson.com> Date: Tue, 30 Apr 2013 16:44:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> <517ECCFF.6040706@alum.mit.edu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre6RG/WBBp1bFS2unfnHaDF1+WMW ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyvh79yxrwS3Zik+n9jE1 MH4V72Lk5JAQMJH40zWfCcIWk7hwbz1bFyMXh5DAKUaJvhtHmSCc5YwSry92sYFU8QqoS2xu mMLexcjBwSKgKvF9VSJImE3AQuLmj0Y2kLCoQLDE1tYYiGpBiZMzn7CA2CICuhKLzj5gBxnJ LNAGNHJGM9hIYQEzidMNf1ggdk1nkpj7cAUrSIJTIFBi7bkvjBDXSUpsedHODmIzC+hJTLna wghhy0s0b53NDGILCWhLNDR1sE5gFJqFZPksJC2zkLQsYGRexciem5iZk15uuIkRGMAHt/zW 3cF46pzIIUZpDhYlcd6dp+sDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCWNtl/OCR8KKGi rW7zRauwpV4XFqUdPdrdMn9ZxNl3a5atVj69NV61YekE7e5MXsV/n49unVSaMssjhWvNJTmD idu4rbz2L6m2MbNldL9272mDhJTJgnP1H7M+rJ3NkCP08j3zQ42YTpu7lU2Ke55zx951fbCj qeDssW3SevNiOr6X6KVp16cosRRnJBpqMRcVJwIA+DCgcS4CAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM 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, 30 Apr 2013 14:44:43 -0000 On 2013-04-30 01:03, Martin Thomson wrote: > On 29 April 2013 12:41, Paul Kyzivat wrote: >> One more thing - a question for all: >> >> Do you agree that there is a need to support more than one way to demux RTP, >> and hence a need to signal what way is to be used? >> >> Or do you think we will be able to reach agreement on a single algorithm, so >> that signaling of the algorithm isn't required? > > There is agreement in avtcore to build two demux schemes. The need to > signal the choice of demux scheme has already been made for us. > > Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh > and protocol if you've got this DTLS thingy))" and then have a > SHIMBUNDLE grouping. That would be actively antisocial. Can you please clarify why you think this is anti-social? I would like to point out that BUNDLE and SHIM operates at different levels. To my understanding BUNDLE is a way of using multiple media descriptions (m= lines) to describe one RTP session. SHIM is an explicit layer for transmitting multiple independent RTP session on the same lower layer transport. Each RTP session will be described using its own signaling, which could include BUNDLE of multiple m= lines. The transmission of DTLS/SCTP over the same UDP flow as an RTP session is yet another problem of who shares the lower layer transport. A number of RTP sessions over SHIM will be able to share the lower layer transport (UDP) with DTLS/SCTP, more from the perspective that it must be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work than anything else. Colin Perkins and I did privately discuss ways of signalling the SHIM solution in Orlando and put together a strawman. I can share it here to see what input you have. 1) We would have one m= line to describe the SHIM's transport itself, i.e. m=application 12345 UDP/SHIM * a=candidate ... 2) Each RTP session would be described normally with or without bundle. Although we prefer to avoid BUNDLE, but that would depend on the rest of discussion on what recommendation for multiple m= lines description of one RTP session means. The port numbers on the m= lines would be used as SHIM IDs. They anyway have to be unique for fallback if BUNDLE is not supported. 3) The media descriptions involved in one SHIM will for clarity be indicated using a SHIM specific grouping semantics. 4) If SHIM is supported as determined by first round, the media descriptions can be cleaned up and any unnecessary transport information can be removed in second round to verify that middleboxes don't misunderstand that SHIM is being used and that is the only main transport parameters for the streams put on that SHIM. This proposal is intentionally not requiring BUNDLE because we want to enable the fallback from SHIM to Individual sessions over different transports if SHIM is not supported. If BUNDLE would be included then then choice of fallback from SHIM might become BUNDLE, which in most cases is not desired. You are using SHIM because you want different RTP sessions, not have everything put into one RTP Session. Sorry if I missed something important in earlier discussions. I am still catching up on MMUSIC and I haven't managed to read it linearly. 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 bernard_aboba@hotmail.com Tue Apr 30 08:21: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 6B50621F841D for ; Tue, 30 Apr 2013 08:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.944 X-Spam-Level: X-Spam-Status: No, score=-101.944 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Kig+OZnZQAfx for ; Tue, 30 Apr 2013 08:21:15 -0700 (PDT) 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 866C121F93DC for ; Tue, 30 Apr 2013 08:21:15 -0700 (PDT) Received: from BLU169-W121 ([65.55.116.74]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 08:21:15 -0700 X-EIP: [IPYnoRVysTcIBjqeOyKmIGjV7I9+L2oJ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_19e1cdb6-b983-4c6d-b9dd-353435b012e8_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Tue, 30 Apr 2013 08:21:14 -0700 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2013 15:21:15.0035 (UTC) FILETIME=[5AD13EB0:01CE45B6] Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? 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, 30 Apr 2013 15:21:20 -0000 --_19e1cdb6-b983-4c6d-b9dd-353435b012e8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No objection here to requiring rtcp-mux with BUNDLE. Implementations not = supporting rtcp-mux probably don't support BUNDLE either. =20 From: christer.holmberg@ericsson.com To: mmusic@ietf.org Date: Tue=2C 30 Apr 2013 13:26:35 +0000 Subject: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Hi=2C=0A= =0A= As currently indicated in BUNDLE=2C and SDP offer for RTP must contain an r= tcp-mux attribute=2C indicating support of RTP/RTCP multiplexing.=0A= =0A= However=2C it is currently optional to include it in the SDP answer.=0A= =0A= There has been some discussions on whether we should MANDATE the usage of r= tcp-mux whenever BUNDLE is enabled.=0A= =0A= Would anyone OBJECT to that?=0A= =0A= Regards=2C=0A= =0A= Christer=0A= =0A= =0A= =0A= _______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic = --_19e1cdb6-b983-4c6d-b9dd-353435b012e8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No objection here to requiring r= tcp-mux with BUNDLE.  =3B Implementations not supporting rtcp-mux proba= bly don't support BUNDLE either.  =3B

From: christer.holmberg@ericsson.c= om
To: mmusic@ietf.org
Date: Tue=2C 30 Apr 2013 13:26:35 +0000
Sub= ject: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

=0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

Hi=2C

=0A=

 =3B

=0A=

As currently indicated in BUNDLE=2C and SDP offer= for RTP must contain an rtcp-mux attribute=2C indicating support of RTP/RT= CP multiplexing.

=0A=

 =3B

=0A=

However=2C it is currently optional to include it= in the SDP answer.

=0A=

 =3B

=0A=

There has been some discussions on whether we sho= uld MANDATE the usage of rtcp-mux whenever BUNDLE is enabled.

=0A=

 =3B

=0A=

Would anyone OBJECT to that?

=0A=

 =3B

=0A=

Regards=2C

=0A=

 =3B

=0A=

Christer

=0A=
=0A= =0A= =0A=
_______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic
= --_19e1cdb6-b983-4c6d-b9dd-353435b012e8_-- From pkyzivat@alum.mit.edu Tue Apr 30 09:02: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 65EC321F934C for ; Tue, 30 Apr 2013 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 lh4eVLAbcAci for ; Tue, 30 Apr 2013 09:02:30 -0700 (PDT) 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 5437C21F85C3 for ; Tue, 30 Apr 2013 09:02:29 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id WAW61l0040SCNGk55G2V9q; Tue, 30 Apr 2013 16:02:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id WG2U1l00t3ZTu2S3VG2Uq4; Tue, 30 Apr 2013 16:02:29 +0000 Message-ID: <517FEB14.3000407@alum.mit.edu> Date: Tue, 30 Apr 2013 12:02:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> <201304251934.r3PJYupZ3410480@shell01.TheWorld.com> <517A9991.3060901@alum.mit.edu> <201304292159.r3TLxCQT3757057@shell01.TheWorld.com> In-Reply-To: <201304292159.r3TLxCQT3757057@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=1367337749; bh=6MpoUnnPOgqltPkBCbNpI6Aal13Zz2i/oC6vNWSgGv4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I3byUD8+H0zbFSpqesVTz/MktuCmOC3+Js+WVxDkj2cdPFidVoWc5TC2KLLfRVj5R 1P4vvoJ3mBJG+1J4CSvPclALlMjmUJcHprNq1/qTE1wG1TlnrHvXfyJcx2VpzE41uk 5/yTlrsBN2Rj5ehZlW/K/ltG2XCBnWvxixdQsdadvlfL6b+LkmPARhcp5GJvdwRG9e J3vODgEISQpKIu2+YMQNOlCXdn+ca0CIZ6aY+uSZE5LUxLTWzNNgRFFHAO21iE/TYS gX9ZJccEIbOqzvLiPaiEX86cnDnqOTdF7Uq5V9DuDQfP4E8X0KfmhhN/iHJG5QNbHA T9tKAurQ1KtnQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] "splitting" 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: Tue, 30 Apr 2013 16:02:36 -0000 On 4/29/13 5:59 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> I only bring it up because past experience >> with O/A has shown that it is generally better for an offerer to say >> what they want without making value judgements about the other party. It >> becomes especially important if it turns out that the party you are >> sending the offer to turns out to be different from the one you talked >> to last. (That probably is nonsense here if these O/A cycles are >> back-to-back.) > > The difficulty in this case with always offering everything you want > is that the process never ends: Each endpoint *wants* to bundle m= > lines that the other endpoint can't accept. > > OTOH, you have to worry about the possiblity that at this moment, the > other endpoint is not the endpoint you negotiated with previously. Yep! > A solution is that if the endpoint is sending an offer to effect > bundling between m= lines that it disconnected from an *immediately* > preceding offer, the endpoint should offer no bundling that was not > proposed in the preceding offer. New offers generated for other > reasons would offer all the bundling the endpoint is willing to > support. I think I agree with what you mean, but not with what I you wrote. I think you mean: "A solution is that if the endpoint is sending an offer to effect bundling between m= lines that it disconnected from an *immediately* preceding offer, the new offer should not disturb the bundles that were accepted in the prior answer. New bundles may be offered including m-lines refused in the prior answer as well as new m-lines. New offers generated for other reasons would offer all the bundling the endpoint is willing to support." This allows the 2nd O/A to introduce the remainder of the split bundle. >> In all of the above, the behavior of B only makes sense if B feels it >> *needs* all of these streams. Another possibility is that B simply >> rejects the streams it can't accept when bundled as proposed, but >> doesn't initiate another O/A cycle. Then if A feels those are important, >> *it* can send another offer with them separately bundled. > > The difficulty with that is that A doesn't know whether B rejected > them because it couldn't deal with the bundling or because B was > unable to utlize the m= line for some other reason. A would have to > send a number of probes to determine the answer. For this to be practical we would have to come up with a way to signal the *reason* those m-lines were refused. Preconditions might be one way. >> But having B make the second >> offer means it may need to take on faith "I don't know if these streams >> are important, but my peer wanted them so I'll try to establish them." > > B would only include the stream in a second offer if B would have > accepted the stream un-bundled, which means that B knows that A wants > the stream (whether or not A considers it "important") and that B can > support it, in which case we assume that the penalty for supporting > the stream without bundling is lower than the penalty for not > supporting the stream at all. This will probably be ok. But we need to recognize that it is a slight leap of faith. >> These cases requiring multiple O/A cycles to get things arranged as >> desired are starting to smell to me like the kinds of situations that >> preconditions were designed for. Perhaps a new "bundle" precondition >> would provide a way to sort out responsibilities and realize when to >> keep trying and when to give up. But many consider preconditions too >> heavy weight to use in practice. And they could prove difficult in JSEP. > > It does resemble precondition situations. But we can arrange for > exactly two O/A cycles to determine the maximal bundling that both > endpoints can support. It seems so. >>> But if either side initiates a re-offer for some other reason, the new >>> offer should be the biggest bundling the offerer is willing to >>> support. >> >> You mean, in the above case, after having agreed on bundles 1,2 ; 3/4 ; >> 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer >> 1,2,5,6 ; 3,4,7,8,9 ??? >> >> I *think* the new offer should include the new bundles in their current >> operational form, with only one address/port per bundle. Doing otherwise >> would disrupt the functioning of the current streams. Stream 9 could be >> added to one of the existing bundles in the offer, but should have a >> separate address/port. >> >> That will probably break a scenario that is trying to do a 3pcc >> transfer. I suspect that doing such a thing with bundled streams is >> going to be *hard*, and will need to be considered separately. > > The question is whether B thinks A might have been replaced by A'. In general I think we can assume that coincidences don't happen much. In particular, if conditions have changed at one endpoint such that it spontaneously needs to make a new offer that changes things from the current state, then it is exceedingly unlikely that the other endpoint will simultaneously have a change of state that it needs to introduce in the answer to that offer. > Now that you mention it, if B adds stream 9 (generating a new offer > for internal reasons), then it is very unlikely that A has been > replaced. But if B receives an offerless INVITE (demanding that B > produce an offer), then A might well have been replaced. Yes, the offerless invite should be viewed as a solicitation for the full set of desires of the receiver. > If B receives an offer, there are three cases: > > The offer may be from an A', in which case it's OK if B gives the best > response it can (according to the previous plan), and does a re-offer > if it needs to create new bundles to split an offered bundle. > > The offer may be from A, generated for internal reasons, in which case > it looks very much like the previous SDP. But, e.g., added m= lines > may be bundled in a way that B can't accept and may require B to > produce a second offer. One thing to clarify in a case like this is how such an offer (adding a new m-line to an already active bundle) should be structured. I think, for practical reasons, it should have a single address/port for all of the m-lines that had previously been bundled. Not doing so will disturb the ongoing flows. This *does* mean that it might get in trouble if the recipient turns out to be B' rather than B, and B' doesn't support bundle. Barring coincidences, this shouldn't happen with an unsolicited offer. > The offer may be from A, generated due to receiving an offerless > INVITE from an intermediate 3PCC controller, in which case (we assume) > it specifies the maximal bundling that A can support. That may > require B to produce a second offer. The offerless invite *might* be an indication that B has been replaced by B'. But there are also uses of offerless invites when that hasn't happened. And we can't screw things up in those cases. If B has not been replaced, then I think it remains important that the existing bundles not be disturbed. So if that is a possibility, then A should send an offer that has the existing bundles as they are. If it turns out that B has been replaced by B', then that may be sub-optimal. And if B' doesn't support bundling, then it may not work at all. It would be nice if we had a way, in the offerless invite, to send something so the receiver could discover if it was talking to the same party as before. AFAIK we don't have a way to do that. > So it looks like we can soften the rules to: > > If an endpoint makes an offer for what it sees as a new dialog, or due > to receiving an offerless INVITE, it must offer the maximal bundling > it supports. As noted above, I don't think this works. > If an endpoint receives an offer, it answers with the maximal bundling > that it supports that is a subset of the offered bundling. (I say > "subset", as the answer necessarily has no more bundles than the > offer.) The endpoing may then make a second offer that offers the > maximal bundling that it supports that is compatible with the received > offer. ("Compatible" in the sense of bundling no two m= lines that > were not bundled in the offer.) Presumably in the 2nd offer, if a new bundle is proposed, then all the m-lines in that offer can share a single address/port, because support for bundling is already known. Thanks, Paul From pkyzivat@alum.mit.edu Tue Apr 30 09:20: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 9B9D621F9BD4 for ; Tue, 30 Apr 2013 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_19=0.6, RDNS_NONE=0.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 nyPILz4qaX9t for ; Tue, 30 Apr 2013 09:20:11 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8F21F9BB9 for ; Tue, 30 Apr 2013 09:20:10 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id WBqy1l0081ap0As59GL9Rr; Tue, 30 Apr 2013 16:20:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id WGL91l0113ZTu2S3iGL9PQ; Tue, 30 Apr 2013 16:20:09 +0000 Message-ID: <517FEF39.2030306@alum.mit.edu> Date: Tue, 30 Apr 2013 12:20:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Magnus Westerlund References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> <517ECCFF.6040706@alum.mit.edu> <517FD8C2.307@ericsson.com> In-Reply-To: <517FD8C2.307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367338809; bh=672hbDOl+MogqIQL7L3bRnDC0TlHE5SGa/mh5NQ+GzM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UARAx0D+FYqHkYscpoulc/a3dcyP2cUPPWPMd4hGEdWzNAEx+R1dbaN6yhLGzNMx4 r6sQsdrqXnKzJY1D42JsZEMt2vpynYEoxmbrm0MF6GaDvAbOwN52hV3jllsOEvGhq2 UBPaRLoh//MM/fQMDq1AEYtfgJ/1oe79C74iQES/8avYywpr/6UQ29ZEN/I0AM9n9j 73LCwjHZVpWiQRtHkpWfUXEzZPhOSkWUzc5lHzkesUM2xA8erOZcfujCwP5n57ygHL qTkwHYWsyaowJvzgtu+LGB+mA9V8jPAZb02Bh0PSEP/R6smxB20beHFdB4VSNXSJq0 Lbr1yHs9jTXiQ== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM 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, 30 Apr 2013 16:20:28 -0000 Inline... On 4/30/13 10:44 AM, Magnus Westerlund wrote: > On 2013-04-30 01:03, Martin Thomson wrote: >> On 29 April 2013 12:41, Paul Kyzivat wrote: >>> One more thing - a question for all: >>> >>> Do you agree that there is a need to support more than one way to demux RTP, >>> and hence a need to signal what way is to be used? >>> >>> Or do you think we will be able to reach agreement on a single algorithm, so >>> that signaling of the algorithm isn't required? >> >> There is agreement in avtcore to build two demux schemes. The need to >> signal the choice of demux scheme has already been made for us. >> >> Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh >> and protocol if you've got this DTLS thingy))" and then have a >> SHIMBUNDLE grouping. That would be actively antisocial. > > Can you please clarify why you think this is anti-social? > > I would like to point out that BUNDLE and SHIM operates at different > levels. To my understanding BUNDLE is a way of using multiple media > descriptions (m= lines) to describe one RTP session. > > SHIM is an explicit layer for transmitting multiple independent RTP > session on the same lower layer transport. Each RTP session will be > described using its own signaling, which could include BUNDLE of > multiple m= lines. AFAIK the SDP in support of shim has never really been discussed. The bundle proposal. But the bundle draft does say: When media is transported using the Real-Time Protocol (RTP) [RFC3550], the default assumption of the mechanism is that all media associated with a "BUNDLE" group will form a single RTP Session [RFC3550]. However, future specifications can extend the mechanism, in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups where media associated with a group form multiple RTP Sessions. which is a hint that it *could* be extended to apply when shim is used. My thinking is that this bundling stuff is sufficiently messy and complex that we won't want to do something similar but different for shim. Instead, I am inclined to view the shim as just another mechanism for multiplexing. If so, then a suitable mechanism for signaling the sort(s) of multiplexing to be used in a bundle should support it as well. > The transmission of DTLS/SCTP over the same UDP flow as an RTP session > is yet another problem of who shares the lower layer transport. Yep! And we *know* we want to coexist that with some flavors of RTP. > A number of RTP sessions over SHIM will be able to share the lower layer > transport (UDP) with DTLS/SCTP, more from the perspective that it must > be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work > than anything else. IIUC the demux of shimmed RTP from DTLS/SCTP is exactly the same as for unshimmed RTP. > Colin Perkins and I did privately discuss ways of signalling the SHIM > solution in Orlando and put together a strawman. I can share it here to > see what input you have. IMO we don't need to spend much time on it now, as long as we can see a way forward if/when we get around to working on it. > 1) We would have one m= line to describe the SHIM's transport itself, i.e. > m=application 12345 UDP/SHIM * > a=candidate ... > > 2) Each RTP session would be described normally with or without bundle. > Although we prefer to avoid BUNDLE, but that would depend on the rest of > discussion on what recommendation for multiple m= lines description of > one RTP session means. > > The port numbers on the m= lines would be used as SHIM IDs. They anyway > have to be unique for fallback if BUNDLE is not supported. > > 3) The media descriptions involved in one SHIM will for clarity be > indicated using a SHIM specific grouping semantics. > > 4) If SHIM is supported as determined by first round, the media > descriptions can be cleaned up and any unnecessary transport information > can be removed in second round to verify that middleboxes don't > misunderstand that SHIM is being used and that is the only main > transport parameters for the streams put on that SHIM. > > This proposal is intentionally not requiring BUNDLE because we want to > enable the fallback from SHIM to Individual sessions over different > transports if SHIM is not supported. If BUNDLE would be included then > then choice of fallback from SHIM might become BUNDLE, which in most > cases is not desired. You are using SHIM because you want different RTP > sessions, not have everything put into one RTP Session. This smells like there are as many rat holes to pursue as there have been in bundles without SHIM. I doubt we want to go there now. > Sorry if I missed something important in earlier discussions. I am still > catching up on MMUSIC and I haven't managed to read it linearly. Hard to tell. :-) Thanks, Paul > 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 pkyzivat@alum.mit.edu Tue Apr 30 10:12: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 36E5121F9C1C for ; Tue, 30 Apr 2013 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 WPuFA7aY1ZXe for ; Tue, 30 Apr 2013 10:12:32 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA2721F9763 for ; Tue, 30 Apr 2013 10:12:31 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id WFPg1l0061HzFnQ5EHCXSi; Tue, 30 Apr 2013 17:12:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id WHCW1l01Y3ZTu2S3aHCXBR; Tue, 30 Apr 2013 17:12:31 +0000 Message-ID: <517FFB7E.8050801@alum.mit.edu> Date: Tue, 30 Apr 2013 13:12:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C368E12@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=1367341951; bh=ZoKWJAkdWM1anW/EXuiexeGv4fuQQ9RwNW2MTt9pa2I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Boqh0nD5sUIHYmE4d3niwSn9Jbtg6U2OMM5PNrYlpmSLS/cmCpcWD8xrOGvFFvfjf CYDBeubbhR9bolYGpbTV8Ty1AQ9yZs3wAaj455ZJe+l1G9okrK2PIGG7Fi+qTC4EkX 8vpkGRR7cLKuBaf8BPaDFbCkRoJ/EXbuIMcBef9sAuRrTL9TiKa7hfEE3vrReEWSoK N8Iytv99UVmpTSur3jB5ivrmj7ZR6aGmlIMXKzaJ6XvqHyhONvrfENLZJ9veFoaK+D 8UyL/c7ZiYTskisBz4iQaCK8t0OSZ8oPtuXzuGxveOyPwKX0neYwOgBiEmrfHS4uET SjSLgdi/AMrzg== Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? 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, 30 Apr 2013 17:12:48 -0000 On 4/30/13 9:26 AM, Christer Holmberg wrote: > Hi, > > As currently indicated in BUNDLE, and SDP offer for RTP must contain an > rtcp-mux attribute, indicating support of RTP/RTCP multiplexing. > > However, it is currently optional to include it in the SDP answer. > > There has been some discussions on whether we should MANDATE the usage > of rtcp-mux whenever BUNDLE is enabled. > > Would anyone OBJECT to that? What are the implications of *not* mandating it? Doing so requires two ports, so in some sense you end up with two bundles. If a=rtcp:nn is used, then presumably it will need to be the same in all RTP m-lines. But we have many such requirements, so this one isn't special. I guess I won't *object*, but it does offend my notion that independent things should be kept independent. Thanks, Paul From martin.thomson@gmail.com Tue Apr 30 11:50: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 4570821F9BA4 for ; Tue, 30 Apr 2013 11:50:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5smnJ3Q8l0on for ; Tue, 30 Apr 2013 11:50:03 -0700 (PDT) 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 EF1E621F9B5E for ; Tue, 30 Apr 2013 11:50:02 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id t11so680346wey.23 for ; Tue, 30 Apr 2013 11:50:02 -0700 (PDT) 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=rlQCu/lBD6zGsBgo8giJa1xcZDJWqF9PChWMb5Vd+F0=; b=ut4CYRIeJuFspoKt2+QZW6FEA5YEvRKdKo7StzBikTMLag2hZap4eo3yAr1CtJE2cD EOu9JIdFl1VWDBObmwaKZHlzT5l3uMlWvp/WhLRwsutFbxFhv4WUE4JPlDCqX1Pr8kSL +2ASZB1W3+wpkTuNB+B/KdhJjUKuBzvQ/A3VZJeutszau0blnYH4ljIkiIknfzd6ELdl 3JNkiKc0nXl4QSM+ntZnI35BNF0ShSm6XJ/RjVuYxpjGXdxJBjoopIeY5te9yGIeoRhg lP/wIb+aUtjJPkAVUO+NKX76fiG6mijexNdtSCdkzCu5buzwcuHIvUF1G3j17d2W/hyE A/ig== MIME-Version: 1.0 X-Received: by 10.194.78.204 with SMTP id d12mr14455924wjx.42.1367347802081; Tue, 30 Apr 2013 11:50:02 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 11:50:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C368D88@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C368D88@ESESSMB209.ericsson.se> Date: Tue, 30 Apr 2013 11:50:01 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines? 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, 30 Apr 2013 18:50:04 -0000 On 30 April 2013 05:16, Christer Holmberg wrote: > Regarding using the same SDES key, it is important to remember that, if t= here is a fallback (ie the remote endpoint does not support BUNDLE, and the= SDP answer will contain different ports), there will be different RTP sess= ions, in which case two-time pad becomes an issue. Yes, I hadn't considered that, but it's another reason to have different keys :) Since this is only the bundling side that is affected, this can be addressed with a security considerations note to the effect that the bundler, who has chosen to use the same key across m=3D lines, MUST NOT select the same SSRC for those sessions. I think that's an easy thing to do. Still, even without special measures chances are that you wont pick colliding SSRCs. Though the odds are not really in your favor given the size of the space you chose from; it doesn't take many sessions before it happens to someone. > So, one way forward would be: > > 1. In the first offer, when it is still unknown whether the remote endpoi= nt supports BUNDLE, use different SDES keys. > > 2. In the second offer, if the remote endpoint indicated support of BUNDL= E, allow switching to a single SDES key. That would be reasonable too. I probably wouldn't bother with the change in practice (see above), but MAY =3D=3D good. From martin.thomson@gmail.com Tue Apr 30 11:55: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 B2F0B21F9C68 for ; Tue, 30 Apr 2013 11:55:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or87lFlSdZU2 for ; Tue, 30 Apr 2013 11:55:25 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4221F9C6A for ; Tue, 30 Apr 2013 11:55:22 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t9so707961wey.5 for ; Tue, 30 Apr 2013 11:55:22 -0700 (PDT) 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=/ahHV80VvRf9zgCxwKrY795PPSEbnFd9mqTQSLYDxow=; b=Xm8XmA/U4n4SGsj5FTGwseLhQz56pYN8O2OsjSCIbijJ3CmiYNg/1wyL0okRYIv8I9 aEqQsueZJe1BnjDOL10Ga7CGxJuTU7UaCj82AiJ1hRcTEu1dOjITzzVXeu1sWjExhAO4 erkx2GobXox38YebSXMlt8xfdBurrRuJXC80GPE7OIqJZuCOXLnC4HvhP2JNVqp1vA75 wgmF+d5JeSuN4saCyFkjFGm1QI8OiZxpfAzrwfDjEkGHtuDPECszMQErvoTKNiodSM9q 0s7DWuehOP1zI3Z6CcaWQ6qnw6lYqZGVKjUXQJMa/xICJ/Bb53iOPNvFtHL0VTfdwMqT CpNA== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr16620425wic.32.1367348122252; Tue, 30 Apr 2013 11:55:22 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 11:55:22 -0700 (PDT) In-Reply-To: <517FD8C2.307@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> <517ECCFF.6040706@alum.mit.edu> <517FD8C2.307@ericsson.com> Date: Tue, 30 Apr 2013 11:55:22 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM 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, 30 Apr 2013 18:55:30 -0000 On 30 April 2013 07:44, Magnus Westerlund wrote: > On 2013-04-30 01:03, Martin Thomson wrote: >> Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh >> and protocol if you've got this DTLS thingy))" and then have a >> SHIMBUNDLE grouping. That would be actively antisocial. > > Can you please clarify why you think this is anti-social? My impression was that there would be a degree of overlap between the two solutions. From your mail, it appears as though you intend to go a completely different path. So, not anti-social I guess. From martin.thomson@gmail.com Tue Apr 30 12: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 742F221F9C8C for ; Tue, 30 Apr 2013 12:00:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzCdYjJOSPxw for ; Tue, 30 Apr 2013 12:00:38 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6860821F9C96 for ; Tue, 30 Apr 2013 12:00:32 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so3323798wgh.3 for ; Tue, 30 Apr 2013 12:00:31 -0700 (PDT) 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=T5qUI+AgSi+ITQm9LHw0/4rzU8wn++KOxKb5gpyLbxI=; b=XnYayf3bqbUFpZdnHWjraYlbKQ29a9JwuHXIckPi6y9RqphI3a+baDmxZ7yJbjjhwg RdGB/a9WVcUCmzfr0QMUQkiJ83cEx8XBGTgodyry/7MMD2N1d4pnKgEdgWwOnkN6YkOQ HxQd2oFNb5X2RRfqyvNzFk2oR4UrmSOu2JudGYQHasdK1xEOrT4lhpMfQSqmvQZKQ4cL zacrKBQZQrJdWLP3/AVT1y5i7ouhYYu04WKnmh4vEQ4f+UuGQJFRF6T9Hvt0z3wAKLaV UCtW0iZP3MNyugc9VDPwK1mQCRodyDV9ArEBVgZvcLUALZiXzonAW2aM9rBCPDCnH2X2 mrLQ== MIME-Version: 1.0 X-Received: by 10.194.63.239 with SMTP id j15mr20445038wjs.30.1367348431597; Tue, 30 Apr 2013 12:00:31 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 12:00:31 -0700 (PDT) In-Reply-To: <517FFB7E.8050801@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@alum.mit.edu> Date: Tue, 30 Apr 2013 12:00:31 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? 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, 30 Apr 2013 19:00:42 -0000 On 30 April 2013 10:12, Paul Kyzivat wrote: > What are the implications of *not* mandating it? I'm more interesting in learning why someone might want to split it out. I can't see any reason for doing that... ...that is, except perhaps for some of the fictitious attacks I invent when someone suggests that RTCP is a good place for a security mechanism of one sort or other. From pkyzivat@alum.mit.edu Tue Apr 30 12:30: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 BDAAD21F984B for ; Tue, 30 Apr 2013 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 9en0DpbmT-pR for ; Tue, 30 Apr 2013 12:30:08 -0700 (PDT) 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 AF50D21F9A89 for ; Tue, 30 Apr 2013 12:30:06 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id WAg11l0050bG4ec51KW66E; Tue, 30 Apr 2013 19:30:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id WKW61l00g3ZTu2S3PKW6P9; Tue, 30 Apr 2013 19:30:06 +0000 Message-ID: <51801BBD.1010505@alum.mit.edu> Date: Tue, 30 Apr 2013 15:30:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se> <517FFB7E.8050801@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=1367350206; bh=/yaCZR4SQD5hGEpDCGOYDu4SHoPemwoaeiuA93W3ngs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UKH7GTTKxOKPyydGR6h2TwuLXCQjgPPgsB1eF5eOn4JV2jj8+dsfyETdA7EEHvCUD EjztOk8utV6y/rnx32TYFrmH6DcijAUDjTiIeY0PiRbdqFTdK2ZXvlulZJ1r5Gnz9u pa/HD9rPqfPa15uG/Yp5OgWlK5DeCAI36ThZEo+IrlGW+nqwkKTc/a9bLpCOzY6F77 if6umH/Gsa2QU9W988a6ctFT8V35MJ8RIyTGAHCvbCD/2kK79oHHhqCTtK9z/2HTeC GG4Iv01PEh/9NElRCTxvtCdiR3WlyIuBIeTY8bk5Tmtj/m1bXzK3r2mxYuXBbEi4Lw 27TvoejRKjjbw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing? 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, 30 Apr 2013 19:30:13 -0000 On 4/30/13 3:00 PM, Martin Thomson wrote: > On 30 April 2013 10:12, Paul Kyzivat wrote: >> What are the implications of *not* mandating it? > > I'm more interesting in learning why someone might want to split it > out. I can't see any reason for doing that... > > ...that is, except perhaps for some of the fictitious attacks I invent > when someone suggests that RTCP is a good place for a security > mechanism of one sort or other. Well, IIUC it was separate before there was a way to combine them. Why was that? Why hasn't separate RTCP gone away entirely? Thanks, Paul