From csp@csperkins.org Mon Jul 1 02:56: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 A068A21F8ECE for ; Mon, 1 Jul 2013 02:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=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 F924IgyYt3+f for ; Mon, 1 Jul 2013 02:55:57 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2E72B21F8DDD for ; Mon, 1 Jul 2013 02:55:57 -0700 (PDT) Received: from [130.209.247.112] (port=63444 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Utapm-0004Gs-CN; Mon, 01 Jul 2013 10:55:56 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <51CF00F4.4050605@alum.mit.edu> Date: Mon, 1 Jul 2013 10:55:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8043C1C0-E284-4F81-AC5D-4FE359F1AE46@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> <51CF00F4.4050605@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2013 09:56:04 -0000 On 29 Jun 2013, at 16:44, Paul Kyzivat wrote: > On 6/29/13 8:44 AM, Colin Perkins wrote: >> On 26 Jun 2013, at 13:20, Christer Holmberg wrote: >>> Hi Colin, >>>=20 >>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP = data to m- lines should be based on PT. Applications are >>>>> allowed to use whatever other mechanisms, but usage of such = mechanisms must be negotiated (or, applications need to have >>>>> some other means knowing that the other endpoint support such = mechanisms). >>>>>=20 >>>>> Q3: Do we need to specify a default, MTI, mechanism for mapping = RTP data to m- lines? >>>>=20 >>>> I think the BUNDLE specification needs to define how RTP flows can = be associated with m=3D lines, but ought not mandate that applications >>>> do so. The document that describes how WebRTC uses BUNDLE might = want to mandate that WebRTC applications use the mechanism. >>>=20 >>> Note that there is a separate discussion, BUNDLE DISCUSION: Always = mandate mechanism to map received data to m- line?, on whether BUNDLE = shall mandate that the receiver must always be able to map received data = to an m- line. >>>=20 >>> So far only Paul has commented on that discussion, but I assume it's = just a question of hours before your input will be posted? :) >>>=20 >>>>> Q4: If Q3, do we mandate applications to support, and use (unless = applications are made aware of other mechanisms supported by all = endpoints) PT for mapping received RTP media? >>>>=20 >>>> I think we should specify how the combination of PT values and = a=3Dssrc: lines can be used to associate RTP data with m=3D lines, for = applications that want to do so. >>>>=20 >>>> I don't think just using PT values is sufficient, since the PT = space is small (I can imagine applications that want to send lots of = flows using >>>> the same codec configuration, and it's more natural to give them = all the same PT and use a=3Dssrc: lines to distinguish). >>>=20 >>> If you run out of PTs, and have to re-use the same PT in multiple m- = lines (for the same codec configuration, though), you will obviously = need something else for mapping RTP to m- lines, and we should probably = state that. >>>=20 >>> But, my take from your reply is that you don't think we should = specify a default mechanism. We CAN describe different mechanisms (PT, = PT+SSRC etc), but it would be up to applications to decide what to use. = Correct? >>=20 >>=20 >> No. >>=20 >> Specifying a "default" suggests that there might be alternative ways = of doing this. If we specify an algorithm for mapping RTP flows to m=3D = lines, we should specify a single algorithm. We don't need multiple ways = of doing this. I think that single algorithm should look at the PT and = the a=3Dssrc: lines. Just looking at the PT isn't sufficient. >=20 > But we *will* have alternative ways of doing this: >=20 > - one way is by SSRC, specifying which SSRC goes to which m-line >=20 > - another way could be by appid (from Roni's new draft) >=20 > The only thing that is special about PT is that *every* RTP media = section contains PTs, so it is always available to be used. Every RTP packet contains an SSRC, so that's always available to use = too. You may not chose to use it, but it seems strange to ignore it. Colin > If I want to use appid, I may very well *not* want to use ssrc as = well. I may want the same ssrc to associate with *different* m-lines in = the bundle depending on which appid it has. >=20 > And in that case I may well not want to use PT either. >=20 > Thanks, > Paul >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Mon Jul 1 04:40: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 0313221F9C47 for ; Mon, 1 Jul 2013 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, J_CHICKENPOX_44=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 ZwjaiCFjNkAl for ; Mon, 1 Jul 2013 04:40:35 -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 D762521F9AC1 for ; Mon, 1 Jul 2013 04:40:34 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so3055034wev.8 for ; Mon, 01 Jul 2013 04:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=GjTMl+5Y2movtRXzCzs1PZgT0PasNDCxFl4Cc88NPmU=; b=WG0g0Dd+Lg0MIkIamrzp8bEn12ZiTewOPZNwB+ndzP2YLnOmG/YSiwF6eG38zXnLJI sNNtD+EY5gwHHdWpAHzi29ihlB0M/2IEayLkqWbSoidVqmRLha20sICSNKjB2UTRJ1YM pVXg0/C5qfUvJedaw6cixbRDCEshybsVYz9dqKx1C53e6IgVkihDOLLY1mDGImRW7jKW HjrY0nWTmv3zVh/nElWWA20sle7rGg69K8q2w0/iDiEW0RyFwHtcXDoUBa4SeFXF9jfH bqYgQCUxzUImMzmBkgOP+M7POAHtzN2LucLk+vWRnRh1sAOGNhiyAlXyIpGYRRKoFjmr xPUg== X-Received: by 10.180.208.7 with SMTP id ma7mr11872565wic.11.1372678833811; Mon, 01 Jul 2013 04:40:33 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id nb12sm15694251wic.7.2013.07.01.04.40.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Jul 2013 04:40:33 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> <047901ce7552$de032840$9a0978c0$@gmail.com> <51D0569C.3020508@alum.mit.edu> In-Reply-To: <51D0569C.3020508@alum.mit.edu> Date: Mon, 1 Jul 2013 14:38:59 +0300 Message-ID: <051301ce764f$95a89370$c0f9ba50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeUlghD62FOWC7Z8hplVA8xNyLagHaS0jkAkLxBloCOy5ymwJnxbPBmmn20CA= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 11:40:36 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 30 June, 2013 7:03 PM > To: Roni Even > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > mmusic-application-token-00.txt > > On 6/30/13 1:29 AM, Roni Even wrote: > > Inline > > > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 29 June, 2013 6:59 PM > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > >> mmusic-application-token-00.txt > >> > >> I looked this over, and it seems to solve many of the issues at hand. > >> There are no doubt some nits to iron out, but we should get agreement > >> over the concepts before worrying too much about the details. > >> > >> A couple of things I wanted to comment on: > >> > >> You give examples of form: > >> a=ssrc:11111 AppID:1 > >> But you don't say too much about the meaning of this. The reason I > >> ask is that you say elsewhere that the appid can move from one ssrc to > another. > >> My question is: If this form is used, can that appid later be bound > >> to a different ssrc via the header extension? Also, is the following legal? > >> a=ssrc:11111,22222 AppID:1 > > [Roni Even] The AppID can be mapped later using SDES or header > > extension to a new SSRC and our view is that this is a replacement. An > > AppID can be mapped to a single SSRC at a time. > > OK. That's fine, but then I think the draft should say more about it. [Roni Even] In section 3 there is the following text " Each value of the AppID maps to one SSRC at a time. When a new SSRC is mapped to an existing AppID using an RTP header extension or SDES message, it replaces the previous RTP stream for this application usage." > > Also, a followup question: > > Suppose I start with an offer with > > a=ssrc:11111 AppID:1 > > and then use SDES or header extension to change move AppID 1 to ssrc > 22222. > > If there is then another O/A, with the same SDP as before: > > a=ssrc:11111 AppID:1 > > Does that change the mapping back to 11111, or does it stay as 22222? > > This impacts how closely the SDP signaling must be coupled to the media > processing. [Roni Even]This needs clarification in the previous text. If the mapping is changed using SDES or RTP header it is the current mapping so if a new offer is sent it should use the current SSRC mapping. > > > We looked at having more than one SSRC mapped to a single AppID and > > decided to leave it to discussion. It will require to distinguish > > between adding and SSRC and replacing an SSRC when a new mapping is > specified. > > My view is that the unique mapping is clearer and I assume we can look > > at using SDP grouping if want to associate two RTP media streams to an > > application usage. > > I asked about > > a=ssrc:11111,22222 AppID:1 > > just because it seemed to be allowed by the syntax. My next question would > be what it means. E.g, it *could* mean that it is expected that > 11111 and 22222 may both be used, but won't be used simultaneously. If it > turned out that they *were* used simultaneously, then the effect would be > to switch rapidly between them. [Roni Even] We have a problem in the syntax. We did not mean to allow mapping two SSRCs to the same AppID. The usage for the syntax was to allow a preannounce of AppIDs for example "a=appID:2,3" to allow them to be used later in SDES or RTP header and know to which m-line they correspond. So we will need to change the syntax. > > Thanks, > Paul > > > Roni > > > >> > >> My other issue is with: > >> In the CLUE WG case the mapping is from an RTP stream to a CLUE > media > >> capture specified in the CLUE framework [I-D.ietf-clue-framework]. > >> This should be to a CLUE capture-encoding. > > [Roni Even] OK, will fix it > >> > >> Thanks, > >> Paul > >> > >> On 6/28/13 11:54 AM, Roni Even wrote: > >>> Hi, > >>> We have submitted this document that defines a mechanism to provide > >> the mapping between the > >>> SSRCs of RTP streams and the application semantics by defining > >> extensions to RTP and RTCP messages. > >>> > >>> It defines a new SDP attribute, RTCP SDES message and RTP header > >> extension for this puropose. The document explains how it can be used > >> with the different multiplexing proposal (Plan A, Plan B and no plan). > >>> > >>> It can be used also in CLUE to map SSRCs to Clue media capture. > >>> > >>> Please review and send comments > >>> Thanks > >>> Roni Even > >>> > >>> ________________________________________ > >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] > >>> Sent: Friday, June 28, 2013 6:27 PM > >>> To: Jonathan Lennox; Qin Wu; Roni Even > >>> Subject: New Version Notification for draft-even-mmusic-application- > >> token-00.txt > >>> > >>> A new version of I-D, draft-even-mmusic-application-token-00.txt > >>> has been successfully submitted by Roni Even and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-even-mmusic-application-token > >>> Revision: 00 > >>> Title: The Session Description Protocol (SDP) Application > > Token > >> Attribute > >>> Creation date: 2013-06-28 > >>> Group: Individual Submission > >>> Number of pages: 11 > >>> URL: http://www.ietf.org/internet-drafts/draft-even-mmusic- > >> application-token-00.txt > >>> Status: http://datatracker.ietf.org/doc/draft-even-mmusic- > >> application-token > >>> Htmlized: > > http://tools.ietf.org/html/draft-even-mmusic-application- > >> token-00 > >>> > >>> > >>> Abstract: > >>> The RTP fixed header includes the payload type number and the SSRC > >>> values of the RTP stream. RTP defines how you de-multiplex streams > >>> within an RTP session, but in some use cases applications need > >>> further identifiers in order to identify the application semantics > >>> associated with particular streams within the session. > >>> > >>> This document defines a mechanism to provide the mapping > >>> between > >> the > >>> SSRCs of RTP streams and the application semantics by defining > >>> extensions to RTP and RTCP messages. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > From palmarti@cisco.com Mon Jul 1 05:03: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 606E221F9F38 for ; Mon, 1 Jul 2013 05:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.409 X-Spam-Level: X-Spam-Status: No, score=-8.409 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 IxiztJR4aTvY for ; Mon, 1 Jul 2013 05:03:12 -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 62CBE21F9CE2 for ; Mon, 1 Jul 2013 05:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7912; q=dns/txt; s=iport; t=1372680192; x=1373889792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SGlRco4mqnJV70wJlTWM/pDHu9rtNGoq1jHLIOX/Yc0=; b=dc+iMreLddTjGFXt+uXy/64a5NMUVBX/rKX36fvSpPiGaThTznyaJ1fL mwWdjGl8xAF02jR9/osMpYyg29tboMVdRe4itdpzh8ZTOd2sehDAMyTGc dB3MxF88lU4zJBeu/xK6Mpr5JksOJ+7JY430HGw/ZSpa6lceai0uyZLij 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAORu0VGtJV2Z/2dsb2JhbABagwkySb8YfhZ0giMBAQEDAQEBAWQEAwsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgTh24GDLtBBI8rAjEHBoJ+YwOIa4sLlReDEYIo X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208";a="229199443" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jul 2013 12:03:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r61C3BTT024999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 12:03:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 07:03:10 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: Application to Network Communication Thread-Index: AQHOcxFK/cjz0kpmD0WIIaQKdosnb5lJTrRAgAG89ACAAABJEIAAa/0AgAA8kYCABF8jgA== Date: Mon, 1 Jul 2013 12:03:10 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB11429A9C@xmb-rcd-x06.cisco.com> References: <1373AC9C23D80E44856F5CF6F883ACAB11425F93@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BC594@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB11426E0B@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BE5EA@ESESSMB209.ericsson.se> <1373AC9C23D80E44856F5CF6F883ACAB114289C4@xmb-rcd-x06.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3BEA73@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BEA73@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.94] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <25CEACF8872B154DB3D7B11F61620EF2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Application to Network Communication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2013 12:03:18 -0000 On Jun 29, 2013, at 24:27 AM, Christer Holmberg wrote: > Hi, >=20 >>> I guess my questions will be answered once I read the draft, but I'll a= sk a couple of high-level questions at this point anyway :) >>=20 >> I am afraid that the draft will open up for more questions than answers.= ;-) >=20 > Well, at least it's good if the questions come before the draft is publis= hed as RFC :) >=20 >>> Q1: How will you associate the STUN requests with a given media flow? I= f your answer is based on IP address:port, do you=20 >>> then assume that there will be only a single flow= per IP address:port? >>>=20 >>=20 >> The STUN messages are sent on the same 5-tuple as media, so the metadata= in the STUN packets needs to describe whatever is being sent on that 5-tup= le. >>=20 >> Introducing BUNDLE into this is interesting. But again I think that is u= p to what the metadata want to describe. If audio and video is flowing on t= he same 5-tuple, that needs to be described.=20 >=20 > BUNDLE is one case, but there are also discussions about sending multiple= media flows of the same media type, separated by SSRC, on the same 5-tuple= . The SDP a=3Dssrc attribute might be enough to signal that, so you wouldn'= t need BUNDLE. That is true. Thanks for the pointer. We some text around multiplexing scen= arios and the problems associated with it. >=20 >>> Q2: You say that the network will provide information using STUN reques= ts. Will the network piggyback information in the STUN requests sent by the= ICE endpoints, or will the network generate their own STUN requests? >>>=20 >> Piggyback. The plan is to add attributes the network elements can write = information into. That might save some mallocs on the network side.=20 >=20 > Keep in mind that if one endpoint is ICE lite, it won't send any STUN con= nectivity check requests (only responses) or keep-alives. That might not be= an issue in UA-to-UA scenarios, where both ICE endpoints are typically ful= l ICE.=20 >=20 > But, if one ICE endpoint is located within the network it will often be I= CE lite. Now, I don't think you would have to mandate those to become full = ICE, but I guess they at least would need to send keep-alives, in order to = allow piggybacking of data in both directions. >=20 Yes. For now we are focusing on solving two problems, how to get better tre= atment of flows in the network and how to improve ICE path selection. To so= lve both of these in the ICE-lite scenario I think we need to introduce a M= ALICE-light version that does what you describe above (Send some conn check= s and answer checks with reflected metadata attributes.) Will post the draft later today. .-. P=E5l-Erik > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 >> Sent: 28. kes=E4kuuta 2013 10:13 >> To: Christer Holmberg >> Cc: mmusic >> Subject: Re: Application to Network Communication >>=20 >>=20 >> On Jun 27, 2013, at 11:42 AM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> I am not really sure what you mean by "how network should treat differe= nt streams". >>>=20 >>> What kind of network entities are you referring to, and what kind of tr= eatment? >>>=20 >>=20 >> Routers, switches, firewalls, NATs, ALGs, SBCs, B2Bs. And a few acronyms= I probably don=B4t know exist. In short any device in the network that rig= htfully or not is or inserts itself in the media path.=20 >>=20 >> The name of the draft that currently is being drafted is MALICE (Metadat= a Attribute signaLing with ICE). The basic idea is to signal a set of descr= iptive metadata attributes in some of the STUN messages that are sent when = an agent does ICE. The way STUN is crafted makes it easy for network entiti= es to distinguish the STUN metadata packets and act on the information.=20 >>=20 >> One of the short term use cases this can solve is the problem where DSCP= markings can be lost when the packet crosses administrative domains. If me= tadata is sent in-band with STUN it can for instance describe this stream a= s video. If SRTP is in use it would be hard/impossible for any network enti= ty to know that the stream is video without this in-band metadata. So if ne= twork A and B want to treat video differently by having their own DSCP mark= ings they can now do this.=20 >>=20 >> MALICE tries to just be a framework for sending the metadata, thus enabl= ing application to network communication. It also tries to describe how rou= ters can add useful information to the metadata packets, and how that infor= mation can be sent back to the application without relying on address spoof= ing or opening up for multiplying attacks. This opens up for network to app= lication communication. Like ECN, but more descriptive and it works on more= platforms. (I am no expert n the area, but I am under the impression that = it is difficult to get the complete IP header up to the application on some= platforms) >>=20 >> This can be used in a multitude of ways; Optimising the ICE path selecti= on based on actual network feedback, making it easier for video application= to choose the correct starting bandwidth, can enable better down/and up sp= eeding of video streams. Hopefully there are a lot of other use cases as we= ll.=20 >>=20 >> I don=B4t expect this to be an easy problem to solve. So for now I think= the big question is: >> "Is it worthwile trying to come up with machanisms that enable better ap= plication to/from network communication?" >>=20 >> .-. >> P=E5l-Erik >>=20 >>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f Of Pal Martinsen (palmarti) >>> Sent: 27. kes=E4kuuta 2013 11:36 >>> To: mmusic >>> Subject: [MMUSIC] Application to Network Communication >>>=20 >>> Hi All, >>>=20 >>> We see a need for better application to network communication to convey= how the network should/could treat the different streams described in the = medalines of the SDP. This is especially important as video codecs have bec= ome very elastic regarding network bandwidth. It would be useful for the ne= twork to know the nature regarding the usage of the video stream. The netwo= rk could treat the stream very differently whatever it is realtime video re= quiring low latency and high bandwidth or is it a more static presentation = flow carrying a slideshow. Getting information from the network to the appl= ication can also prove to be useful. >>>=20 >>> Todays existing solutions can be difficult to implement on some devices= as the information is carried in the IP header or the markings in the pack= ets is ignored across administrative domains. Other solution treats the net= work as a black box and tries to fix problems when they are discovered. Bot= h the network and the application would benefit if information regarding th= ings that is about to happen as opposed to just happened could be conveyed. >>>=20 >>> We are considering extending ICE connectivity checks and keepalives (ST= UN) to provide this communication from the endpoint to the network and from= the network to the endpoint. >>>=20 >>> Are other folks seeing this problem as well, or are existing techniques= and throwing bandwidth at the problem sufficient today and sufficient tomo= rrow? >>>=20 >>> Any comments, feedback and ideas are very welcome. >>>=20 >>> Regards >>> P=E5l-Erik Martinsen >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 From pkyzivat@alum.mit.edu Mon Jul 1 10:03: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 E7E4C11E823B for ; Mon, 1 Jul 2013 10:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.107 X-Spam-Level: X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=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 twDO3t9yFB2X for ; Mon, 1 Jul 2013 10:03:01 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 0649121F9E39 for ; Mon, 1 Jul 2013 10:02:59 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id uzjm1l00427AodY5752zY2; Mon, 01 Jul 2013 17:02:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id v52z1l00T3ZTu2S3f52zB5; Mon, 01 Jul 2013 17:02:59 +0000 Message-ID: <51D1B642.8080608@alum.mit.edu> Date: Mon, 01 Jul 2013 13:02:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> <047901ce7552$de032840$9a0978c0$@gmail.com> <51D0569C.3020508@alum.mit.edu> <051301ce764f$95a89370$c0f9ba50$@gmail.com> In-Reply-To: <051301ce764f$95a89370$c0f9ba50$@gmail.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=1372698179; bh=p30E9EpghCunuA6pRhIARGBaLJzne2Ni+watsFRurqg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Eab7/YUOxv0iHmjKoXZIUhTNWDYPmeyf3Up6olInnA0LRd33F8meTuDuTSYt8Ad8S X4cQVCRXZM4pz4X0WaCv5DklF7xjG9r87b0jbUkWcNcSBxOwq9x9Lcs/BSC0t2MB+h tJc/WN39QKz66cZl5zUuZOjI1Ho+VKWHgXdPmRQ5uDBZpi75im/B6lYpWwaWpU9OKl ZXXA9f8n/5uW6iqklCJHym+L939Z5LPJBTg/eF/O+Lt3q8DS8ORijFd7JkHCeh5I0F UFj8VriS+f7+44hEiaK7YzbyVhO9GLn+IjIpIAM/KPrjY/6BrUMzFdHIRQO16T/f6L KzA1TxNI/jOPw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:03:07 -0000 Hi Roni. See inline. On 7/1/13 7:38 AM, Roni Even wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 30 June, 2013 7:03 PM >> To: Roni Even >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- >> mmusic-application-token-00.txt >> >> On 6/30/13 1:29 AM, Roni Even wrote: >>> Inline >>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 29 June, 2013 6:59 PM >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- >>>> mmusic-application-token-00.txt >>>> >>>> I looked this over, and it seems to solve many of the issues at hand. >>>> There are no doubt some nits to iron out, but we should get agreement >>>> over the concepts before worrying too much about the details. >>>> >>>> A couple of things I wanted to comment on: >>>> >>>> You give examples of form: >>>> a=ssrc:11111 AppID:1 >>>> But you don't say too much about the meaning of this. The reason I >>>> ask is that you say elsewhere that the appid can move from one ssrc to >> another. >>>> My question is: If this form is used, can that appid later be bound >>>> to a different ssrc via the header extension? Also, is the following > legal? >>>> a=ssrc:11111,22222 AppID:1 >>> [Roni Even] The AppID can be mapped later using SDES or header >>> extension to a new SSRC and our view is that this is a replacement. An >>> AppID can be mapped to a single SSRC at a time. >> >> OK. That's fine, but then I think the draft should say more about it. > > > [Roni Even] In section 3 there is the following text > " Each value of the AppID maps to one SSRC at a time. When a new SSRC > is mapped to an existing AppID using an RTP header extension or SDES > message, it replaces the previous RTP stream for this application > usage." It still isn't clear to me. You have three ways to communicate the mapping: - SDP - SDES - header extension I think the relationship and precedence between SDES and header extension is well defined in general, so I guess that doesn't need further elaboration. But the relationship between the SDP and the RTP/RTCP mechanisms isn't so clear. This is especially problematic because it is impossible to synchronize the arrival of SDP with the arrival of RTP/RTCP. The simplest answer would be to use the SDP as a *default* if the mapping hasn't been received in the media, with changes in the SDP having no effect on the mapping of a particular AppId once it has been mentioned in the media. But I don't know if that is a sufficient mechanism. Alternatively, the mapping can be defined by whichever has been received most recently. But that may cause artifacts. I just think this needs to be made very clear. >> Also, a followup question: >> >> Suppose I start with an offer with >> >> a=ssrc:11111 AppID:1 >> >> and then use SDES or header extension to change move AppID 1 to ssrc >> 22222. >> >> If there is then another O/A, with the same SDP as before: >> >> a=ssrc:11111 AppID:1 >> >> Does that change the mapping back to 11111, or does it stay as 22222? >> >> This impacts how closely the SDP signaling must be coupled to the media >> processing. > [Roni Even]This needs clarification in the previous text. If the mapping is > changed using SDES or RTP header it is the current mapping so if a new offer > is sent it should use the current SSRC mapping. See comments above. >>> We looked at having more than one SSRC mapped to a single AppID and >>> decided to leave it to discussion. It will require to distinguish >>> between adding and SSRC and replacing an SSRC when a new mapping is >> specified. >>> My view is that the unique mapping is clearer and I assume we can look >>> at using SDP grouping if want to associate two RTP media streams to an >>> application usage. >> >> I asked about >> >> a=ssrc:11111,22222 AppID:1 >> >> just because it seemed to be allowed by the syntax. My next question would >> be what it means. E.g, it *could* mean that it is expected that >> 11111 and 22222 may both be used, but won't be used simultaneously. If it >> turned out that they *were* used simultaneously, then the effect would be >> to switch rapidly between them. > [Roni Even] We have a problem in the syntax. We did not mean to allow > mapping two SSRCs to the same AppID. The usage for the syntax was to allow a > preannounce of AppIDs for example "a=appID:2,3" to allow them to be used > later in SDES or RTP header and know to which m-line they correspond. So we > will need to change the syntax. OK. So if the intent is not to allow it, then sure, the syntax can be tweaked so it isn't possible to say it. Thanks, Paul From iesg-secretary@ietf.org Mon Jul 1 11: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 7F6EC11E823B; Mon, 1 Jul 2013 11: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=[AWL=0.000, 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 Gnl8fjWZ10Bg; Mon, 1 Jul 2013 11:56:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3F11E8234; Mon, 1 Jul 2013 11:56:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 11:56:23 -0700 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:56:24 -0000 The IESG has approved the following document: - 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ *Technical Summary * The document 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 Publich Switched Telephone Network (PSTN) *Working Group Summary * The WG had some discussion around the format to use for E.164 numbers and whether to align this with the existing definition in RFC 3108. The RFC 3108 definition was seen as deficient and the WG agreed it was better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a particular network type, and hence RFC 3108 compatibility is not a concern (the implication is that the "E164" address type may differ between network types in SDP). *Document Quality * There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. The document has received good overall review in the WG, some of which resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel * Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo From pkyzivat@alum.mit.edu Mon Jul 1 17:27: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 ECBBD11E8376 for ; Mon, 1 Jul 2013 17:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_24=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 GfYcqGvhzvXO for ; Mon, 1 Jul 2013 17:27:15 -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 2ACFF11E8347 for ; Mon, 1 Jul 2013 17:27:15 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id v73B1l0060cZkys5DCTE5B; Tue, 02 Jul 2013 00:27:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id vCTE1l00F3ZTu2S3WCTE4D; Tue, 02 Jul 2013 00:27:14 +0000 Message-ID: <51D21E61.80207@alum.mit.edu> Date: Mon, 01 Jul 2013 20:27:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se> <6181387D-36CA-470A-8E94-09AF90F4B9FD@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3BBB7A@ESESSMB209.ericsson.se> <51CF00F4.4050605@alum.mit.edu> <8043C1C0-E284-4F81-AC5D-4FE359F1AE46@csperkins.org> In-Reply-To: <8043C1C0-E284-4F81-AC5D-4FE359F1AE46@csperkins.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=1372724834; bh=N/FFt5Rj1E+MRipcDJh2e/OR0zomwOX0D7uOWNJR4pI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fRGO3/YLlJltMj3umVYfX4zf89oTzpT8n13/z2syVce9NNdzkjovH46tK5vjrMsA2 z+ydXuQJAE9iGk0DBE5k59s+FiHbUQuu3LuTODGtbASsTXXhCPN/GywDUulAlj5ASM TKkUYQghXKrDjx0MHVsiopEV8CX/8ojZ+1lNywKQr4J/t/Hh+ftfTDPwRqLeXsEHWc zsRWDWJrBpGOUa9lr5zBP9AS4mc/IFq/+VP4/GEKPDnZEgXWhMVzxn5I3MUB09Q7/f 0++jNeUKdYYaokeI8pT/ciZkQrSjxK8Ygeo9BjIFULwLeGrFkRWoKNLROCq1QnTZdn CgBjcrTrxg9qQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 00:27:20 -0000 On 7/1/13 5:55 AM, Colin Perkins wrote: > On 29 Jun 2013, at 16:44, Paul Kyzivat wrote: >> On 6/29/13 8:44 AM, Colin Perkins wrote: >>> On 26 Jun 2013, at 13:20, Christer Holmberg wrote: >>>> Hi Colin, >>>> >>>>>> Emil suggested that the default, "MTI", mechanism for mapping RTP data to m- lines should be based on PT. Applications are >>>>>> allowed to use whatever other mechanisms, but usage of such mechanisms must be negotiated (or, applications need to have >>>>>> some other means knowing that the other endpoint support such mechanisms). >>>>>> >>>>>> Q3: Do we need to specify a default, MTI, mechanism for mapping RTP data to m- lines? >>>>> >>>>> I think the BUNDLE specification needs to define how RTP flows can be associated with m= lines, but ought not mandate that applications >>>>> do so. The document that describes how WebRTC uses BUNDLE might want to mandate that WebRTC applications use the mechanism. >>>> >>>> Note that there is a separate discussion, BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?, on whether BUNDLE shall mandate that the receiver must always be able to map received data to an m- line. >>>> >>>> So far only Paul has commented on that discussion, but I assume it's just a question of hours before your input will be posted? :) >>>> >>>>>> Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media? >>>>> >>>>> I think we should specify how the combination of PT values and a=ssrc: lines can be used to associate RTP data with m= lines, for applications that want to do so. >>>>> >>>>> I don't think just using PT values is sufficient, since the PT space is small (I can imagine applications that want to send lots of flows using >>>>> the same codec configuration, and it's more natural to give them all the same PT and use a=ssrc: lines to distinguish). >>>> >>>> If you run out of PTs, and have to re-use the same PT in multiple m- lines (for the same codec configuration, though), you will obviously need something else for mapping RTP to m- lines, and we should probably state that. >>>> >>>> But, my take from your reply is that you don't think we should specify a default mechanism. We CAN describe different mechanisms (PT, PT+SSRC etc), but it would be up to applications to decide what to use. Correct? >>> >>> >>> No. >>> >>> Specifying a "default" suggests that there might be alternative ways of doing this. If we specify an algorithm for mapping RTP flows to m= lines, we should specify a single algorithm. We don't need multiple ways of doing this. I think that single algorithm should look at the PT and the a=ssrc: lines. Just looking at the PT isn't sufficient. >> >> But we *will* have alternative ways of doing this: >> >> - one way is by SSRC, specifying which SSRC goes to which m-line >> >> - another way could be by appid (from Roni's new draft) >> >> The only thing that is special about PT is that *every* RTP media section contains PTs, so it is always available to be used. > > Every RTP packet contains an SSRC, so that's always available to use too. You may not chose to use it, but it seems strange to ignore it. The think about PT is that it is guaranteed to be in the SDP. There are lots of things in the RTP, but most of them are sometimes, or usually, not in the SDP. While we have a way of putting SSRC into the SDP, we have heard much discussion of cases where the SSRC values aren't known at the time the SDP is sent. The AppId draft, if it progresses, will provide another way. That makes three mechanisms. We *could* define an *algorithm* for mapping that is based on the sometimes presence of some or all of these in the SDP. But then I think it may need to be extensible for new attributes that might be used for this. I did specify an abstract algorithm of this sort in an earlier reply. (I suspect we aren't in fundamental disagreement. We are probably just talking about this is very different ways. For me the fundamental point is that a valid O/A must always define (perhaps implicitly) the algorithm to do the association.) Thanks, Paul > Colin > >> If I want to use appid, I may very well *not* want to use ssrc as well. I may want the same ssrc to associate with *different* m-lines in the bundle depending on which appid it has. >> >> And in that case I may well not want to use PT either. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From ron.even.tlv@gmail.com Tue Jul 2 05:33: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 0FE3B21F9EC0 for ; Tue, 2 Jul 2013 05:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, J_CHICKENPOX_44=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 8xP55BX2iCYr for ; Tue, 2 Jul 2013 05:33:48 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9C21F9EBF for ; Tue, 2 Jul 2013 05:33:47 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so4349380wes.34 for ; Tue, 02 Jul 2013 05:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=6ikk+cMfTEeXSzSHUhwiZYbTOH+zAH7czoO3ApYd0O8=; b=vM4PaJBM+mKV2g/IDBXHb19mxdeoiVbQYpYpmyqbD82P0UhI73usaP/LEWfbDW1kV6 nNn97X1dk89ufnT7VR3dF6VAVcQ6WdohC8/n0XxXMRCK/voDt65s+FP0sQzCyRboAOuG KZmd3jmbQ6IL8tcYE4UubPHknxkvXE3l0MAuC3jEUqpP9p+AlVjZyI893A96yNVi7GqG CHEpKDujAzd6aQh9YjnwdghM0SGGYjG+oBpkyr3x5kfBGD33pFMll3ZktO+hjUXAf5rY ebEJl3Zq6M6PvBLDQfRdNW22Ry649x0W3bo91rEtsnJoIH+oLahSRX0CDe9Ppy/QYeaq lYRg== X-Received: by 10.194.103.226 with SMTP id fz2mr23204672wjb.75.1372768426956; Tue, 02 Jul 2013 05:33:46 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id s19sm22574138wik.11.2013.07.02.05.33.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Jul 2013 05:33:36 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> <047901ce7552$de032840$9a0978c0$@gmail.com> <51D0569C.3020508@alum.mit.edu> <051301ce764f$95a89370$c0f9ba50$@gmail.com> <51D1B642.8080608@alum.mit.edu> In-Reply-To: <51D1B642.8080608@alum.mit.edu> Date: Tue, 2 Jul 2013 15:32:01 +0300 Message-ID: <002201ce7720$28b5e070$7a21a150$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeUlghD62FOWC7Z8hplVA8xNyLagHaS0jkAkLxBloCOy5ymwJnxbPBAalIAbkCHnxnTppNWuLQ Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:33:49 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 01 July, 2013 8:03 PM > To: Roni Even > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > mmusic-application-token-00.txt > > Hi Roni. See inline. > > On 7/1/13 7:38 AM, Roni Even wrote: > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 30 June, 2013 7:03 PM > >> To: Roni Even > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > >> mmusic-application-token-00.txt > >> > >> On 6/30/13 1:29 AM, Roni Even wrote: > >>> Inline > >>> > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: 29 June, 2013 6:59 PM > >>>> To: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even- > >>>> mmusic-application-token-00.txt > >>>> > >>>> I looked this over, and it seems to solve many of the issues at hand. > >>>> There are no doubt some nits to iron out, but we should get > >>>> agreement over the concepts before worrying too much about the > details. > >>>> > >>>> A couple of things I wanted to comment on: > >>>> > >>>> You give examples of form: > >>>> a=ssrc:11111 AppID:1 > >>>> But you don't say too much about the meaning of this. The reason I > >>>> ask is that you say elsewhere that the appid can move from one ssrc > >>>> to > >> another. > >>>> My question is: If this form is used, can that appid later be bound > >>>> to a different ssrc via the header extension? Also, is the > >>>> following > > legal? > >>>> a=ssrc:11111,22222 AppID:1 > >>> [Roni Even] The AppID can be mapped later using SDES or header > >>> extension to a new SSRC and our view is that this is a replacement. > >>> An AppID can be mapped to a single SSRC at a time. > >> > >> OK. That's fine, but then I think the draft should say more about it. > > > > > > [Roni Even] In section 3 there is the following text " Each value of > > the AppID maps to one SSRC at a time. When a new SSRC > > is mapped to an existing AppID using an RTP header extension or SDES > > message, it replaces the previous RTP stream for this application > > usage." > > It still isn't clear to me. You have three ways to communicate the mapping: > > - SDP > - SDES > - header extension > > I think the relationship and precedence between SDES and header extension > is well defined in general, so I guess that doesn't need further elaboration. > > But the relationship between the SDP and the RTP/RTCP mechanisms isn't so > clear. This is especially problematic because it is impossible to synchronize > the arrival of SDP with the arrival of RTP/RTCP. > > The simplest answer would be to use the SDP as a *default* if the mapping > hasn't been received in the media, with changes in the SDP having no effect > on the mapping of a particular AppId once it has been mentioned in the > media. But I don't know if that is a sufficient mechanism. [Roni Even] I think this make sense because the usage of the SDES and RTP header is to allow changes without a new O/A what we need to specify is what should be the SDP in a case when we used mapping to SSRC in the SDP and after using SDES to remap we will have a new O/A. I think that we should not try to synchronize the SDP but maybe add a flag that will say the SEDS / RTP header should be used for the mapping. > > Alternatively, the mapping can be defined by whichever has been received > most recently. But that may cause artifacts. > > I just think this needs to be made very clear. > > >> Also, a followup question: > >> > >> Suppose I start with an offer with > >> > >> a=ssrc:11111 AppID:1 > >> > >> and then use SDES or header extension to change move AppID 1 to ssrc > >> 22222. > >> > >> If there is then another O/A, with the same SDP as before: > >> > >> a=ssrc:11111 AppID:1 > >> > >> Does that change the mapping back to 11111, or does it stay as 22222? > >> > >> This impacts how closely the SDP signaling must be coupled to the > >> media processing. > > [Roni Even]This needs clarification in the previous text. If the > > mapping is changed using SDES or RTP header it is the current mapping > > so if a new offer is sent it should use the current SSRC mapping. > > See comments above. > > >>> We looked at having more than one SSRC mapped to a single AppID and > >>> decided to leave it to discussion. It will require to distinguish > >>> between adding and SSRC and replacing an SSRC when a new mapping is > >> specified. > >>> My view is that the unique mapping is clearer and I assume we can > >>> look at using SDP grouping if want to associate two RTP media > >>> streams to an application usage. > >> > >> I asked about > >> > >> a=ssrc:11111,22222 AppID:1 > >> > >> just because it seemed to be allowed by the syntax. My next question > >> would be what it means. E.g, it *could* mean that it is expected that > >> 11111 and 22222 may both be used, but won't be used simultaneously. > >> If it turned out that they *were* used simultaneously, then the > >> effect would be to switch rapidly between them. > > [Roni Even] We have a problem in the syntax. We did not mean to allow > > mapping two SSRCs to the same AppID. The usage for the syntax was to > > allow a preannounce of AppIDs for example "a=appID:2,3" to allow them > > to be used later in SDES or RTP header and know to which m-line they > > correspond. So we will need to change the syntax. > > OK. So if the intent is not to allow it, then sure, the syntax can be tweaked so > it isn't possible to say it. > > Thanks, > Paul From palmarti@cisco.com Tue Jul 2 05:47: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 94EB321F99FA for ; Tue, 2 Jul 2013 05:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[AWL=1.153, 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 tmKidt-PH1Pi for ; Tue, 2 Jul 2013 05:47:03 -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 5B3E221F9997 for ; Tue, 2 Jul 2013 05:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2074; q=dns/txt; s=iport; t=1372769223; x=1373978823; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lkCQmuMmRPJJ5oyw91g+xFSCzHM0wSTkkcAC+MpwYSQ=; b=L7u1R0Rr3OHmFLRlvZzQxyFHRvqJrvY3HZ5ytFg+vZLVsYX2rp0it963 t0/UjmTEe5qnG2JdfWqwBf3L3toNSYwQvOGWzq0Z9VEMXLFYX8I41MDv7 kcKW+NJJyLeevdKM8WTEfp6jaln/eQS0FzUiQIyoWrLOKPJ5qW7U+cxyv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAI/K0lGtJXG9/2dsb2JhbABagwkySb9NgQAWdIIjAQEBAwF3FAEqVicEGwGIAAYMmz2gNI8pgzxnA4hrkAeQHIMRgig X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229979087" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2013 12:47:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r62Cl0H8025805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jul 2013 12:47:00 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 07:46:59 -0500 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: New Version Notification for draft-martinsen-mmusic-malice-00.txt Thread-Index: AQHOdyI+qhBGDB0+Q0yi69T2gJN+LA== Date: Tue, 2 Jul 2013 12:46:59 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB1142B602@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.61.160.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <01818007EEB07D44BE25F849195C0F66@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] New Version Notification for draft-martinsen-mmusic-malice-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:47:08 -0000 Hi, We submitted a new draft called MALICE today. It is all about smarter appli= cation/network communication. Se abstract for some details. Read the whole = draft to get a lot more details. >=20 > A new version of I-D, draft-martinsen-mmusic-malice-00.txt > has been successfully submitted by Reinaldo Penno and posted to the > IETF repository. >=20 > Filename: draft-martinsen-mmusic-malice > Revision: 00 > Title: Meta-data Attribute signaLling with ICE > Creation date: 2013-07-02 > Group: Individual Submission > Number of pages: 33 > URL: http://www.ietf.org/internet-drafts/draft-martinsen-mmus= ic-malice-00.txt > Status: http://datatracker.ietf.org/doc/draft-martinsen-mmusic-m= alice > Htmlized: http://tools.ietf.org/html/draft-martinsen-mmusic-malice= -00 >=20 >=20 > Abstract: > It can be useful for applications to provide flow metadata > information to on-path devices to influence flow treatment in the > network. Provided that the network is able to provide useful > feedback, this can also influence path selection if an application > have multiple flow paths to choose from. >=20 > This draft describes how this can be achieved by adding metadata to > the STUN packets sent during the ICE connectivity checks or a > slightly modified version of the keep-alive mechanism. Devices on > the media path can use the metadata information to prioritize the > flow, perform traffic engineering, or provide network analytics and > notifications as requested by the endpoints. On-path devices can > append or modify the existing metadata information in the STUN/ICE > messages to enable feedback to other on-path devices or the > applications in both ends of the media session. >=20 > This document describes a framework mechanism for how such metadata > can be transported by STUN when ICE is in use and it covers the > endpoint and on path device processing. The functionality described > here is referred to as MALICE. .-. P=E5l-Erik= From pkyzivat@alum.mit.edu Tue Jul 2 07:05: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 278B721F9D4D for ; Tue, 2 Jul 2013 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=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 9Vexp+Iy2PQF for ; Tue, 2 Jul 2013 07:05: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 5A5D121F9DD0 for ; Tue, 2 Jul 2013 07:05:31 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta14.westchester.pa.mail.comcast.net with comcast id vRQP1l0030SCNGk5ES5XeN; Tue, 02 Jul 2013 14:05:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id vS5X1l0043ZTu2S3VS5X2B; Tue, 02 Jul 2013 14:05:31 +0000 Message-ID: <51D2DE2A.20300@alum.mit.edu> Date: Tue, 02 Jul 2013 10:05:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372773931; bh=miLwS88QpW4ENXaA2xQDAyDC2EG9dWiXvLhcL13jr9E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bMq6N7UjpT8R71QtZG00cuvVkTXblgOPVp6bEQxOqlaMfdYkww/EXY4ndA3Rr8b8e CuHq3T7r9WiB0bOWdPq2lxRQdOmcDHekWXNU+D9KwEVwoV9em4bvOatgwVWVgo97iL AwC7QoXGT+233/p7T7QVdMFYulhDxoid0dpt30ZxdB9hDo1NAZgmP1bTQgxNMEWYnk VzgoaDre2Z/5Fi0UWmWL/9VMJwQ4BIGnyBBua0UNTYTdf1A/aWXqN8SmZAI61gKf0v kdRJSdckk4xm4k9DvZLBoMCoH8U+optotkAWhg7n5R5HlSn+r8bTahYE326HbQ7Iib haPkL842PUURQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:05:37 -0000 On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: > Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology? > > The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan. I'm going to keep asking this question until I get an answer that makes sense: Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping. Thanks, Paul > Mo > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Saturday, June 29, 2013 12:12 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > On 6/29/13 8:50 AM, Colin Perkins wrote: >> Christer, >> >> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed. >>> >>> We haven't had that much discussion about it yet, so I will not ask a DECISION question at this point, but I would really like to get some input from people who have opinions about this :) >> >> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. > > I just replied elsewhere on this. > My opinion turns out to be the exact opposite of yours: we need to > support multiple algorithms, and that all applications should care. > > I won't repeat the stuff about multiple algorithms. > > I will repeat what I have said about the need for being able to associate: > > There must have been *some* reason that two m-lines were used, rather > than just one. Each m-line heads a media section of the SDP that > contains a bunch of declarations. Something must be different in those > two media sections, or else a single media section would have been > enough. Presumably whatever it is that is different is intended to > affect how received packets are processed or interpreted. (If not, again > there is no need for it to be there.) If you can't associate the packet > with the m-line, then you don't know which of the multiple > interpretations to apply to the packet. > > Maybe there is some exception to this, though I haven't come up with > anything. If there is, then I hope someone will call it out. If so, then > the constraint can be tightened. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Jul 2 08:01: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 E839421F9F4A for ; Tue, 2 Jul 2013 08:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.092, 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 4VbjMmaHmFLe for ; Tue, 2 Jul 2013 08:00:55 -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 F370E21F9EEC for ; Tue, 2 Jul 2013 08:00:54 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta09.westchester.pa.mail.comcast.net with comcast id vRpc1l0070ldTLk59T0u3V; Tue, 02 Jul 2013 15:00:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id vT0u1l00e3ZTu2S01T0uJ1; Tue, 02 Jul 2013 15:00:54 +0000 Message-ID: <51D2EB25.7090500@alum.mit.edu> Date: Tue, 02 Jul 2013 11:00:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130630163215.12814.46061.idtracker@ietfa.amsl.com> <51D05E00.3080203@ericsson.com> In-Reply-To: <51D05E00.3080203@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=1372777254; bh=nJZaTdZH76Hqgrfn8+rGLpt4UpmWLMYtle3hJ5mUyIY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=opPGSb7+/uj6zNf75yZnmk666H3OyOVmySkWbLlNt4PfXLgUI65xohG8h2Vdvut1G woO3pvuNrN9dkHVHn60muN8i0+yUE1x7NP+feZRssUYPugCkAIOwQS1g5tUNDMY5F8 Q0hK8t1PCaKJQ+FPk37UhrH1HBAXPLMr9ErXNpFswhh1rPIQHCHiArK1z8/HNBZM96 eBXeuB12uFttBQR6eh6Lm/Ikak2r4doA6+X54Re0rpFBJLQLh91y4OUo+3V/WWfP26 LCMhVeqN0XIoI9BIR29w5DBb9jCsMGpB8NG0shClahCbrBoF08ziTD5hLd/OS9Ag/P dafhoBm05PN6A== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:01:01 -0000 On 6/30/13 12:34 PM, Salvatore Loreto wrote: > Hi there, > > I have produced a new version to address all the comments received on > the mailing list > > Comments, feedback and questions are very well appreciated and requested > > cheers > Salvatore Here are some things that I found. I'm pretty sure some of them have been discussed on the list before. In section 5.1: The sctpmap attribute maps from a port number (as used in an "m=" line) to an encoding name denoting the payload format to be used on top of the SCTP association or the actual protocol running on top of it. While the earlier examples may clarify, this text isn't clear about what "port" means. The m-line contains a field, and a field that has been said to contain an sctp-port. I think this text should reference the field: The sctpmap attribute maps from a number (as used in an "m=" line) to an encoding name denoting the payload format to be used on top of the SCTP association or the actual protocol running on top of it. Also in this section you define as . There is no specification of how/where such things are defined - e.g. a registry. That can't be. In the case of rtpmap, the field from the m-line, plus the from the rtpmap-line form a mime-type that is registered in IANA. Some of the examples suggest that the same approach is intended for sctpmap. But this needs to be clearly specified. If you don't intend to follow this approach, then for the examples (such as T38) to be valid there will need to be definitions of them is whatever registration scheme you propose. Section 9.3: The example shows a=webrtc-DataChannel lines. Are these defined in any rfc or draft? I can't find one. I think you should either use real examples, that are defined somewhere, or else make clear that you are using a hypothetical example. Thanks, Paul From mzanaty@cisco.com Tue Jul 2 09:09: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 5D8B221F854F for ; Tue, 2 Jul 2013 09:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=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 Ri0+SgnmOXq9 for ; Tue, 2 Jul 2013 09:09:06 -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 4E94121F9FD4 for ; Tue, 2 Jul 2013 09:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5861; q=dns/txt; s=iport; t=1372781343; x=1373990943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZGloVzw8GwEH+mFiWPP46b2g9OutibV4ilhjoxYYT4A=; b=YO5flRM78cIW4s4GIasfUiMtjM70cJoAsDOM9WLxcBGx+bwqDJmPGF0N RoKEm6WLu6yUQLjUrxVa0N9BKz0Xrrea1dIv6r0j7FsWjhvwrio/NAvUS N0Jry7ibXwUX38AUxwcNUC6YESq9IDFAj/EpnNmLXOMez4aLBRjP9aXeE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFABv50lGtJV2c/2dsb2JhbABaDoJ7Mkm/ToEDFnSCIwEBAQMBAQEBNzQLBQcEAgEIDgMEAQEBChQJBycLFAkIAgQOBQiIAQYMvCcEjykxBwaCfmcDqQ6BWHs+gig X-IronPort-AV: E=Sophos;i="4.87,981,1363132800"; d="scan'208";a="229813861" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jul 2013 16:09:02 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r62G92Vd008931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 16:09:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 11:09:02 -0500 From: "Mo Zanaty (mzanaty)" To: Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+AgAKxRwD//7wNkA== Date: Tue, 2 Jul 2013 16:09:01 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> In-Reply-To: <51D2DE2A.20300@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.30.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:09:11 -0000 An attempt at "an answer that makes sense". (Just snippets, not full SDP.) m=3Dvideo 10000 RTP/SAVPF 96 a=3Drtpmap:96 H264/90000 a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly No need to map thumbnail packets to specific m-lines, so reuse of PT=3D97 i= s fine. Just render the last 4 thumbnail sources received (in addition to t= he main speaker). You could mandate that PT must be unique to allow unique mapping. =20 You could mandate that multiple m-lines of thumbnails must be combined into= a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. Which do you want to mandate and why? Cheers, Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Tuesday, July 02, 2013 10:06 AM To: Mo Zanaty (mzanaty) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: > Informative descriptions of possible mappings are fine, but nothing norma= tive, please. Some applications won't care about the mapping, and others ma= y care but use a different mapping from those described. The only normative= statement you could make is something like: "If you care about the mapping= , you MUST have a mapping mechanism. You MAY use the mechanism(s) described= here, or some other mechanism." But why mandate such a tautology? > > The assumption below that multiple m-lines always require different m-lin= e-specific processing of the packets also assumes Plan B, i.e. that multipl= e streams with similar processing should always be signaled with a single m= -line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use m= ultiple m-lines even for multiple streams with the same processing. I don't= think we want to force bundle to pick a plan. I'm going to keep asking this question until I get an answer that makes=20 sense: Please explain to me a meaningful situation when there are multiple=20 m-lines in a bundle and there is insufficient information to associate=20 each packet with an m-line. The *point* of plan A is that there be an m-line per "flow", and that=20 the offerer is enumerating the flows. So clearly it knows the mapping.=20 If the answerer isn't capable of doing the same mapping, then the use of=20 plan A has failed. The part that I want to be normative is that an O/A is not valid unless=20 the mapping is possible with the information in the O/A, and that the=20 offerer and the answerer would agree about the mapping of each packet. I=20 don't care if they actually do the mapping, though if they are doing any=20 sensible processing then they will be doing something *equivalent* to=20 the mapping. Thanks, Paul > Mo > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: Saturday, June 29, 2013 12:12 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map r= eceived data to m- line? > > On 6/29/13 8:50 AM, Colin Perkins wrote: >> Christer, >> >> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>> There has been some discussions about whether BUNDLE should mandate tha= t users are mandated to always (no matter what transport protocols are used= in the BUNDLE group) have a mechanism to map received data to an m- line, = or whether it from a generic BUNDLE perspective should be optional - IF the= re would be cases where it's not needed. >>> >>> We haven't had that much discussion about it yet, so I will not ask a D= ECISION question at this point, but I would really like to get some input f= rom people who have opinions about this :) >> >> My opinion: BUNDLE needs to mandate a single algorithm for mapping from = RTP flows to m=3D lines, for those applications that care about such a mapp= ing. I don't think it should mandate that all applications need to care. > > I just replied elsewhere on this. > My opinion turns out to be the exact opposite of yours: we need to > support multiple algorithms, and that all applications should care. > > I won't repeat the stuff about multiple algorithms. > > I will repeat what I have said about the need for being able to associate= : > > There must have been *some* reason that two m-lines were used, rather > than just one. Each m-line heads a media section of the SDP that > contains a bunch of declarations. Something must be different in those > two media sections, or else a single media section would have been > enough. Presumably whatever it is that is different is intended to > affect how received packets are processed or interpreted. (If not, again > there is no need for it to be there.) If you can't associate the packet > with the m-line, then you don't know which of the multiple > interpretations to apply to the packet. > > Maybe there is some exception to this, though I haven't come up with > anything. If there is, then I hope someone will call it out. If so, then > the constraint can be tightened. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Jul 2 11:30: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 2C0BD21F9829 for ; Tue, 2 Jul 2013 11:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.028 X-Spam-Level: X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=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 UBtzJ8Tp3ogS for ; Tue, 2 Jul 2013 11:30:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5967F21F8443 for ; Tue, 2 Jul 2013 11:30:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-fe-51d31c424380 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.E4.06741.24C13D15; Tue, 2 Jul 2013 20:30:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 20:30:26 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkA== Date: Tue, 2 Jul 2013 18:30:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvra6zzOVAg4MqFlOXP2axePFgDpPF ig0HWB2YPf6+/8DkMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlbHgsWTDbuGLf0hPMDYxX NLsYOTkkBEwkZjQ9ZYewxSQu3FvP1sXIxSEkcJhRYlLjT2YIZyGjxMZVXUxdjBwcbAIWEt3/ tEEaRARCJTYs3cACEmYWUJe4ujgIJCwskCzRufIlE0RJisTd/efZIewwiUPN89lAbBYBFYmF G7Yxg9i8Ar4SuxZ+g9p7hkni+ferYA2cQIlfz2eDNTACHff91BqwocwC4hIfDl5nhjhaQGLJ nvNQtqjEy8f/WCFsJYkfGy6xQNTrSdyYOoUNwtaWWLbwNdRiQYmTM5+wTGAUm4Vk7CwkLbOQ tMxC0rKAkWUVI3tuYmZOernhJkZgzBzc8lt3B+OpcyKHGKU5WJTEeTfpnQkUEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwMilwGQuoOzEE7PotmFgWsvVcw8qRapsNtc+f/9ha/Di2pSNnqva 1IMc4hg+XLKy2LJHXObGy1KpilkFPQ3f/CZyZeVt4Okw7tu9Q/Hdv4iH0SYvJrqc+dZt5vb2 h9GPdXsjsqRkxAJu2y+9rFgz2XCCEn8IE8uFfxfrDtodjj1WVjml017yhxJLcUaioRZzUXEi AFmbXk1nAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:30:43 -0000 Hi, I am not Paul, but just to verify that I understand his issue, the question= is: Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line= ? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Mo Zanaty (mzanaty) L=E4hetetty: 2. hein=E4kuuta 2013 19:09 Vastaanottaja: Paul Kyzivat Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map receiv= ed data to m- line? An attempt at "an answer that makes sense". (Just snippets, not full SDP.) m=3Dvideo 10000 RTP/SAVPF 96 a=3Drtpmap:96 H264/90000 a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly m=3Dvideo 10000 RTP/SAVPF 97 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvonly No need to map thumbnail packets to specific m-lines, so reuse of PT=3D97 i= s fine. Just render the last 4 thumbnail sources received (in addition to t= he main speaker). You could mandate that PT must be unique to allow unique mapping. =20 You could mandate that multiple m-lines of thumbnails must be combined into= a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. Which do you want to mandate and why? Cheers, Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, July 02, 2013 10:06 AM To: Mo Zanaty (mzanaty) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: > Informative descriptions of possible mappings are fine, but nothing norma= tive, please. Some applications won't care about the mapping, and others ma= y care but use a different mapping from those described. The only normative= statement you could make is something like: "If you care about the mapping= , you MUST have a mapping mechanism. You MAY use the mechanism(s) described= here, or some other mechanism." But why mandate such a tautology? > > The assumption below that multiple m-lines always require different m-lin= e-specific processing of the packets also assumes Plan B, i.e. that multipl= e streams with similar processing should always be signaled with a single m= -line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use m= ultiple m-lines even for multiple streams with the same processing. I don't= think we want to force bundle to pick a plan. I'm going to keep asking this question until I get an answer that makes sense: Please explain to me a meaningful situation when there are multiple m-lines= in a bundle and there is insufficient information to associate each packet= with an m-line. The *point* of plan A is that there be an m-line per "flow", and that the o= fferer is enumerating the flows. So clearly it knows the mapping.=20 If the answerer isn't capable of doing the same mapping, then the use of pl= an A has failed. The part that I want to be normative is that an O/A is not valid unless the= mapping is possible with the information in the O/A, and that the offerer = and the answerer would agree about the mapping of each packet. I don't care= if they actually do the mapping, though if they are doing any sensible pro= cessing then they will be doing something *equivalent* to the mapping. Thanks, Paul > Mo > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Saturday, June 29, 2013 12:12 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map r= eceived data to m- line? > > On 6/29/13 8:50 AM, Colin Perkins wrote: >> Christer, >> >> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>> There has been some discussions about whether BUNDLE should mandate tha= t users are mandated to always (no matter what transport protocols are used= in the BUNDLE group) have a mechanism to map received data to an m- line, = or whether it from a generic BUNDLE perspective should be optional - IF the= re would be cases where it's not needed. >>> >>> We haven't had that much discussion about it yet, so I will not ask=20 >>> a DECISION question at this point, but I would really like to get=20 >>> some input from people who have opinions about this :) >> >> My opinion: BUNDLE needs to mandate a single algorithm for mapping from = RTP flows to m=3D lines, for those applications that care about such a mapp= ing. I don't think it should mandate that all applications need to care. > > I just replied elsewhere on this. > My opinion turns out to be the exact opposite of yours: we need to=20 > support multiple algorithms, and that all applications should care. > > I won't repeat the stuff about multiple algorithms. > > I will repeat what I have said about the need for being able to associate= : > > There must have been *some* reason that two m-lines were used, rather=20 > than just one. Each m-line heads a media section of the SDP that=20 > contains a bunch of declarations. Something must be different in those=20 > two media sections, or else a single media section would have been=20 > enough. Presumably whatever it is that is different is intended to=20 > affect how received packets are processed or interpreted. (If not,=20 > again there is no need for it to be there.) If you can't associate the=20 > packet with the m-line, then you don't know which of the multiple=20 > interpretations to apply to the packet. > > Maybe there is some exception to this, though I haven't come up with=20 > anything. If there is, then I hope someone will call it out. If so,=20 > then the constraint can be tightened. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From jonathan@vidyo.com Tue Jul 2 11:56: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 2520221F9BFF for ; Tue, 2 Jul 2013 11:56:57 -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 WXZOHnwMyvdX for ; Tue, 2 Jul 2013 11:56:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id E056721F9BBB for ; Tue, 2 Jul 2013 11:56:51 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 54E71416854; Tue, 2 Jul 2013 14:56:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F16F64169C2; Tue, 2 Jul 2013 14:56:44 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 2 Jul 2013 14:54:57 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Tue, 2 Jul 2013 14:56:48 -0400 Thread-Topic: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt Thread-Index: Ac53Vcy0p2/BBB8ISw22jFvhdH050g== Message-ID: References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> <51CF0435.3050305@alum.mit.edu> <047901ce7552$de032840$9a0978c0$@gmail.com> <51D0569C.3020508@alum.mit.edu> <051301ce764f$95a89370$c0f9ba50$@gmail.com> <51D1B642.8080608@alum.mit.edu> In-Reply-To: <51D1B642.8080608@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:56:57 -0000 On Jul 1, 2013, at 1:02 PM, Paul Kyzivat wrote: > It still isn't clear to me. You have three ways to communicate the mappin= g: >=20 > - SDP > - SDES > - header extension >=20 > I think the relationship and precedence between SDES and header=20 > extension is well defined in general, so I guess that doesn't need=20 > further elaboration. Actually, it probably needs some further elaboration in cases where RTP pac= kets arrive out of order (either with respect to themselves or with their R= TCP). But straightforward rules for this can probably be defined fairly ea= sily.=20 > But the relationship between the SDP and the RTP/RTCP mechanisms isn't=20 > so clear. This is especially problematic because it is impossible to=20 > synchronize the arrival of SDP with the arrival of RTP/RTCP. >=20 > The simplest answer would be to use the SDP as a *default* if the=20 > mapping hasn't been received in the media, with changes in the SDP=20 > having no effect on the mapping of a particular AppId once it has been=20 > mentioned in the media. But I don't know if that is a sufficient mechanis= m. >=20 > Alternatively, the mapping can be defined by whichever has been received= =20 > most recently. But that may cause artifacts. >=20 > I just think this needs to be made very clear. If we have AppIDs in SDP, I definitely think you need an "RTP associations = always win" semantic. On further reflection, though, I'm now wondering whether to what extent it'= s actually necessary to have per-SSRC AppIDs defined in SDP at all, since t= he point of AppID is to define an *alternative* to signaling SSRCs in SDP, = by instead defining application semantics with a layer of indirection. I think (and this was a bit of a point of disagreement between Roni and me = in writing the draft) that "Plan B"-style signaling with AppID should use a= =3DAppID:token attribute:value signaling in place of RFC 5576 a=3Dssrc:numb= er attribute:value signaling. I.e., it's similar semantics to RFC 5576 sig= naling, but with the extra indirection layer. -- Jonathan Lennox jonathan@vidyo.com From pkyzivat@alum.mit.edu Tue Jul 2 13:00: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 D334621F9AF3 for ; Tue, 2 Jul 2013 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 N+V9jetBWzxc for ; Tue, 2 Jul 2013 13:00:09 -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 074F621F9AFA for ; Tue, 2 Jul 2013 13:00:07 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id vPfh1l0040xGWP858Y07th; Tue, 02 Jul 2013 20:00:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id vY061l0113ZTu2S3YY07Yd; Tue, 02 Jul 2013 20:00:07 +0000 Message-ID: <51D33146.9010402@alum.mit.edu> Date: Tue, 02 Jul 2013 16:00:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> 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=1372795207; bh=i/J5msaHlUMDbOtBFWUPkvk3kWk1GZBmY/JH8bAbYNg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R0pnj8lqJPnTvRYV0MDjWqslsTYQBwc+cKOSGvKzEgl1qQy2+3N893YAIf86Qz/09 aWVRZTyQU4dKfS/6M7kFD+K35gBAbQiwvOglmGznUEz6vYNtWocrjd58EtNd0gHhzs JREMgbx8nKatBFyhLPPzsUHFUNUlTbkCEkdNy+N3Ymd0ghkadN+Huyzvj5o12WMxr3 Xgp4mXzOjkc/UeXYB05Kn7aTsaO4AMYn/+0QKKH1xRepjO9lUvn3OsPC3o6JNt++BP gvi2JbwyQZwpuEp0lZ7qbeCK7VdRO6FmPHUdgYy4qhD/nDIec0Vlk6doByc11il6oQ GWDIxRQmoM9SQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:00:13 -0000 +1 (Except that I *am* Paul) On 7/2/13 2:30 PM, Christer Holmberg wrote: > Hi, > > I am not Paul, but just to verify that I understand his issue, the question is: > > Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line? > > Regards, > > Christer > > -----Alkuperäinen viesti----- > Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty) > Lähetetty: 2. heinäkuuta 2013 19:09 > Vastaanottaja: Paul Kyzivat > Kopio: mmusic@ietf.org > Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > An attempt at "an answer that makes sense". (Just snippets, not full SDP.) > > m=video 10000 RTP/SAVPF 96 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker). > > You could mandate that PT must be unique to allow unique mapping. > > You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. > > Which do you want to mandate and why? > > Cheers, > Mo > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 10:06 AM > To: Mo Zanaty (mzanaty) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology? >> >> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan. > > I'm going to keep asking this question until I get an answer that makes > sense: > > Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. > > The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. > If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. > > The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping. > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Saturday, June 29, 2013 12:12 PM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> On 6/29/13 8:50 AM, Colin Perkins wrote: >>> Christer, >>> >>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed. >>>> >>>> We haven't had that much discussion about it yet, so I will not ask >>>> a DECISION question at this point, but I would really like to get >>>> some input from people who have opinions about this :) >>> >>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. >> >> I just replied elsewhere on this. >> My opinion turns out to be the exact opposite of yours: we need to >> support multiple algorithms, and that all applications should care. >> >> I won't repeat the stuff about multiple algorithms. >> >> I will repeat what I have said about the need for being able to associate: >> >> There must have been *some* reason that two m-lines were used, rather >> than just one. Each m-line heads a media section of the SDP that >> contains a bunch of declarations. Something must be different in those >> two media sections, or else a single media section would have been >> enough. Presumably whatever it is that is different is intended to >> affect how received packets are processed or interpreted. (If not, >> again there is no need for it to be there.) If you can't associate the >> packet with the m-line, then you don't know which of the multiple >> interpretations to apply to the packet. >> >> Maybe there is some exception to this, though I haven't come up with >> anything. If there is, then I hope someone will call it out. If so, >> then the constraint can be tightened. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From mzanaty@cisco.com Tue Jul 2 13: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 D1D5C11E80AE for ; Tue, 2 Jul 2013 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.324 X-Spam-Level: X-Spam-Status: No, score=-9.324 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 FisSC8a5FZOk for ; Tue, 2 Jul 2013 13:33:29 -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 B271F11E80F7 for ; Tue, 2 Jul 2013 13:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7378; q=dns/txt; s=iport; t=1372797208; x=1374006808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5tYAIPTJYNHkxNA4LPbTGGLv5oRtp99MBp7zzdBvtow=; b=QfrkjJDOdNRqMBkeVSbcgUEsh59neGsxtJwgzxPkor3XUUk6QPIHWuGN GuDdWcTGLEnDXEPUgXC4A5H6NnTyUewEN/vpbN/LiD1yYFvdUfTBvBfj+ lCyHIRMJfksifUtmrkuIReBWsjksbernM1Cs1klkxzlPeM+RS/SFOaWka M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACE401GtJXG+/2dsb2JhbABaDoJ7Mkm/ZIEIFnSCIwEBAQMBAQEBCWILBQcEAgEIDgMEAQEBCh0HJwsUCQgCBAENBQiIAQYMuywEjzQxBwaCfmkDiGugJIFYez6CKA X-IronPort-AV: E=Sophos;i="4.87,983,1363132800"; d="scan'208";a="230172866" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jul 2013 20:33:03 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r62KX34k009211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 20:33:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 15:33:02 -0500 From: "Mo Zanaty (mzanaty)" To: Paul Kyzivat , Christer Holmberg Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+AgAKxRwD//7wNkIAAjfgAgAAZDgD//7QIEA== Date: Tue, 2 Jul 2013 20:33:02 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> In-Reply-To: <51D33146.9010402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.30.85] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:33:33 -0000 > You could mandate that multiple m-lines of thumbnails must be combined in= to a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. It seems you both want to mandate this (Plan B). Why? I see no reason for b= undle to pick a plan. Let the plan wars rage outside bundle. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Tuesday, July 02, 2013 4:00 PM To: Christer Holmberg Cc: Mo Zanaty (mzanaty); mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? +1 (Except that I *am* Paul) On 7/2/13 2:30 PM, Christer Holmberg wrote: > Hi, > > I am not Paul, but just to verify that I understand his issue, the questi= on is: > > Why do you need 4 m- lines for the thumbnails, when you could use 1 m- li= ne? > > Regards, > > Christer > > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]= Puolesta Mo Zanaty (mzanaty) > L=E4hetetty: 2. hein=E4kuuta 2013 19:09 > Vastaanottaja: Paul Kyzivat > Kopio: mmusic@ietf.org > Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rece= ived data to m- line? > > An attempt at "an answer that makes sense". (Just snippets, not full SDP.= ) > > m=3Dvideo 10000 RTP/SAVPF 96 > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker > > m=3Dvideo 10000 RTP/SAVPF 97 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvon= ly > > m=3Dvideo 10000 RTP/SAVPF 97 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvon= ly > > m=3Dvideo 10000 RTP/SAVPF 97 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvon= ly > > m=3Dvideo 10000 RTP/SAVPF 97 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvon= ly > > No need to map thumbnail packets to specific m-lines, so reuse of PT=3D97= is fine. Just render the last 4 thumbnail sources received (in addition to= the main speaker). > > You could mandate that PT must be unique to allow unique mapping. > > You could mandate that multiple m-lines of thumbnails must be combined in= to a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > Which do you want to mandate and why? > > Cheers, > Mo > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 10:06 AM > To: Mo Zanaty (mzanaty) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map r= eceived data to m- line? > > On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >> Informative descriptions of possible mappings are fine, but nothing norm= ative, please. Some applications won't care about the mapping, and others m= ay care but use a different mapping from those described. The only normativ= e statement you could make is something like: "If you care about the mappin= g, you MUST have a mapping mechanism. You MAY use the mechanism(s) describe= d here, or some other mechanism." But why mandate such a tautology? >> >> The assumption below that multiple m-lines always require different m-li= ne-specific processing of the packets also assumes Plan B, i.e. that multip= le streams with similar processing should always be signaled with a single = m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use = multiple m-lines even for multiple streams with the same processing. I don'= t think we want to force bundle to pick a plan. > > I'm going to keep asking this question until I get an answer that makes > sense: > > Please explain to me a meaningful situation when there are multiple m-lin= es in a bundle and there is insufficient information to associate each pack= et with an m-line. > > The *point* of plan A is that there be an m-line per "flow", and that the= offerer is enumerating the flows. So clearly it knows the mapping. > If the answerer isn't capable of doing the same mapping, then the use of = plan A has failed. > > The part that I want to be normative is that an O/A is not valid unless t= he mapping is possible with the information in the O/A, and that the offere= r and the answerer would agree about the mapping of each packet. I don't ca= re if they actually do the mapping, though if they are doing any sensible p= rocessing then they will be doing something *equivalent* to the mapping. > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Saturday, June 29, 2013 12:12 PM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/29/13 8:50 AM, Colin Perkins wrote: >>> Christer, >>> >>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>> There has been some discussions about whether BUNDLE should mandate th= at users are mandated to always (no matter what transport protocols are use= d in the BUNDLE group) have a mechanism to map received data to an m- line,= or whether it from a generic BUNDLE perspective should be optional - IF th= ere would be cases where it's not needed. >>>> >>>> We haven't had that much discussion about it yet, so I will not ask >>>> a DECISION question at this point, but I would really like to get >>>> some input from people who have opinions about this :) >>> >>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from= RTP flows to m=3D lines, for those applications that care about such a map= ping. I don't think it should mandate that all applications need to care. >> >> I just replied elsewhere on this. >> My opinion turns out to be the exact opposite of yours: we need to >> support multiple algorithms, and that all applications should care. >> >> I won't repeat the stuff about multiple algorithms. >> >> I will repeat what I have said about the need for being able to associat= e: >> >> There must have been *some* reason that two m-lines were used, rather >> than just one. Each m-line heads a media section of the SDP that >> contains a bunch of declarations. Something must be different in those >> two media sections, or else a single media section would have been >> enough. Presumably whatever it is that is different is intended to >> affect how received packets are processed or interpreted. (If not, >> again there is no need for it to be there.) If you can't associate the >> packet with the m-line, then you don't know which of the multiple >> interpretations to apply to the packet. >> >> Maybe there is some exception to this, though I haven't come up with >> anything. If there is, then I hope someone will call it out. If so, >> then the constraint can be tightened. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Jul 2 15:40: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 23AF111E8100 for ; Tue, 2 Jul 2013 15:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 50RjjhzQJpbZ for ; Tue, 2 Jul 2013 15:40:09 -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 560D121F8FB3 for ; Tue, 2 Jul 2013 15:40:09 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id vPZL1l0031vXlb853ag8xk; Tue, 02 Jul 2013 22:40:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id vag81l00q3ZTu2S3dag8Kh; Tue, 02 Jul 2013 22:40:08 +0000 Message-ID: <51D356C7.2030909@alum.mit.edu> Date: Tue, 02 Jul 2013 18:40:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.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=1372804808; bh=KWd761poRTIS0I5aq6PnjyTysmkbG1FIMpIL+FFQDVI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FFlNozHJhoC1s1FwLcf7zLCwDDKQRzxRsOkWrVf+3FDMfyD2dFCtyVXWKGXX1l/uv UUef0gXvL0PT2j6dYWFa872htYCkiXA3f8rIPy68uka4n0UOc1Ju6Oem0bk63taQxz g29RqScwfc8v4NUt8kHhRua9JMo4RRWgVqJjCxVQ6TvKDYbsk2vpIHeiJjM77lnhmv TWQRbuJz+/nG+lp1EA0PCj7B9bvVxmhMJ3UKXFtH8cmX2Q6NiGJhPrn8sBBmHT5gaL d4buivbBMDvEXhGXgTfx1t8hYaYuXCKCk6HJBK7Oe/1W+GGCQIdAPCibMYlupeU4/P l5JUKCRhUIK/g== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 22:40:14 -0000 On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only* purpose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with one of the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a different flow, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There you still need the ability to associate packets to m-lines, but that isn't sufficient to map them to flows. It is assumed that "extra" information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the question is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line? >> >> Regards, >> >> Christer >> >> -----Alkuperäinen viesti----- >> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty) >> Lähetetty: 2. heinäkuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full SDP.) >> >> m=video 10000 RTP/SAVPF 96 >> a=rtpmap:96 H264/90000 >> a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker >> >> m=video 10000 RTP/SAVPF 97 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >> >> m=video 10000 RTP/SAVPF 97 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >> >> m=video 10000 RTP/SAVPF 97 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >> >> m=video 10000 RTP/SAVPF 97 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not ask >>>>> a DECISION question at this point, but I would really like to get >>>>> some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associate: >>> >>> There must have been *some* reason that two m-lines were used, rather >>> than just one. Each m-line heads a media section of the SDP that >>> contains a bunch of declarations. Something must be different in those >>> two media sections, or else a single media section would have been >>> enough. Presumably whatever it is that is different is intended to >>> affect how received packets are processed or interpreted. (If not, >>> again there is no need for it to be there.) If you can't associate the >>> packet with the m-line, then you don't know which of the multiple >>> interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with >>> anything. If there is, then I hope someone will call it out. If so, >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From mzanaty@cisco.com Tue Jul 2 22:06: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 B859921F9BA8 for ; Tue, 2 Jul 2013 22:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 zKUHPRlG87WE for ; Tue, 2 Jul 2013 22:06:51 -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 14FFA21F9B9D for ; Tue, 2 Jul 2013 22:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9072; q=dns/txt; s=iport; t=1372827995; x=1374037595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ir9qkVtU/JwpRRuWtMNtIEiX7kvveXw06akKZbV0KqA=; b=dsOA8+bfZUKGprEetP/OMk3vD4m6FRAKg0YIBLs6vozi639UglkpmBxT d0b9sR58l/o+jZKXsW5wIzX6isS3mFyQ+ID3JCw2kdsMetyIPiWXtMcdj JGu+dMT4U2HO+WauOwcLJtU9VKkWaTd2a3MFRYS+wn1oL5t/1ooymJx6z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANew01GtJXG//2dsb2JhbABaDoJ7MknAHIEDFnSCIwEBAQMBAQEBCWILBQcEAgEIDgMEAQEBCh0HJwsUCQgCBA4FCIgBBgy7SwSPNDEHBoJ+aQOIa6AkgVh7PoIo X-IronPort-AV: E=Sophos;i="4.87,985,1363132800"; d="scan'208";a="230426883" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2013 05:06:34 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6356Y8i001176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 05:06:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 00:06:33 -0500 From: "Mo Zanaty (mzanaty)" To: Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+AgAKxRwD//7wNkIAAjfgAgAAZDgD//7QIEIAAeK2AgAAEm8A= Date: Wed, 3 Jul 2013 05:06:32 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> In-Reply-To: <51D356C7.2030909@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.225.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 05:06:57 -0000 To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per t= humbnail, all with the same port/PT). While I personally would not chose th= is, I see no reason to forbid it, because I recognize it is just personal p= reference. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Tuesday, July 02, 2013 6:40 PM To: Mo Zanaty (mzanaty) Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for= bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only*=20 purpose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with=20 one of the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a=20 different flow, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There=20 you still need the ability to associate packets to m-lines, but that=20 isn't sufficient to map them to flows. It is assumed that "extra"=20 information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the quest= ion is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- l= ine? >> >> Regards, >> >> Christer >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ] Puolesta Mo Zanaty (mzanaty) >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full SDP= .) >> >> m=3Dvideo 10000 RTP/SAVPF 96 >> a=3Drtpmap:96 H264/90000 >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=3D9= 7 is fine. Just render the last 4 thumbnail sources received (in addition t= o the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing nor= mative, please. Some applications won't care about the mapping, and others = may care but use a different mapping from those described. The only normati= ve statement you could make is something like: "If you care about the mappi= ng, you MUST have a mapping mechanism. You MAY use the mechanism(s) describ= ed here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-l= ine-specific processing of the packets also assumes Plan B, i.e. that multi= ple streams with similar processing should always be signaled with a single= m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use= multiple m-lines even for multiple streams with the same processing. I don= 't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-li= nes in a bundle and there is insufficient information to associate each pac= ket with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that th= e offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of= plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless = the mapping is possible with the information in the O/A, and that the offer= er and the answerer would agree about the mapping of each packet. I don't c= are if they actually do the mapping, though if they are doing any sensible = processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate t= hat users are mandated to always (no matter what transport protocols are us= ed in the BUNDLE group) have a mechanism to map received data to an m- line= , or whether it from a generic BUNDLE perspective should be optional - IF t= here would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not ask >>>>> a DECISION question at this point, but I would really like to get >>>>> some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping fro= m RTP flows to m=3D lines, for those applications that care about such a ma= pping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associa= te: >>> >>> There must have been *some* reason that two m-lines were used, rather >>> than just one. Each m-line heads a media section of the SDP that >>> contains a bunch of declarations. Something must be different in those >>> two media sections, or else a single media section would have been >>> enough. Presumably whatever it is that is different is intended to >>> affect how received packets are processed or interpreted. (If not, >>> again there is no need for it to be there.) If you can't associate the >>> packet with the m-line, then you don't know which of the multiple >>> interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with >>> anything. If there is, then I hope someone will call it out. If so, >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From christer.holmberg@ericsson.com Wed Jul 3 00:26: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 CE3451F0D35 for ; Wed, 3 Jul 2013 00:26:49 -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=-2.106, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 Nw+vq7XFSITq for ; Wed, 3 Jul 2013 00:26:44 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC41F0D33 for ; Wed, 3 Jul 2013 00:26:43 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-79-51d3d22a25b3 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.60.11907.A22D3D15; Wed, 3 Jul 2013 09:26:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 09:26:33 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkP//9/UAgAAJMwCAACOCgIAAa/cA//+5UEA= Date: Wed, 3 Jul 2013 07:26:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7WpcuBBtcnqVlMXf6YxeLFgzlM Fis2HGB1YPb4+/4Dk8eU3xtZPZYs+ckUwBzFZZOSmpNZllqkb5fAlXHt8G3mgoe+FduaHjA2 ML6w62Lk5JAQMJG4f/wXC4QtJnHh3nq2LkYuDiGBo4wSvVNfsoEkhAQWMkqsfyzbxcjBwSZg IdH9TxskLCIQKrFh6QYWkDCzgLrE1cVBIKawQLrE7U2ZEBUZEnMvvGOFsMskNjRcYwaxWQRU JJ5dOwRm8wr4Siz88YsdYustFolHG4+AncMJlJiz5jIjiM0IdNr3U2uYQGxmAXGJDwevM0Oc LCCxZM95KFtU4uXjf6wQtpJE45InrBD1ehI3pk5hg7C1JZYtfA21WFDi5MwnLBMYxWYhGTsL ScssJC2zkLQsYGRZxchRnFqclJtuZLCJERg1B7f8ttjBePmvzSFGaQ4WJXHeLXpnAoUE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwKhar/WFncnnWofLu0h1PsasfLKQK29O21/8pWv7Uj+3h kWeado4u4i/P+mzPO+3sVLgof9nnVSdCLpxnOqxVmclbf/yLibT77MM7JqRVzL11a+eMa//m aG+7Iflaotyk9e3b+q4/+uFFhrf2ey+743Qy8apiYmr9mmgdzvS+itDbP25Euf3dqcRSnJFo qMVcVJwIAGuvaGxoAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 07:26:49 -0000 Hi Mo, I think what you are saying is that you want to have one thumbnail flow per= m- line. So far so good. And, WITHOUT BUNDLE, you would be able to demux the flows based on the 5-tu= ple (as each m- line would have a unique address:port). So far go good. But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-tuple, s= o if you want to demux the streams you need to have SOME other mechanism th= an the 5-tuple. Will you demux based on SSRC? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]=20 L=E4hetetty: 3. hein=E4kuuta 2013 8:07 Vastaanottaja: Paul Kyzivat Kopio: Christer Holmberg; mmusic@ietf.org Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map re= ceived data to m- line? To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per t= humbnail, all with the same port/PT). While I personally would not chose th= is, I see no reason to forbid it, because I recognize it is just personal p= reference. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, July 02, 2013 6:40 PM To: Mo Zanaty (mzanaty) Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for= bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only* pur= pose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with one o= f the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a different f= low, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There you s= till need the ability to associate packets to m-lines, but that isn't suffi= cient to map them to flows. It is assumed that "extra"=20 information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the quest= ion is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- l= ine? >> >> Regards, >> >> Christer >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ]=20 >> Puolesta Mo Zanaty (mzanaty) >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full=20 >> SDP.) >> >> m=3Dvideo 10000 RTP/SAVPF 96 >> a=3Drtpmap:96 H264/90000 >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=3D9= 7 is fine. Just render the last 4 thumbnail sources received (in addition t= o the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing nor= mative, please. Some applications won't care about the mapping, and others = may care but use a different mapping from those described. The only normati= ve statement you could make is something like: "If you care about the mappi= ng, you MUST have a mapping mechanism. You MAY use the mechanism(s) describ= ed here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-l= ine-specific processing of the packets also assumes Plan B, i.e. that multi= ple streams with similar processing should always be signaled with a single= m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use= multiple m-lines even for multiple streams with the same processing. I don= 't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that=20 >> makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-li= nes in a bundle and there is insufficient information to associate each pac= ket with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that th= e offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of= plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless = the mapping is possible with the information in the O/A, and that the offer= er and the answerer would agree about the mapping of each packet. I don't c= are if they actually do the mapping, though if they are doing any sensible = processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate t= hat users are mandated to always (no matter what transport protocols are us= ed in the BUNDLE group) have a mechanism to map received data to an m- line= , or whether it from a generic BUNDLE perspective should be optional - IF t= here would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not=20 >>>>> ask a DECISION question at this point, but I would really like to=20 >>>>> get some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping fro= m RTP flows to m=3D lines, for those applications that care about such a ma= pping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to=20 >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associa= te: >>> >>> There must have been *some* reason that two m-lines were used,=20 >>> rather than just one. Each m-line heads a media section of the SDP=20 >>> that contains a bunch of declarations. Something must be different=20 >>> in those two media sections, or else a single media section would=20 >>> have been enough. Presumably whatever it is that is different is=20 >>> intended to affect how received packets are processed or=20 >>> interpreted. (If not, again there is no need for it to be there.) If=20 >>> you can't associate the packet with the m-line, then you don't know=20 >>> which of the multiple interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with=20 >>> anything. If there is, then I hope someone will call it out. If so,=20 >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From christer.holmberg@ericsson.com Wed Jul 3 04:38: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 83E0711E8181 for ; Wed, 3 Jul 2013 04:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 M4Jya6+2FAH9 for ; Wed, 3 Jul 2013 04:38:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9021F9C72 for ; Wed, 3 Jul 2013 04:38:02 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-10-51d40d187143 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 02.0F.05990.81D04D15; Wed, 3 Jul 2013 13:38:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 13:38:00 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkP//9/UAgAAJMwCAACOCgIAAa/cAgACO5vo= Date: Wed, 3 Jul 2013 11:38:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C1F8C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu>, <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3C1F8CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvra4k75VAg8trmC2mLn/MYvHiwRwm ixUbDrA6MHv8ff+ByWPK742sHkuW/GQKYI7isklJzcksSy3St0vgyji+bSpzwYYdjBXHZ3ex NTCunsnYxcjJISFgInHrZicbhC0mceHeeiCbi0NI4DCjxOV529ghnIWMEr/bNrF0MXJwsAlY SHT/0wZpEBEIldiwdAMLiM0soCrxeup3VhBbWCBd4sqLNSwQNRkScy+8Y4WwyySWnLnDDmKz CKhIXDoxESzOK+Arcb3tJNTiGywS504fYQZJcAIl5qy5DHYpI9B130+tYYJYJi5x68l8Joir BSSW7DnPDGGLSrx8/I8VoiZf4vKUKSwQCwQlTs58wjKBUWQWkvZZSMpmISmDiOtJ3Jg6hQ3C 1pZYtvA1M4StKzHj3yEWZPEFjOyrGNlzEzNz0suNNjECo+rglt+qOxjvnBM5xCjNwaIkzrtZ 70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYK+1fffgvbiH5452uu2K6/Jk8qkYdPku1z pfJ8jT2vy2xiVm++eOVA+8yLSoeSjvgzpS9Sk9sed674X57Cdn2Rbp3Z/DI5+xbVZT2ZZ5z/ fLu89KPer4acZReiE8oKnk2vZ9j230L1Qv5c34bVH1bPMrX3tHR6xNnTt+zqTg3NlBdxS9Zr nlViKc5INNRiLipOBACejbuGeAIAAA== Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 11:38:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3C1F8CESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I guess one advantage with 4 m- lines is that, if the remote endpoint does = not support BUNDLE, it will allow to have a separate 5-tuple for each thumb= nail stream, without having to send a "fallack" offer. When both endpoints do support BUNDLE it makes little sense, but when think= ing about it I really wonder if there is a reason to forbid it. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Mo Zanaty (mzanaty) [mzanaty@cisco.com] To: Paul Kyzivat [pkyzivat@alum.mit.edu] CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.org [mm= usic@ietf.org] Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per t= humbnail, all with the same port/PT). While I personally would not chose th= is, I see no reason to forbid it, because I recognize it is just personal p= reference. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, July 02, 2013 6:40 PM To: Mo Zanaty (mzanaty) Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for= bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only* purpose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with one of the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a different flow, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There you still need the ability to associate packets to m-lines, but that isn't sufficient to map them to flows. It is assumed that "extra" information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the quest= ion is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- l= ine? >> >> Regards, >> >> Christer >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ] Puolesta Mo Zanaty (mzanaty) >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full SDP= .) >> >> m=3Dvideo 10000 RTP/SAVPF 96 >> a=3Drtpmap:96 H264/90000 >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=3D9= 7 is fine. Just render the last 4 thumbnail sources received (in addition t= o the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing nor= mative, please. Some applications won't care about the mapping, and others = may care but use a different mapping from those described. The only normati= ve statement you could make is something like: "If you care about the mappi= ng, you MUST have a mapping mechanism. You MAY use the mechanism(s) describ= ed here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-l= ine-specific processing of the packets also assumes Plan B, i.e. that multi= ple streams with similar processing should always be signaled with a single= m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use= multiple m-lines even for multiple streams with the same processing. I don= 't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-li= nes in a bundle and there is insufficient information to associate each pac= ket with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that th= e offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of= plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless = the mapping is possible with the information in the O/A, and that the offer= er and the answerer would agree about the mapping of each packet. I don't c= are if they actually do the mapping, though if they are doing any sensible = processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate t= hat users are mandated to always (no matter what transport protocols are us= ed in the BUNDLE group) have a mechanism to map received data to an m- line= , or whether it from a generic BUNDLE perspective should be optional - IF t= here would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not ask >>>>> a DECISION question at this point, but I would really like to get >>>>> some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping fro= m RTP flows to m=3D lines, for those applications that care about such a ma= pping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associa= te: >>> >>> There must have been *some* reason that two m-lines were used, rather >>> than just one. Each m-line heads a media section of the SDP that >>> contains a bunch of declarations. Something must be different in those >>> two media sections, or else a single media section would have been >>> enough. Presumably whatever it is that is different is intended to >>> affect how received packets are processed or interpreted. (If not, >>> again there is no need for it to be there.) If you can't associate the >>> packet with the m-line, then you don't know which of the multiple >>> interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with >>> anything. If there is, then I hope someone will call it out. If so, >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --_000_7594FB04B1934943A5C02806D1A2204B1C3C1F8CESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
I guess one advantage with 4 m- lines is that, if the remote endpoint = does not support BUNDLE, it will allow to have a separate 5-tuple for each = thumbnail stream, without having to send a "fallack" offer.
 
When both endpoints do support BUNDLE it makes little sense, but when = thinking about it I really wonder if there is a reason to forbid it.
 
 
Regards,
 
Christer
 
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Mo Zanaty (mzanaty) [mzanaty@cisco.com]
To: Paul Kyzivat [pkyzivat@alum.mit.edu]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic@ietf.= org [mmusic@ietf.org]
Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism= to map received data to m- line?
To clarify, I have no plan to use or abuse Plan A.= The implementations I'm most interested in are all closer to Plan B. Howev= er, I'm aware of widely deployed implementations (from other vendors) which= are closer to Plan A in general, and specifically for the thumbnail example below (one m-line per thumbnail= , all with the same port/PT). While I personally would not chose this, I se= e no reason to forbid it, because I recognize it is just personal preferenc= e.

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; mmusic@ietf.org
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line?

On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote:
>> You could mandate that multiple m-lines of thumbnails must be comb= ined into a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever.<= br> >
> It seems you both want to mandate this (Plan B). Why? I see no reason = for bundle to pick a plan. Let the plan wars rage outside bundle.

So you want to use plan A *without* the association, so that the *only* purpose of the extra m-lines is to denote the number of flows?

How would the receiver know if an incoming packet was associated with
one of the flows defined by the m-lines?

How would the receiver know if each ssrc should be treated as a
different flow, or if appid should be used to define flows?

I think you abuse plan A. Its different with plan B or No Plan. There
you still need the ability to associate packets to m-lines, but that
isn't sufficient to map them to flows. It is assumed that "extra"=
information, learned by different means, is used to sort out the flows.

        Thanks,
        Paul

> Mo
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pk= yzivat@alum.mit.edu]
> Sent: Tuesday, July 02, 2013 4:00 PM
> To: Christer Holmberg
> Cc: Mo Zanaty (mzanaty); mmusic@ietf.org
> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism t= o map received data to m- line?
>
> +1
> (Except that I *am* Paul)
>
> On 7/2/13 2:30 PM, Christer Holmberg wrote:
>> Hi,
>>
>> I am not Paul, but just to verify that I understand his issue, the= question is:
>>
>> Why do you need 4 m- lines for the thumbnails, when you could use = 1 m- line?
>>
>> Regards,
>>
>> Christer
>>
>> -----Alkuper=E4inen viesti-----
>> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (= mzanaty)
>> L=E4hetetty: 2. hein=E4kuuta 2013 19:09
>> Vastaanottaja: Paul Kyzivat
>> Kopio: mmusic@ietf.org
>> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line?
>>
>> An attempt at "an answer that makes sense". (Just snippe= ts, not full SDP.)
>>
>> m=3Dvideo 10000 RTP/SAVPF 96
>> a=3Drtpmap:96 H264/90000
>> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speak= er
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> No need to map thumbnail packets to specific m-lines, so reuse of = PT=3D97 is fine. Just render the last 4 thumbnail sources received (in addi= tion to the main speaker).
>>
>> You could mandate that PT must be unique to allow unique mapping.<= br> >>
>> You could mandate that multiple m-lines of thumbnails must be comb= ined into a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever.<= br> >>
>> Which do you want to mandate and why?
>>
>> Cheers,
>> Mo
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailt= o:pkyzivat@alum.mit.edu]
>> Sent: Tuesday, July 02, 2013 10:06 AM
>> To: Mo Zanaty (mzanaty)
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism t= o map received data to m- line?
>>
>> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote:
>>> Informative descriptions of possible mappings are fine, but no= thing normative, please. Some applications won't care about the mapping, an= d others may care but use a different mapping from those described. The onl= y normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechani= sm. You MAY use the mechanism(s) described here, or some other mechanism.&q= uot; But why mandate such a tautology?
>>>
>>> The assumption below that multiple m-lines always require diff= erent m-line-specific processing of the packets also assumes Plan B, i.e. t= hat multiple streams with similar processing should always be signaled with= a single m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple = streams with the same processing. I don't think we want to force bundle to = pick a plan.
>>
>> I'm going to keep asking this question until I get an answer that = makes
>> sense:
>>
>> Please explain to me a meaningful situation when there are multipl= e m-lines in a bundle and there is insufficient information to associate ea= ch packet with an m-line.
>>
>> The *point* of plan A is that there be an m-line per "flow&qu= ot;, and that the offerer is enumerating the flows. So clearly it knows the= mapping.
>> If the answerer isn't capable of doing the same mapping, then the = use of plan A has failed.
>>
>> The part that I want to be normative is that an O/A is not valid u= nless the mapping is possible with the information in the O/A, and that the= offerer and the answerer would agree about the mapping of each packet. I d= on't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing s= omething *equivalent* to the mapping.
>>
>>       Thanks,
>>       Paul
>>
>>> Mo
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>> Behalf Of Paul Kyzivat
>>> Sent: Saturday, June 29, 2013 12:12 PM
>>> To: mmusic@ietf.org
>>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechani= sm to map received data to m- line?
>>>
>>> On 6/29/13 8:50 AM, Colin Perkins wrote:
>>>> Christer,
>>>>
>>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
>>>>> There has been some discussions about whether BUNDLE s= hould mandate that users are mandated to always (no matter what transport p= rotocols are used in the BUNDLE group) have a mechanism to map received dat= a to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not ne= eded.
>>>>>
>>>>> We haven't had that much discussion about it yet, so I= will not ask
>>>>> a DECISION question at this point, but I would really = like to get
>>>>> some input from people who have opinions about this :)=
>>>>
>>>> My opinion: BUNDLE needs to mandate a single algorithm for= mapping from RTP flows to m=3D lines, for those applications that care abo= ut such a mapping. I don't think it should mandate that all applications ne= ed to care.
>>>
>>> I just replied elsewhere on this.
>>> My opinion turns out to be the exact opposite of yours: we nee= d to
>>> support multiple algorithms, and that all applications should = care.
>>>
>>> I won't repeat the stuff about multiple algorithms.
>>>
>>> I will repeat what I have said about the need for being able t= o associate:
>>>
>>> There must have been *some* reason that two m-lines were used,= rather
>>> than just one. Each m-line heads a media section of the SDP th= at
>>> contains a bunch of declarations. Something must be different = in those
>>> two media sections, or else a single media section would have = been
>>> enough. Presumably whatever it is that is different is intende= d to
>>> affect how received packets are processed or interpreted. (If = not,
>>> again there is no need for it to be there.) If you can't assoc= iate the
>>> packet with the m-line, then you don't know which of the multi= ple
>>> interpretations to apply to the packet.
>>>
>>> Maybe there is some exception to this, though I haven't come u= p with
>>> anything. If there is, then I hope someone will call it out. I= f so,
>>> then the constraint can be tightened.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https= ://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/mmusic
>>
>
>

 --_000_7594FB04B1934943A5C02806D1A2204B1C3C1F8CESESSMB209erics_-- From emil@sip-communicator.org Wed Jul 3 07:13: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 9289C21F9BB6 for ; Wed, 3 Jul 2013 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFMTtMqk3Hjh for ; Wed, 3 Jul 2013 07:13:54 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5119511E81A0 for ; Wed, 3 Jul 2013 07:13:54 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so5284542wiv.7 for ; Wed, 03 Jul 2013 07:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=TzihQPLf5/PLJ9EhwcpUp8JtxQfIuTm6inMypkvbx+I=; b=jv4/OhAv0f5CkyH8qYW3boGP++K0h7fBBPOW0W11kfe5JOLb8QHQoHzF+TRzbMTHqW wSBv0nRseqS+S1sJf/tTYS+vJ3L2FBnT4tAIvfC6F7kl1FO9wRFaHTe158KuJ/wYTT5b 48yHSuhewfEGxu90r9Pw4XIU/R567nQXvUIiKvhjlLK/QQPz6R42Z0/CsaGJLzZk5nVL xCV9OUibfw+qYA9YDJ18zOePg2IZ9hIvx7RKZNAyPyEIElKT/+VwvPH7gg13G5C+t777 lUAorGF2JtmXWtCz9YUK36kX1wsGtxEbj7mm1up0hTK/WsT/C6F8Tm8qyNjlwhQ3AQDW wpng== X-Received: by 10.180.12.11 with SMTP id u11mr637683wib.61.1372860828265; Wed, 03 Jul 2013 07:13:48 -0700 (PDT) Received: from [192.168.43.3] ([90.84.144.37]) by mx.google.com with ESMTPSA id fo10sm29062729wib.8.2013.07.03.07.13.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 07:13:47 -0700 (PDT) Message-ID: <51D43186.2010907@jitsi.org> Date: Wed, 03 Jul 2013 16:13:26 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: MMUSIC IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQljlNnp28L0CljM29rfpB4Zg9HuuYfAda/BF2Cq7eAI78wic6cJkAp2IWKMsNcIIEuNK2E2 Subject: [MMUSIC] Trickle ICE for SIP 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, 03 Jul 2013 14:13:59 -0000 Hey all, Christer, Enrico and I are preparing the next version of Trickle ICE for SIP. Now that discussions on BUNDLE and the plans seem to be winding down, we wanted to run a few questions by the working group. Q1: Making reliable provisional responses and PRACK mandatory. Obviously this would be nice to avoid, so the question is: is there a reasonable mechanism to achieve this (and by reasonable, we mean something that wouldn't be harder than implementing support for PRACK). There was some discussion about this back in April and there was a suggestion for implementing a 5245-style hack where the answerer basically resends the 180 until it knows that it has been received. 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions when the first connectivity check is received) but we don't have that option here since the 180 may contain either none or only host candidates so there are strong chances that no binding request would be received on them. Thomas also suggested a second option which would be to also use INFO requests with trickled candidates as an indication that 180 was received. This however wouldn't work with half trickle so we are basically back to vanilla ICE for all (non-re) INVITEs. Another option would be to mandate an INFO request with "end-of-candidates" in response to the 180, but that would be just the same as mandating PRACK support. Thomas also suggested that the answerer can start sending INFOs right after it sends its answer in the 180 and then it can just resend the 180 if the INFOs result in a 481 response. Personally I think this could potentially be made to work, but it would imply a level of complexity that considerably exceeds PRACK support. Opinions? Q2: How do we send INFOs? Are they blocking or do we just send them in parallel? If the latter, then what happens when an INFO fails because it is received out of order? Do we just tell the application to resend the candidates asap? This also leads to the following question: Q3: What exactly do we send in INFOs? Just the latest batch of freshly learned candidates or all candidates we've learned so far? Dale suggested that if we do this cumulatively we wouldn't need to worry about the case with the out-of-order INFOs from Q2 since the information gets resent anyway. A drawback here would obviously be that this adds more complexity for trickle ICE users (WebRTC applications specifically) A third option would be to allow both and leave it to the application. Comments are most welcome! Emil -- https://jitsi.org From partha@parthasarathi.co.in Wed Jul 3 09: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 BEEC821F9DDD for ; Wed, 3 Jul 2013 09:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 NSlowXJojQCZ for ; Wed, 3 Jul 2013 09:31:55 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6F98721F9DDB for ; Wed, 3 Jul 2013 09:31:55 -0700 (PDT) Received: from userPC (unknown [122.179.83.161]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D976C190822B; Wed, 3 Jul 2013 16:31:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372869114; bh=V3NtvlgBrOa0khgwWSLdAGxNRTkrbCuqjaMbesDyUFI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FeHnvTv8s4PBr7YmS/L7e9Kg9sTij+fBli2I7wIJy5zLZCRyEldg5xZd9E6sldsV4 yZrFO9kW3B0pEFMlT/1MMdcwRRLmgwxb8998iKCF8ErXJ0eILoK/3ijo8HdLXYwCW8 LQzv5inXB82N0XW9nf8f1QU6M8Ujh93XC4L7aEMk= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Mo Zanaty \(mzanaty\)'" , "'Paul Kyzivat'" References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> Date: Wed, 3 Jul 2013 22:01:42 +0530 Message-ID: <00e101ce780a$d189acf0$749d06d0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkP//9/UAgAAJMwCAACOCgIAAa/cA//+5UED//tlUkA== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51D451FA.00EF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 16:32:03 -0000 Hi all, In case BUNDLE, the same type of =93m=94 lines shall be diffentiated by = SDP label attribute? I'm asking this question as I heard that SSRC in RTP is = not created to differentiate RTP session. In fact in SIPREC, the label attribute is used to differentiate the two different "m" line of the same type. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, July 03, 2013 12:57 PM > To: Mo Zanaty (mzanaty); Paul Kyzivat > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to = map > received data to m- line? >=20 > Hi Mo, >=20 > I think what you are saying is that you want to have one thumbnail = flow > per m- line. So far so good. >=20 > And, WITHOUT BUNDLE, you would be able to demux the flows based on the > 5-tuple (as each m- line would have a unique address:port). So far go > good. >=20 > But, in your example, WITH BUNDLE, all 4 m- lines share the same 5- > tuple, so if you want to demux the streams you need to have SOME other > mechanism than the 5-tuple. Will you demux based on SSRC? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > L=E4hetetty: 3. hein=E4kuuta 2013 8:07 > Vastaanottaja: Paul Kyzivat > Kopio: Christer Holmberg; mmusic@ietf.org > Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > map received data to m- line? >=20 > To clarify, I have no plan to use or abuse Plan A. The implementations > I'm most interested in are all closer to Plan B. However, I'm aware of > widely deployed implementations (from other vendors) which are closer > to Plan A in general, and specifically for the thumbnail example below > (one m-line per thumbnail, all with the same port/PT). While I > personally would not chose this, I see no reason to forbid it, because > I recognize it is just personal preference. >=20 > Mo >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 6:40 PM > To: Mo Zanaty (mzanaty) > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism = to > map received data to m- line? >=20 > On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: > >> You could mandate that multiple m-lines of thumbnails must be > combined into a single m-line with a=3Dssrc/max-ssrc/multiple- > render/whatever. > > > > It seems you both want to mandate this (Plan B). Why? I see no = reason > for bundle to pick a plan. Let the plan wars rage outside bundle. >=20 > So you want to use plan A *without* the association, so that the = *only* > purpose of the extra m-lines is to denote the number of flows? >=20 > How would the receiver know if an incoming packet was associated with > one of the flows defined by the m-lines? >=20 > How would the receiver know if each ssrc should be treated as a > different flow, or if appid should be used to define flows? >=20 > I think you abuse plan A. Its different with plan B or No Plan. There > you still need the ability to associate packets to m-lines, but that > isn't sufficient to map them to flows. It is assumed that "extra" > information, learned by different means, is used to sort out the = flows. >=20 > Thanks, > Paul >=20 > > Mo > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Tuesday, July 02, 2013 4:00 PM > > To: Christer Holmberg > > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism > to map received data to m- line? > > > > +1 > > (Except that I *am* Paul) > > > > On 7/2/13 2:30 PM, Christer Holmberg wrote: > >> Hi, > >> > >> I am not Paul, but just to verify that I understand his issue, the > question is: > >> > >> Why do you need 4 m- lines for the thumbnails, when you could use 1 > m- line? > >> > >> Regards, > >> > >> Christer > >> > >> -----Alkuper=E4inen viesti----- > >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] > >> Puolesta Mo Zanaty (mzanaty) > >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 > >> Vastaanottaja: Paul Kyzivat > >> Kopio: mmusic@ietf.org > >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to = map > received data to m- line? > >> > >> An attempt at "an answer that makes sense". (Just snippets, not = full > >> SDP.) > >> > >> m=3Dvideo 10000 RTP/SAVPF 96 > >> a=3Drtpmap:96 H264/90000 > >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker > >> > >> m=3Dvideo 10000 RTP/SAVPF 97 > >> a=3Drtpmap:97 H264/90000 > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > a=3Drecvonly > >> > >> m=3Dvideo 10000 RTP/SAVPF 97 > >> a=3Drtpmap:97 H264/90000 > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > a=3Drecvonly > >> > >> m=3Dvideo 10000 RTP/SAVPF 97 > >> a=3Drtpmap:97 H264/90000 > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > a=3Drecvonly > >> > >> m=3Dvideo 10000 RTP/SAVPF 97 > >> a=3Drtpmap:97 H264/90000 > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > a=3Drecvonly > >> > >> No need to map thumbnail packets to specific m-lines, so reuse of > PT=3D97 is fine. Just render the last 4 thumbnail sources received (in > addition to the main speaker). > >> > >> You could mandate that PT must be unique to allow unique mapping. > >> > >> You could mandate that multiple m-lines of thumbnails must be > combined into a single m-line with a=3Dssrc/max-ssrc/multiple- > render/whatever. > >> > >> Which do you want to mandate and why? > >> > >> Cheers, > >> Mo > >> > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Tuesday, July 02, 2013 10:06 AM > >> To: Mo Zanaty (mzanaty) > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > map received data to m- line? > >> > >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: > >>> Informative descriptions of possible mappings are fine, but = nothing > normative, please. Some applications won't care about the mapping, and > others may care but use a different mapping from those described. The > only normative statement you could make is something like: "If you = care > about the mapping, you MUST have a mapping mechanism. You MAY use the > mechanism(s) described here, or some other mechanism." But why mandate > such a tautology? > >>> > >>> The assumption below that multiple m-lines always require = different > m-line-specific processing of the packets also assumes Plan B, i.e. > that multiple streams with similar processing should always be = signaled > with a single m-line (for example, using a=3Dssrc or max-ssrc). Plan A > purists would use multiple m-lines even for multiple streams with the > same processing. I don't think we want to force bundle to pick a plan. > >> > >> I'm going to keep asking this question until I get an answer that > >> makes > >> sense: > >> > >> Please explain to me a meaningful situation when there are multiple > m-lines in a bundle and there is insufficient information to associate > each packet with an m-line. > >> > >> The *point* of plan A is that there be an m-line per "flow", and > that the offerer is enumerating the flows. So clearly it knows the > mapping. > >> If the answerer isn't capable of doing the same mapping, then the > use of plan A has failed. > >> > >> The part that I want to be normative is that an O/A is not valid > unless the mapping is possible with the information in the O/A, and > that the offerer and the answerer would agree about the mapping of = each > packet. I don't care if they actually do the mapping, though if they > are doing any sensible processing then they will be doing something > *equivalent* to the mapping. > >> > >> Thanks, > >> Paul > >> > >>> Mo > >>> > >>> -----Original Message----- > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: Saturday, June 29, 2013 12:12 PM > >>> To: mmusic@ietf.org > >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism = to > map received data to m- line? > >>> > >>> On 6/29/13 8:50 AM, Colin Perkins wrote: > >>>> Christer, > >>>> > >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: > >>>>> There has been some discussions about whether BUNDLE should > mandate that users are mandated to always (no matter what transport > protocols are used in the BUNDLE group) have a mechanism to map > received data to an m- line, or whether it from a generic BUNDLE > perspective should be optional - IF there would be cases where it's = not > needed. > >>>>> > >>>>> We haven't had that much discussion about it yet, so I will not > >>>>> ask a DECISION question at this point, but I would really like = to > >>>>> get some input from people who have opinions about this :) > >>>> > >>>> My opinion: BUNDLE needs to mandate a single algorithm for = mapping > from RTP flows to m=3D lines, for those applications that care about = such > a mapping. I don't think it should mandate that all applications need > to care. > >>> > >>> I just replied elsewhere on this. > >>> My opinion turns out to be the exact opposite of yours: we need to > >>> support multiple algorithms, and that all applications should = care. > >>> > >>> I won't repeat the stuff about multiple algorithms. > >>> > >>> I will repeat what I have said about the need for being able to > associate: > >>> > >>> There must have been *some* reason that two m-lines were used, > >>> rather than just one. Each m-line heads a media section of the SDP > >>> that contains a bunch of declarations. Something must be different > >>> in those two media sections, or else a single media section would > >>> have been enough. Presumably whatever it is that is different is > >>> intended to affect how received packets are processed or > >>> interpreted. (If not, again there is no need for it to be there.) > If > >>> you can't associate the packet with the m-line, then you don't = know > >>> which of the multiple interpretations to apply to the packet. > >>> > >>> Maybe there is some exception to this, though I haven't come up > with > >>> anything. If there is, then I hope someone will call it out. If = so, > >>> then the constraint can be tightened. > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Wed Jul 3 10:20: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 58A4421F9DD7 for ; Wed, 3 Jul 2013 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 lXjo0WcLrxtx for ; Wed, 3 Jul 2013 10:20:41 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id E149C21F9DD5 for ; Wed, 3 Jul 2013 10:20:40 -0700 (PDT) Received: from userPC (unknown [122.179.83.161]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2CDFE14D8093; Wed, 3 Jul 2013 17:20:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372872038; bh=z0BoLrzrQ7ucchF2XVq0qHcGzIWjIMjgPU4xeniIQYM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YoWY2YodlYdP5N71Rc2CrDjV/JLaZ40PAIkk8XQnI5Tlpp58fvHU2uVH98jc0rmx0 P+l9fLRv2JK6Pkd35Tcp5EW4ORX4sy5OZeLIrvnwoI9Vd3OOpqUYuP3xE3YOYgRIHS +rOzl1dSronSlVNN2G5FRin2A0KcOnjhJvMqHSUg= From: "Parthasarathi R" To: "'Parthasarathi R'" , "'Christer Holmberg'" , "'Mo Zanaty \(mzanaty\)'" , "'Paul Kyzivat'" References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> <00e101ce780a$d189acf0$749d06d0$@co.in> In-Reply-To: <00e101ce780a$d189acf0$749d06d0$@co.in> Date: Wed, 3 Jul 2013 22:50:21 +0530 Message-ID: <00e501ce7811$a02bb840$e08328c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkP//9/UAgAAJMwCAACOCgIAAa/cA//+5UED//tlUkP/9q9vg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51D45D66.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 17:20:45 -0000 Hi Christer, Sorry, label attribute shall be used to distinguish in application layer only and not on RTP layer demux as label is not possible to be pushed in = the RTP session. AFAIK, the proposal to use SSRC or CNAME for distinguishing the RTP = streams are discussed in SIPREC but both are not selected. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Parthasarathi R > Sent: Wednesday, July 03, 2013 10:02 PM > To: 'Christer Holmberg'; 'Mo Zanaty (mzanaty)'; 'Paul Kyzivat' > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to = map > received data to m- line? >=20 > Hi all, >=20 > In case BUNDLE, the same type of =93m=94 lines shall be diffentiated = by SDP > label attribute? I'm asking this question as I heard that SSRC in RTP > is not > created to differentiate RTP session. >=20 > In fact in SIPREC, the label attribute is used to differentiate the = two > different "m" line of the same type. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Wednesday, July 03, 2013 12:57 PM > > To: Mo Zanaty (mzanaty); Paul Kyzivat > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > map > > received data to m- line? > > > > Hi Mo, > > > > I think what you are saying is that you want to have one thumbnail > flow > > per m- line. So far so good. > > > > And, WITHOUT BUNDLE, you would be able to demux the flows based on > the > > 5-tuple (as each m- line would have a unique address:port). So far = go > > good. > > > > But, in your example, WITH BUNDLE, all 4 m- lines share the same 5- > > tuple, so if you want to demux the streams you need to have SOME > other > > mechanism than the 5-tuple. Will you demux based on SSRC? > > > > Regards, > > > > Christer > > > > > > > > > > > > > > -----Alkuper=E4inen viesti----- > > L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > > L=E4hetetty: 3. hein=E4kuuta 2013 8:07 > > Vastaanottaja: Paul Kyzivat > > Kopio: Christer Holmberg; mmusic@ietf.org > > Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > > map received data to m- line? > > > > To clarify, I have no plan to use or abuse Plan A. The > implementations > > I'm most interested in are all closer to Plan B. However, I'm aware > of > > widely deployed implementations (from other vendors) which are = closer > > to Plan A in general, and specifically for the thumbnail example > below > > (one m-line per thumbnail, all with the same port/PT). While I > > personally would not chose this, I see no reason to forbid it, > because > > I recognize it is just personal preference. > > > > Mo > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Tuesday, July 02, 2013 6:40 PM > > To: Mo Zanaty (mzanaty) > > Cc: Christer Holmberg; mmusic@ietf.org > > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism > to > > map received data to m- line? > > > > On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: > > >> You could mandate that multiple m-lines of thumbnails must be > > combined into a single m-line with a=3Dssrc/max-ssrc/multiple- > > render/whatever. > > > > > > It seems you both want to mandate this (Plan B). Why? I see no > reason > > for bundle to pick a plan. Let the plan wars rage outside bundle. > > > > So you want to use plan A *without* the association, so that the > *only* > > purpose of the extra m-lines is to denote the number of flows? > > > > How would the receiver know if an incoming packet was associated = with > > one of the flows defined by the m-lines? > > > > How would the receiver know if each ssrc should be treated as a > > different flow, or if appid should be used to define flows? > > > > I think you abuse plan A. Its different with plan B or No Plan. = There > > you still need the ability to associate packets to m-lines, but that > > isn't sufficient to map them to flows. It is assumed that "extra" > > information, learned by different means, is used to sort out the > flows. > > > > Thanks, > > Paul > > > > > Mo > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > Sent: Tuesday, July 02, 2013 4:00 PM > > > To: Christer Holmberg > > > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > > > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate > mechanism > > to map received data to m- line? > > > > > > +1 > > > (Except that I *am* Paul) > > > > > > On 7/2/13 2:30 PM, Christer Holmberg wrote: > > >> Hi, > > >> > > >> I am not Paul, but just to verify that I understand his issue, = the > > question is: > > >> > > >> Why do you need 4 m- lines for the thumbnails, when you could use > 1 > > m- line? > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> -----Alkuper=E4inen viesti----- > > >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic- > bounces@ietf.org] > > >> Puolesta Mo Zanaty (mzanaty) > > >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 > > >> Vastaanottaja: Paul Kyzivat > > >> Kopio: mmusic@ietf.org > > >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > map > > received data to m- line? > > >> > > >> An attempt at "an answer that makes sense". (Just snippets, not > full > > >> SDP.) > > >> > > >> m=3Dvideo 10000 RTP/SAVPF 96 > > >> a=3Drtpmap:96 H264/90000 > > >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker > > >> > > >> m=3Dvideo 10000 RTP/SAVPF 97 > > >> a=3Drtpmap:97 H264/90000 > > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > > a=3Drecvonly > > >> > > >> m=3Dvideo 10000 RTP/SAVPF 97 > > >> a=3Drtpmap:97 H264/90000 > > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > > a=3Drecvonly > > >> > > >> m=3Dvideo 10000 RTP/SAVPF 97 > > >> a=3Drtpmap:97 H264/90000 > > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > > a=3Drecvonly > > >> > > >> m=3Dvideo 10000 RTP/SAVPF 97 > > >> a=3Drtpmap:97 H264/90000 > > >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail > > a=3Drecvonly > > >> > > >> No need to map thumbnail packets to specific m-lines, so reuse of > > PT=3D97 is fine. Just render the last 4 thumbnail sources received = (in > > addition to the main speaker). > > >> > > >> You could mandate that PT must be unique to allow unique mapping. > > >> > > >> You could mandate that multiple m-lines of thumbnails must be > > combined into a single m-line with a=3Dssrc/max-ssrc/multiple- > > render/whatever. > > >> > > >> Which do you want to mandate and why? > > >> > > >> Cheers, > > >> Mo > > >> > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >> Sent: Tuesday, July 02, 2013 10:06 AM > > >> To: Mo Zanaty (mzanaty) > > >> Cc: mmusic@ietf.org > > >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism > to > > map received data to m- line? > > >> > > >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: > > >>> Informative descriptions of possible mappings are fine, but > nothing > > normative, please. Some applications won't care about the mapping, > and > > others may care but use a different mapping from those described. = The > > only normative statement you could make is something like: "If you > care > > about the mapping, you MUST have a mapping mechanism. You MAY use = the > > mechanism(s) described here, or some other mechanism." But why > mandate > > such a tautology? > > >>> > > >>> The assumption below that multiple m-lines always require > different > > m-line-specific processing of the packets also assumes Plan B, i.e. > > that multiple streams with similar processing should always be > signaled > > with a single m-line (for example, using a=3Dssrc or max-ssrc). Plan = A > > purists would use multiple m-lines even for multiple streams with = the > > same processing. I don't think we want to force bundle to pick a > plan. > > >> > > >> I'm going to keep asking this question until I get an answer that > > >> makes > > >> sense: > > >> > > >> Please explain to me a meaningful situation when there are > multiple > > m-lines in a bundle and there is insufficient information to > associate > > each packet with an m-line. > > >> > > >> The *point* of plan A is that there be an m-line per "flow", and > > that the offerer is enumerating the flows. So clearly it knows the > > mapping. > > >> If the answerer isn't capable of doing the same mapping, then the > > use of plan A has failed. > > >> > > >> The part that I want to be normative is that an O/A is not valid > > unless the mapping is possible with the information in the O/A, and > > that the offerer and the answerer would agree about the mapping of > each > > packet. I don't care if they actually do the mapping, though if they > > are doing any sensible processing then they will be doing something > > *equivalent* to the mapping. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Mo > > >>> > > >>> -----Original Message----- > > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] = On > > >>> Behalf Of Paul Kyzivat > > >>> Sent: Saturday, June 29, 2013 12:12 PM > > >>> To: mmusic@ietf.org > > >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism > to > > map received data to m- line? > > >>> > > >>> On 6/29/13 8:50 AM, Colin Perkins wrote: > > >>>> Christer, > > >>>> > > >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: > > >>>>> There has been some discussions about whether BUNDLE should > > mandate that users are mandated to always (no matter what transport > > protocols are used in the BUNDLE group) have a mechanism to map > > received data to an m- line, or whether it from a generic BUNDLE > > perspective should be optional - IF there would be cases where it's > not > > needed. > > >>>>> > > >>>>> We haven't had that much discussion about it yet, so I will = not > > >>>>> ask a DECISION question at this point, but I would really like > to > > >>>>> get some input from people who have opinions about this :) > > >>>> > > >>>> My opinion: BUNDLE needs to mandate a single algorithm for > mapping > > from RTP flows to m=3D lines, for those applications that care about > such > > a mapping. I don't think it should mandate that all applications = need > > to care. > > >>> > > >>> I just replied elsewhere on this. > > >>> My opinion turns out to be the exact opposite of yours: we need > to > > >>> support multiple algorithms, and that all applications should > care. > > >>> > > >>> I won't repeat the stuff about multiple algorithms. > > >>> > > >>> I will repeat what I have said about the need for being able to > > associate: > > >>> > > >>> There must have been *some* reason that two m-lines were used, > > >>> rather than just one. Each m-line heads a media section of the > SDP > > >>> that contains a bunch of declarations. Something must be > different > > >>> in those two media sections, or else a single media section = would > > >>> have been enough. Presumably whatever it is that is different is > > >>> intended to affect how received packets are processed or > > >>> interpreted. (If not, again there is no need for it to be = there.) > > If > > >>> you can't associate the packet with the m-line, then you don't > know > > >>> which of the multiple interpretations to apply to the packet. > > >>> > > >>> Maybe there is some exception to this, though I haven't come up > > with > > >>> anything. If there is, then I hope someone will call it out. If > so, > > >>> then the constraint can be tightened. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>> > > >>> _______________________________________________ > > >>> mmusic mailing list > > >>> mmusic@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mmusic > > >>> > > >> > > >> _______________________________________________ > > >> mmusic mailing list > > >> mmusic@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mmusic > > >> > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Wed Jul 3 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 782CF21F8474 for ; Wed, 3 Jul 2013 10:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, 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 X5mnNAio5Rdz for ; Wed, 3 Jul 2013 10:29:10 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA5A11E80E9 for ; Wed, 3 Jul 2013 10:29:09 -0700 (PDT) Received: from userPC (unknown [122.179.83.161]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 5120B8686B0; Wed, 3 Jul 2013 17:29:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372872549; bh=RXA02KIt7OuNhsSG7UMkzGzjPHk2B7EwroffHVP1cCU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LYh9C8Ps8BMU0NXQyUHIWRI6PP2zu+MNYc/wuX08MLrH5ub2zR9Ksod6V520UcKcv 4Fip4JSkPrMdzscFokcUxAQzOySwNoVr7pJEhzESRx8OhqtkrL4zcaO/DJHqA08RbJ JLYgg6DpEovKdH0GUTcpQUe8CZYM6OlKWj+tmBe4= From: "Parthasarathi R" To: , , References: <19821_1372321344_51CBF63F_19821_1932_3_719DF432C01EA6418EBA5185063A16610D006F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <19821_1372321344_51CBF63F_19821_1932_3_719DF432C01EA6418EBA5185063A16610D006F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 3 Jul 2013 22:58:59 +0530 Message-ID: <00e701ce7812$d10cbb20$73263160$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5zD3LDp2qz/2AGQwu/7apfDc5rAAE/8RsQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0203.51D45F65.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-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, 03 Jul 2013 17:29:14 -0000 Hi Aurelien, Sorry for the delay response. Thanks for the review comments. Please read inline. Thanks Partha > -----Original Message----- > From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] > Sent: Thursday, June 27, 2013 1:52 PM > To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in > Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 > > Hi > > I reviewed draft-ietf-mmusic-sdp-g723-g729-03 and I have some comments. > They are quite symmetrical between G723 and G729. > > > ** Section 3 > > 1) > ----- > Based on the above, it is best not to use comfort noise frames if > the > SDP offer or answer indicates that comfort noise is not supported. > ----- > The words "it is best not to use" are not strong enough, because it can > not work if one of the party do not support comfort noise frames (SID > frames in the ITU-T Annexes specs). It is rather a "MUST NOT use". > > The word "restrict the use" in the RFC3551 quote is to be interpreted > as "forbid the use". > It is fine. We will add this as a normative statement in case no objection > > > ** Section 3.1 > > 2) > After the first paragraph, I suggest to insert the new paragraph below: > > ---NEW > The Annex A of the codec concerns both sending and receiving, so both > sides of a bi-directional session MUST have the same setting. If > one party indicates that it does not support Annex A, Annex A must be > deactivated both ways. > ----- > That defines the general rationale of the following paragraphs. > I agree with that it is the objective of this O/A requirement but how this statement qualifies for normative statement is not clear. From the offerer perspective, there is no control on same setting in both sides. In case you look at the combine requirements of this draft, this object is met. > > 3) > ----- > When the offer has G723 with annexa=no then the answer MUST NOT have > annexa=yes for G723. Thus the annexa parameter can be turned off by > the answerer, but cannot be turned on. > ----- > I don't think this new requirement is needed. > Anyway implementation that will not implement this RFC-to-be will not > comply with it. > As per based G723 RFC, it is expected for all the implementation to support annexa. This issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html > Plus, with the following paragraph, it breaks the equivalence between > annexa=yes and annexa omitted. > > Note that RFC3264 allows the SDP answer to include media format that > are not present in the SDP offer, so it could be the same for the Annex > A support. > RFC 3264 recommends to define offer/answer behavior per media format whereas it is not defined for G723 & G729 and it is addressed as part of this draft > > 4) > ----- > When the offer has G723 with annexa=no, the reason for not mandating > that the answer MUST have annexa=no for G723 is that there are there > implementations that omit the annexa parameter in answer and expect > the least common denominator to be used. > ----- > > Add the following sentence at the end of the paragraph, to be explicit > about the "least common denominator": > In such cases the offerer and answerer MUST proceed as if G723 is > negotiated with annexa=no. > Agreed. We will update the text > > > ** Section 3.2 > > 5) > After the first two paragraphs, I suggest to insert the new paragraph > below: > > ---NEW > The Annex B of the codec concerns both sending and receiving, so both > sides of a bi-directional session MUST have the same setting. If > one party indicates that it does not support Annex B, Annex B must be > deactivated both ways. > ----- > That defines the general rationale of the following paragraphs. > Same as comment 2 reply. I agree with that it is the objective of this O/A requirement but how this statement qualifies for normative statement is not clear. From the offerer perspective, there is no control on same setting in both sides. In case you look at the combine requirements of this draft, this object is met. > > 6) > ----- > When the offer or answer has G729 and the annexb parameter is > absent, > it MUST be considered as if the offer or answer has G729 with > annexb=yes. > ----- > This paragraph is redundant with what is said before. > Remove it. > > As per based G729 RFC, it is expected for all the implementation to support annexb. This issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html > 7) > ----- > When the offer has G729 with annexb=no then the answer MUST NOT have > annexb=yes for G729. Thus the annexb parameter can be turned off by > the answerer, but cannot be turned on. > ----- > I don't think this new requirement is needed. > For the same reason as for G723 > Same reply as comment 3. As per based G729 RFC, it is expected for all the implementation to support annexb. This issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html > > 8) > ----- > When the offer has G729 with annexa=no, the reason for not mandating > that the answer MUST have annexa=no for G729 is that there are there > implementations that omit the annexa parameter in answer and expect > the least common denominator to be used. > ----- > > Replace annexa by annexb (copy/paste error I guess) > Agreed > And add the following sentence at the end of the paragraph, to be > explicit about the "least common denominator": > In such cases the offerer and answerer MUST proceed as if G729 is > negotiated with annexb=no. > Agreed > > > Best regards, > Aurelien > > > _______________________________________________________________________ > __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. From mzanaty@cisco.com Wed Jul 3 11: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 39DCE11E8203 for ; Wed, 3 Jul 2013 11:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 wXvepUmMVexd for ; Wed, 3 Jul 2013 11:17:31 -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 F10CC11E81CD for ; Wed, 3 Jul 2013 11:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10838; q=dns/txt; s=iport; t=1372875437; x=1374085037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c6NMfhMzDVayDfTRtMHdE3BWkJSN5iMev+4sDvXwLqI=; b=Rwmp6MkH4+slXle5SYeoRFG4QZIvWy0R7aUXYFCT6M66UxNrFuEbuwW6 Y4QpAYPyfTHEdFN75x35MVWBaqCK/RDhcir6wBr9fyO5/bCxzLJG1I+N1 kk28i+Y8fcQWhx5deASRVlsYYqizeCVmy9q6SeR92/NT5SbwLLXJz4LlD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAD5q1FGtJV2d/2dsb2JhbABaDoJ7MknANYEEFnSCIwEBAQMBAQEBCWILBQcEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCIgBBgy6OQSPOjEHBoJ+aQOIa6AjgVh7PoIo X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="230748032" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2013 18:17:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63IHE14001147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 18:17:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 13:17:14 -0500 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg , Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: AQHOdON5iUTc8DI+/Em0svjaZWQNnJlPEy+AgAKxRwD//7wNkIAAjfgAgAAZDgD//7QIEIAAeK2AgAAEm8CAAI58AIAAXRfQ Date: Wed, 3 Jul 2013 18:17:13 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48E8EE@xmb-rcd-x14.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Wed, 03 Jul 2013 18:17:41 -0000 Hi Christer, If by "demux" you mean classify as separate RTP streams, then yes, that is = always by SSRC (regardless of SDP). If by "demux" you mean map to unique SDP m-lines for unique context of othe= r attributes, that unique context is not always necessary for all apps, hen= ce why I prefer not mandating this. I think you worded it well: "if you want to demux the streams you need to h= ave SOME other mechanism". Emphasis on "if" (when demux refers to mapping t= o unique SDP m-lines). This would be fine to mandate if you include the "if= ". Cheers, Mo -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, July 03, 2013 3:27 AM To: Mo Zanaty (mzanaty); Paul Kyzivat Cc: mmusic@ietf.org Subject: VS: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? Hi Mo, I think what you are saying is that you want to have one thumbnail flow per= m- line. So far so good. And, WITHOUT BUNDLE, you would be able to demux the flows based on the 5-tu= ple (as each m- line would have a unique address:port). So far go good. But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-tuple, s= o if you want to demux the streams you need to have SOME other mechanism th= an the 5-tuple. Will you demux based on SSRC? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]=20 L=E4hetetty: 3. hein=E4kuuta 2013 8:07 Vastaanottaja: Paul Kyzivat Kopio: Christer Holmberg; mmusic@ietf.org Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map re= ceived data to m- line? To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per t= humbnail, all with the same port/PT). While I personally would not chose th= is, I see no reason to forbid it, because I recognize it is just personal p= reference. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, July 02, 2013 6:40 PM To: Mo Zanaty (mzanaty) Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for= bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only* pur= pose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with one o= f the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a different f= low, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There you s= till need the ability to associate packets to m-lines, but that isn't suffi= cient to map them to flows. It is assumed that "extra"=20 information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the quest= ion is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- l= ine? >> >> Regards, >> >> Christer >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ]=20 >> Puolesta Mo Zanaty (mzanaty) >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full=20 >> SDP.) >> >> m=3Dvideo 10000 RTP/SAVPF 96 >> a=3Drtpmap:96 H264/90000 >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=3D9= 7 is fine. Just render the last 4 thumbnail sources received (in addition t= o the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing nor= mative, please. Some applications won't care about the mapping, and others = may care but use a different mapping from those described. The only normati= ve statement you could make is something like: "If you care about the mappi= ng, you MUST have a mapping mechanism. You MAY use the mechanism(s) describ= ed here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-l= ine-specific processing of the packets also assumes Plan B, i.e. that multi= ple streams with similar processing should always be signaled with a single= m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use= multiple m-lines even for multiple streams with the same processing. I don= 't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that=20 >> makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-li= nes in a bundle and there is insufficient information to associate each pac= ket with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that th= e offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of= plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless = the mapping is possible with the information in the O/A, and that the offer= er and the answerer would agree about the mapping of each packet. I don't c= are if they actually do the mapping, though if they are doing any sensible = processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate t= hat users are mandated to always (no matter what transport protocols are us= ed in the BUNDLE group) have a mechanism to map received data to an m- line= , or whether it from a generic BUNDLE perspective should be optional - IF t= here would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not=20 >>>>> ask a DECISION question at this point, but I would really like to=20 >>>>> get some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping fro= m RTP flows to m=3D lines, for those applications that care about such a ma= pping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to=20 >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associa= te: >>> >>> There must have been *some* reason that two m-lines were used,=20 >>> rather than just one. Each m-line heads a media section of the SDP=20 >>> that contains a bunch of declarations. Something must be different=20 >>> in those two media sections, or else a single media section would=20 >>> have been enough. Presumably whatever it is that is different is=20 >>> intended to affect how received packets are processed or=20 >>> interpreted. (If not, again there is no need for it to be there.) If=20 >>> you can't associate the packet with the m-line, then you don't know=20 >>> which of the multiple interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with=20 >>> anything. If there is, then I hope someone will call it out. If so,=20 >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > From dwing@cisco.com Wed Jul 3 12: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 9115811E821E for ; Wed, 3 Jul 2013 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 iRyLCfo-bfSw for ; Wed, 3 Jul 2013 12:01:55 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8A11E8221 for ; Wed, 3 Jul 2013 12:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3314; q=dns/txt; s=iport; t=1372878107; x=1374087707; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oM7l2byjw4n12r2zdxGixgBMiraAvGOSvVlELQiLAG4=; b=Wg/505QoXaRPSvnt2BKq4GKTIIgp8I0vXEmTfZerj4b43KdPX9RgbBWe SVil2xbjas7wt6Nijfy3t/ry1YcFh/t4fAfc2QTxF6JW3dowqInTmi7Bk JhVNg68OQUfy3CRdiGWN9jtKEtVhjlluxUdNkzNQ93nHzCpjHPnHLFRXj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFABp01FGrRDoG/2dsb2JhbABagwkywQCBBhZ0giMBAQEDAQEBATc0CwULCw44JzAGE4gJBQ26FQSOKIEQMweDBGkDiSOKVINSkUWDMRw X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="85214316" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 03 Jul 2013 19:01:47 +0000 Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r63J1kLT014443; Wed, 3 Jul 2013 19:01:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <51D43186.2010907@jitsi.org> Date: Wed, 3 Jul 2013 12:01:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51D43186.2010907@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1508) Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 03 Jul 2013 19:01:59 -0000 On Jul 3, 2013, at 7:13 AM, Emil Ivov wrote: > Hey all, >=20 > Christer, Enrico and I are preparing the next version of Trickle ICE = for SIP. Now that discussions on BUNDLE and the plans seem to be winding = down, we wanted to run a few questions by the working group. >=20 > Q1: Making reliable provisional responses and PRACK mandatory. = Obviously this would be nice to avoid, so the question is: is there a = reasonable mechanism to achieve this (and by reasonable, we mean = something that wouldn't be harder than implementing support for PRACK). >=20 > There was some discussion about this back in April and there was a = suggestion for implementing a 5245-style hack where the answerer = basically resends the 180 until it knows that it has been received. >=20 > 5245 uses connectivity checks for this (i.e. it stops 180 = retransmissions when the first connectivity check is received) but we = don't have that option here since the 180 may contain either none or = only host candidates so there are strong chances that no binding request = would be received on them. I might work, because each re-transmission would probably have = additional candidates (because the STUN/TURN transactions will have = completed), and thus more likely that those re-transmissions (containing = those additional candidates) would result in the remote endpoint sending = a STUN binding request. -d > Thomas also suggested a second option which would be to also use INFO = requests with trickled candidates as an indication that 180 was = received. This however wouldn't work with half trickle so we are = basically back to vanilla ICE for all (non-re) INVITEs. >=20 > Another option would be to mandate an INFO request with = "end-of-candidates" in response to the 180, but that would be just the = same as mandating PRACK support. >=20 > Thomas also suggested that the answerer can start sending INFOs right = after it sends its answer in the 180 and then it can just resend the 180 = if the INFOs result in a 481 response. >=20 > Personally I think this could potentially be made to work, but it = would imply a level of complexity that considerably exceeds PRACK = support. >=20 > Opinions? >=20 > Q2: How do we send INFOs? Are they blocking or do we just send them in = parallel? If the latter, then what happens when an INFO fails because it = is received out of order? Do we just tell the application to resend the = candidates asap? >=20 > This also leads to the following question: >=20 > Q3: What exactly do we send in INFOs? Just the latest batch of freshly = learned candidates or all candidates we've learned so far? Dale = suggested that if we do this cumulatively we wouldn't need to worry = about the case with the out-of-order INFOs from Q2 since the information = gets resent anyway. A drawback here would obviously be that this adds = more complexity for trickle ICE users (WebRTC applications specifically) >=20 > A third option would be to allow both and leave it to the application. >=20 > Comments are most welcome! >=20 > Emil >=20 > --=20 > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Wed Jul 3 12:29: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 A77AE21F854E for ; Wed, 3 Jul 2013 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33-Zgtq1IHGh for ; Wed, 3 Jul 2013 12:29:22 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D139021F99BB for ; Wed, 3 Jul 2013 12:29:21 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so450169wes.17 for ; Wed, 03 Jul 2013 12:29:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=v8cvW4f9cRAnnGmrlOdq8KgEyM9PXB2opxP1E1SAPqg=; b=EHxjcQINfBs2vgF2/T3iZZ0RdO+SNGrb4yRD5SHrqndT4Vx1CJstst85BWVgEr/C8V pcwXSXuzUPxiUuSUvJeL+YvPbQD7//35GdVSzXF8bM9InqWVf+IFQHvtqfj8Qi4CScA9 FzcuW1IvzY8yoLi7N01OJrJLdoeLSFf18UNM+LXwJP9Vv3URTfPKVq8CKMcqkt8NcIXL 67N4nGPveSwigLkWhHqV/64h90QZMEPvnbArAeK4zmDdVrSq8HW+tpxXEImbg9F+IV5Y b5zWoShFusBuLx0rZ8H69GLF6q6iKhwe8DSnTTJpMORQCDyL4cutiFLNxp4hNWQ6hHqn ld6Q== X-Received: by 10.180.207.43 with SMTP id lt11mr18915148wic.57.1372879760880; Wed, 03 Jul 2013 12:29:20 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:1deb:1465:36b2:68fe]) by mx.google.com with ESMTPSA id f8sm30507245wiv.0.2013.07.03.12.29.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 12:29:20 -0700 (PDT) Message-ID: <51D47B8E.1090200@jitsi.org> Date: Wed, 03 Jul 2013 21:29:18 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dan Wing References: <51D43186.2010907@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlKT2/KTEIE3X4/ZsU/WPI/FgyRUBouhfpCbjKsje2hvvUv0Q6lF0WJ7NCvNWulang8fDRy Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 03 Jul 2013 19:29:26 -0000 Hey Dan, On 03.07.13, 21:01, Dan Wing wrote: > > On Jul 3, 2013, at 7:13 AM, Emil Ivov wrote: > >> Hey all, >> >> Christer, Enrico and I are preparing the next version of Trickle >> ICE for SIP. Now that discussions on BUNDLE and the plans seem to >> be winding down, we wanted to run a few questions by the working >> group. >> >> Q1: Making reliable provisional responses and PRACK mandatory. >> Obviously this would be nice to avoid, so the question is: is there >> a reasonable mechanism to achieve this (and by reasonable, we mean >> something that wouldn't be harder than implementing support for >> PRACK). >> >> There was some discussion about this back in April and there was a >> suggestion for implementing a 5245-style hack where the answerer >> basically resends the 180 until it knows that it has been >> received. >> >> 5245 uses connectivity checks for this (i.e. it stops 180 >> retransmissions when the first connectivity check is received) but >> we don't have that option here since the 180 may contain either >> none or only host candidates so there are strong chances that no >> binding request would be received on them. > > I might work, because each re-transmission would probably have > additional candidates (because the STUN/TURN transactions will have > completed), and thus more likely that those re-transmissions > (containing those additional candidates) would result in the remote > endpoint sending a STUN binding request. If we do it cumulatively, then yes. We can then move to INFOs the moment we get either a first check (which would more often be the case with half trickle) or a first INFO request (which would be the case for full trickle). This could indeed work. However it would also imply that we keep sending candidates cumulatively even in the INFO requests since we wouldn't know how many of the 180s got through. This makes me slightly uncomfortable as it would imply that someone would have to maintain state on the sending side, and do a number of comparisons on the receiving side ... Emil -- https://jitsi.org >> Thomas also suggested a second option which would be to also use >> INFO requests with trickled candidates as an indication that 180 >> was received. This however wouldn't work with half trickle so we >> are basically back to vanilla ICE for all (non-re) INVITEs. >> >> Another option would be to mandate an INFO request with >> "end-of-candidates" in response to the 180, but that would be just >> the same as mandating PRACK support. >> >> Thomas also suggested that the answerer can start sending INFOs >> right after it sends its answer in the 180 and then it can just >> resend the 180 if the INFOs result in a 481 response. >> >> Personally I think this could potentially be made to work, but it >> would imply a level of complexity that considerably exceeds PRACK >> support. >> >> Opinions? >> >> Q2: How do we send INFOs? Are they blocking or do we just send them >> in parallel? If the latter, then what happens when an INFO fails >> because it is received out of order? Do we just tell the >> application to resend the candidates asap? >> >> This also leads to the following question: >> >> Q3: What exactly do we send in INFOs? Just the latest batch of >> freshly learned candidates or all candidates we've learned so far? >> Dale suggested that if we do this cumulatively we wouldn't need to >> worry about the case with the out-of-order INFOs from Q2 since the >> information gets resent anyway. A drawback here would obviously be >> that this adds more complexity for trickle ICE users (WebRTC >> applications specifically) >> >> A third option would be to allow both and leave it to the >> application. >> >> Comments are most welcome! >> >> Emil From christer.holmberg@ericsson.com Thu Jul 4 00:10: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 CE63F21F9EC1 for ; Thu, 4 Jul 2013 00:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.58 X-Spam-Level: X-Spam-Status: No, score=-4.58 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 im5+KR2nLHQn for ; Thu, 4 Jul 2013 00:10:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 705BD21F9E3D for ; Thu, 4 Jul 2013 00:10:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-9b-51d51feacdc7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 11.7C.06741.AEF15D15; Thu, 4 Jul 2013 09:10:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Thu, 4 Jul 2013 09:10:34 +0200 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Paul Kyzivat Thread-Topic: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? Thread-Index: Ac5xlSdsNUfHWYPzSBOEmKK71uD2NADIVT0AAAcMPAAASg9YAABIYeQAAARQU4AACRNlkP//9/UAgAAJMwCAACOCgIAAa/cA//+5UECAASOagIAA+Zke Date: Thu, 4 Jul 2013 07:10:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3C2DE2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C1CD1@ESESSMB209.ericsson.se>, <3879D71E758A7E4AA99A35DD8D41D3D91D48E8EE@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48E8EE@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3C2DE2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre4r+auBBvfP21hMXf6YxeLFgzlM Fis2HGB1YPb4+/4Dk8eU3xtZPZYs+ckUwBzFZZOSmpNZllqkb5fAlXFxax9jwYZLjBWrP59i aWA8s46xi5GTQ0LAROLtmSYoW0ziwr31bF2MXBxCAocZJVbf7mOBcBYySqxfu4ypi5GDg03A QqL7nzZIg4hAqMSGpRtYQGxmAVWJ11O/s4LYwgLpElderGGBqMmQmHvhHSvIHBGBJkaJi3d7 2UDmsAioSCzbAbaYV8BX4v+kP6wQu+6zSrx5e4AdJMEJlNh5+BCYzQh03fdTa5gglolL3Hoy nwniagGJJXvOM0PYohIvH/9jhajJl7gzZTkzxAJBiZMzn7BMYBSZhaR9FpKyWUjKIOJ6Ejem TmGDsLUlli18zQxh60rM+HeIBVl8ASP7Kkb23MTMnPRyw02MwKg6uOW37g7GU+dEDjFKc7Ao ifNu0jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRPmVd/LrS406BZyVUbRXaOM73Xv10 5NGBwyfnds/PWJJ+81b/zPh7s+fyhnM9W3nWpT6v5FIk9+t5J3Xyt8a3+sb4r/OfvDr8o8mC zMe3LrdsFpjjvd0/raT7L2v3oWaje19mu3rZbJhprWs1XV2L7d4hZudL663PngjzSv+9x78z zJKFtZhFiaU4I9FQi7moOBEAetPqWXgCAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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, 04 Jul 2013 07:10:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3C2DE2ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I meant mapping to unique m- line :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Mo Zanaty (mzanaty) [mzanaty@cisco.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; Paul Kyzivat [pkyzi= vat@alum.mit.edu] CC: mmusic@ietf.org [mmusic@ietf.org] Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? Hi Christer, If by "demux" you mean classify as separate RTP streams, then yes, that is = always by SSRC (regardless of SDP). If by "demux" you mean map to unique SDP m-lines for unique context of othe= r attributes, that unique context is not always necessary for all apps, hen= ce why I prefer not mandating this. I think you worded it well: "if you want to demux the streams you need to h= ave SOME other mechanism". Emphasis on "if" (when demux refers to mapping t= o unique SDP m-lines). This would be fine to mandate if you include the "if= ". Cheers, Mo -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, July 03, 2013 3:27 AM To: Mo Zanaty (mzanaty); Paul Kyzivat Cc: mmusic@ietf.org Subject: VS: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? Hi Mo, I think what you are saying is that you want to have one thumbnail flow per= m- line. So far so good. And, WITHOUT BUNDLE, you would be able to demux the flows based on the 5-tu= ple (as each m- line would have a unique address:port). So far go good. But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-tuple, s= o if you want to demux the streams you need to have SOME other mechanism th= an the 5-tuple. Will you demux based on SSRC? Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] L=E4hetetty: 3. hein=E4kuuta 2013 8:07 Vastaanottaja: Paul Kyzivat Kopio: Christer Holmberg; mmusic@ietf.org Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map re= ceived data to m- line? To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per t= humbnail, all with the same port/PT). While I personally would not chose th= is, I see no reason to forbid it, because I recognize it is just personal p= reference. Mo -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Tuesday, July 02, 2013 6:40 PM To: Mo Zanaty (mzanaty) Cc: Christer Holmberg; mmusic@ietf.org Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. > > It seems you both want to mandate this (Plan B). Why? I see no reason for= bundle to pick a plan. Let the plan wars rage outside bundle. So you want to use plan A *without* the association, so that the *only* pur= pose of the extra m-lines is to denote the number of flows? How would the receiver know if an incoming packet was associated with one o= f the flows defined by the m-lines? How would the receiver know if each ssrc should be treated as a different f= low, or if appid should be used to define flows? I think you abuse plan A. Its different with plan B or No Plan. There you s= till need the ability to associate packets to m-lines, but that isn't suffi= cient to map them to flows. It is assumed that "extra" information, learned by different means, is used to sort out the flows. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 4:00 PM > To: Christer Holmberg > Cc: Mo Zanaty (mzanaty); mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line? > > +1 > (Except that I *am* Paul) > > On 7/2/13 2:30 PM, Christer Holmberg wrote: >> Hi, >> >> I am not Paul, but just to verify that I understand his issue, the quest= ion is: >> >> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- l= ine? >> >> Regards, >> >> Christer >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ] >> Puolesta Mo Zanaty (mzanaty) >> L=E4hetetty: 2. hein=E4kuuta 2013 19:09 >> Vastaanottaja: Paul Kyzivat >> Kopio: mmusic@ietf.org >> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map rec= eived data to m- line? >> >> An attempt at "an answer that makes sense". (Just snippets, not full >> SDP.) >> >> m=3Dvideo 10000 RTP/SAVPF 96 >> a=3Drtpmap:96 H264/90000 >> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speaker >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> m=3Dvideo 10000 RTP/SAVPF 97 >> a=3Drtpmap:97 H264/90000 >> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail a=3Drecvo= nly >> >> No need to map thumbnail packets to specific m-lines, so reuse of PT=3D9= 7 is fine. Just render the last 4 thumbnail sources received (in addition t= o the main speaker). >> >> You could mandate that PT must be unique to allow unique mapping. >> >> You could mandate that multiple m-lines of thumbnails must be combined i= nto a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever. >> >> Which do you want to mandate and why? >> >> Cheers, >> Mo >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 10:06 AM >> To: Mo Zanaty (mzanaty) >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map = received data to m- line? >> >> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>> Informative descriptions of possible mappings are fine, but nothing nor= mative, please. Some applications won't care about the mapping, and others = may care but use a different mapping from those described. The only normati= ve statement you could make is something like: "If you care about the mappi= ng, you MUST have a mapping mechanism. You MAY use the mechanism(s) describ= ed here, or some other mechanism." But why mandate such a tautology? >>> >>> The assumption below that multiple m-lines always require different m-l= ine-specific processing of the packets also assumes Plan B, i.e. that multi= ple streams with similar processing should always be signaled with a single= m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use= multiple m-lines even for multiple streams with the same processing. I don= 't think we want to force bundle to pick a plan. >> >> I'm going to keep asking this question until I get an answer that >> makes >> sense: >> >> Please explain to me a meaningful situation when there are multiple m-li= nes in a bundle and there is insufficient information to associate each pac= ket with an m-line. >> >> The *point* of plan A is that there be an m-line per "flow", and that th= e offerer is enumerating the flows. So clearly it knows the mapping. >> If the answerer isn't capable of doing the same mapping, then the use of= plan A has failed. >> >> The part that I want to be normative is that an O/A is not valid unless = the mapping is possible with the information in the O/A, and that the offer= er and the answerer would agree about the mapping of each packet. I don't c= are if they actually do the mapping, though if they are doing any sensible = processing then they will be doing something *equivalent* to the mapping. >> >> Thanks, >> Paul >> >>> Mo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 29, 2013 12:12 PM >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line? >>> >>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>> Christer, >>>> >>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>> There has been some discussions about whether BUNDLE should mandate t= hat users are mandated to always (no matter what transport protocols are us= ed in the BUNDLE group) have a mechanism to map received data to an m- line= , or whether it from a generic BUNDLE perspective should be optional - IF t= here would be cases where it's not needed. >>>>> >>>>> We haven't had that much discussion about it yet, so I will not >>>>> ask a DECISION question at this point, but I would really like to >>>>> get some input from people who have opinions about this :) >>>> >>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping fro= m RTP flows to m=3D lines, for those applications that care about such a ma= pping. I don't think it should mandate that all applications need to care. >>> >>> I just replied elsewhere on this. >>> My opinion turns out to be the exact opposite of yours: we need to >>> support multiple algorithms, and that all applications should care. >>> >>> I won't repeat the stuff about multiple algorithms. >>> >>> I will repeat what I have said about the need for being able to associa= te: >>> >>> There must have been *some* reason that two m-lines were used, >>> rather than just one. Each m-line heads a media section of the SDP >>> that contains a bunch of declarations. Something must be different >>> in those two media sections, or else a single media section would >>> have been enough. Presumably whatever it is that is different is >>> intended to affect how received packets are processed or >>> interpreted. (If not, again there is no need for it to be there.) If >>> you can't associate the packet with the m-line, then you don't know >>> which of the multiple interpretations to apply to the packet. >>> >>> Maybe there is some exception to this, though I haven't come up with >>> anything. If there is, then I hope someone will call it out. If so, >>> then the constraint can be tightened. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --_000_7594FB04B1934943A5C02806D1A2204B1C3C2DE2ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I meant mapping to unique m- line :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Mo Zanaty (mzanaty) [mzanaty@cisco.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; Paul Kyzivat= [pkyzivat@alum.mit.edu]
CC: mmusic@ietf.org [mmusic@ietf.org]
Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism= to map received data to m- line?
Hi Christer,

If by "demux" you mean classify as separate RTP streams, then yes= , that is always by SSRC (regardless of SDP).

If by "demux" you mean map to unique SDP m-lines for unique conte= xt of other attributes, that unique context is not always necessary for all= apps, hence why I prefer not mandating this.

I think you worded it well: "if you want to demux the streams you need= to have SOME other mechanism". Emphasis on "if" (when demux= refers to mapping to unique SDP m-lines). This would be fine to mandate if= you include the "if".

Cheers,
Mo

-----Original Message-----
From: Christer Holmberg [= mailto:christer.holmberg@ericsson.com]
Sent: Wednesday, July 03, 2013 3:27 AM
To: Mo Zanaty (mzanaty); Paul Kyzivat
Cc: mmusic@ietf.org
Subject: VS: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line?

Hi Mo,

I think what you are saying is that you want to have one thumbnail flow per= m- line. So far so good.

And, WITHOUT BUNDLE, you would be able to demux the flows based on the 5-tu= ple (as each m- line would have a unique address:port). So far go good.

But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-tuple, s= o if you want to demux the streams you need to have SOME other mechanism th= an the 5-tuple. Will you demux based on SSRC?

Regards,

Christer






-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Mo Zanaty (mzanaty) [= mailto:mzanaty@cisco.com]
L=E4hetetty: 3. hein=E4kuuta 2013 8:07
Vastaanottaja: Paul Kyzivat
Kopio: Christer Holmberg; mmusic@ietf.org
Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map re= ceived data to m- line?

To clarify, I have no plan to use or abuse Plan A. The implementations I'm = most interested in are all closer to Plan B. However, I'm aware of widely d= eployed implementations (from other vendors) which are closer to Plan A in = general, and specifically for the thumbnail example below (one m-line per thumbnail, all with the same port/= PT). While I personally would not chose this, I see no reason to forbid it,= because I recognize it is just personal preference.

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; mmusic@ietf.org
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map= received data to m- line?

On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote:
>> You could mandate that multiple m-lines of thumbnails must be comb= ined into a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever.<= br> >
> It seems you both want to mandate this (Plan B). Why? I see no reason = for bundle to pick a plan. Let the plan wars rage outside bundle.

So you want to use plan A *without* the association, so that the *only* pur= pose of the extra m-lines is to denote the number of flows?

How would the receiver know if an incoming packet was associated with one o= f the flows defined by the m-lines?

How would the receiver know if each ssrc should be treated as a different f= low, or if appid should be used to define flows?

I think you abuse plan A. Its different with plan B or No Plan. There you s= till need the ability to associate packets to m-lines, but that isn't suffi= cient to map them to flows. It is assumed that "extra"
information, learned by different means, is used to sort out the flows.

        Thanks,
        Paul

> Mo
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pk= yzivat@alum.mit.edu]
> Sent: Tuesday, July 02, 2013 4:00 PM
> To: Christer Holmberg
> Cc: Mo Zanaty (mzanaty); mmusic@ietf.org
> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism t= o map received data to m- line?
>
> +1
> (Except that I *am* Paul)
>
> On 7/2/13 2:30 PM, Christer Holmberg wrote:
>> Hi,
>>
>> I am not Paul, but just to verify that I understand his issue, the= question is:
>>
>> Why do you need 4 m- lines for the thumbnails, when you could use = 1 m- line?
>>
>> Regards,
>>
>> Christer
>>
>> -----Alkuper=E4inen viesti-----
>> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>> Puolesta Mo Zanaty (mzanaty)
>> L=E4hetetty: 2. hein=E4kuuta 2013 19:09
>> Vastaanottaja: Paul Kyzivat
>> Kopio: mmusic@ietf.org
>> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to m= ap received data to m- line?
>>
>> An attempt at "an answer that makes sense". (Just snippe= ts, not full
>> SDP.)
>>
>> m=3Dvideo 10000 RTP/SAVPF 96
>> a=3Drtpmap:96 H264/90000
>> a=3Dfmtp:96 profile-level-id=3D42001F <--- HD 720p30 main speak= er
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> m=3Dvideo 10000 RTP/SAVPF 97
>> a=3Drtpmap:97 H264/90000
>> a=3Dfmtp:97 profile-level-id=3D42000C <--- SD 240p15 thumbnail = a=3Drecvonly
>>
>> No need to map thumbnail packets to specific m-lines, so reuse of = PT=3D97 is fine. Just render the last 4 thumbnail sources received (in addi= tion to the main speaker).
>>
>> You could mandate that PT must be unique to allow unique mapping.<= br> >>
>> You could mandate that multiple m-lines of thumbnails must be comb= ined into a single m-line with a=3Dssrc/max-ssrc/multiple-render/whatever.<= br> >>
>> Which do you want to mandate and why?
>>
>> Cheers,
>> Mo
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailt= o:pkyzivat@alum.mit.edu]
>> Sent: Tuesday, July 02, 2013 10:06 AM
>> To: Mo Zanaty (mzanaty)
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism t= o map received data to m- line?
>>
>> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote:
>>> Informative descriptions of possible mappings are fine, but no= thing normative, please. Some applications won't care about the mapping, an= d others may care but use a different mapping from those described. The onl= y normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechani= sm. You MAY use the mechanism(s) described here, or some other mechanism.&q= uot; But why mandate such a tautology?
>>>
>>> The assumption below that multiple m-lines always require diff= erent m-line-specific processing of the packets also assumes Plan B, i.e. t= hat multiple streams with similar processing should always be signaled with= a single m-line (for example, using a=3Dssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple = streams with the same processing. I don't think we want to force bundle to = pick a plan.
>>
>> I'm going to keep asking this question until I get an answer that =
>> makes
>> sense:
>>
>> Please explain to me a meaningful situation when there are multipl= e m-lines in a bundle and there is insufficient information to associate ea= ch packet with an m-line.
>>
>> The *point* of plan A is that there be an m-line per "flow&qu= ot;, and that the offerer is enumerating the flows. So clearly it knows the= mapping.
>> If the answerer isn't capable of doing the same mapping, then the = use of plan A has failed.
>>
>> The part that I want to be normative is that an O/A is not valid u= nless the mapping is possible with the information in the O/A, and that the= offerer and the answerer would agree about the mapping of each packet. I d= on't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing s= omething *equivalent* to the mapping.
>>
>>       Thanks,
>>       Paul
>>
>>> Mo
>>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>> Behalf Of Paul Kyzivat
>>> Sent: Saturday, June 29, 2013 12:12 PM
>>> To: mmusic@ietf.org
>>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechani= sm to map received data to m- line?
>>>
>>> On 6/29/13 8:50 AM, Colin Perkins wrote:
>>>> Christer,
>>>>
>>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
>>>>> There has been some discussions about whether BUNDLE s= hould mandate that users are mandated to always (no matter what transport p= rotocols are used in the BUNDLE group) have a mechanism to map received dat= a to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not ne= eded.
>>>>>
>>>>> We haven't had that much discussion about it yet, so I= will not
>>>>> ask a DECISION question at this point, but I would rea= lly like to
>>>>> get some input from people who have opinions about thi= s :)
>>>>
>>>> My opinion: BUNDLE needs to mandate a single algorithm for= mapping from RTP flows to m=3D lines, for those applications that care abo= ut such a mapping. I don't think it should mandate that all applications ne= ed to care.
>>>
>>> I just replied elsewhere on this.
>>> My opinion turns out to be the exact opposite of yours: we nee= d to
>>> support multiple algorithms, and that all applications should = care.
>>>
>>> I won't repeat the stuff about multiple algorithms.
>>>
>>> I will repeat what I have said about the need for being able t= o associate:
>>>
>>> There must have been *some* reason that two m-lines were used,=
>>> rather than just one. Each m-line heads a media section of the= SDP
>>> that contains a bunch of declarations. Something must be diffe= rent
>>> in those two media sections, or else a single media section wo= uld
>>> have been enough. Presumably whatever it is that is different = is
>>> intended to affect how received packets are processed or
>>> interpreted. (If not, again there is no need for it to be ther= e.) If
>>> you can't associate the packet with the m-line, then you don't= know
>>> which of the multiple interpretations to apply to the packet.<= br> >>>
>>> Maybe there is some exception to this, though I haven't come u= p with
>>> anything. If there is, then I hope someone will call it out. I= f so,
>>> then the constraint can be tightened.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https= ://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/mmusic
>>
>
>

 --_000_7594FB04B1934943A5C02806D1A2204B1C3C2DE2ESESSMB209erics_-- From aurelien.sollaud@orange.com Thu Jul 4 03:14: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 2553D21F8426 for ; Thu, 4 Jul 2013 03:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 bF1hEyzuoKo8 for ; Thu, 4 Jul 2013 03:14:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B9EE621F9EB3 for ; Thu, 4 Jul 2013 03:14:10 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4FA4218C1C4; Thu, 4 Jul 2013 12:14:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 18B3623806F; Thu, 4 Jul 2013 12:14:09 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 4 Jul 2013 12:14:08 +0200 From: To: Parthasarathi R , "mmusic@ietf.org" , "mperumal@cisco.com" Thread-Topic: comments on draft-ietf-mmusic-sdp-g723-g729-03 Thread-Index: Ac5zD3LDp2qz/2AGQwu/7apfDc5rAAE/8RsQACMdScAAAN1H4A== Date: Thu, 4 Jul 2013 10:14:08 +0000 Message-ID: <12353_1372932849_51D54AF1_12353_1741_1_719DF432C01EA6418EBA5185063A16610D3EE3@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] 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.5.21.113319 Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-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, 04 Jul 2013 10:14:15 -0000 Hello My answers inline (I removed the agreed parts) Aurelien -----Message d'origine----- De=A0: Parthasarathi R [mailto:partha@parthasarathi.co.in] Envoy=E9=A0: mercredi 3 juillet 2013 19:29 =C0=A0: SOLLAUD Aurelien OLNC/OLN; mmusic@ietf.org; mperumal@cisco.com Obje= t=A0: RE: comments on draft-ietf-mmusic-sdp-g723-g729-03 Hi Aurelien, Sorry for the delay response. Thanks for the review comments.=20 Please read inline. Thanks Partha > -----Original Message----- > From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] > Sent: Thursday, June 27, 2013 1:52 PM > To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in > Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 >=20 (snip) >=20 >=20 > ** Section 3.1 >=20 > 2) > After the first paragraph, I suggest to insert the new paragraph below: >=20 > ---NEW > The Annex A of the codec concerns both sending and receiving, so both=20 > sides of a bi-directional session MUST have the same setting. If one=20 > party indicates that it does not support Annex A, Annex A must be=20 > deactivated both ways. > ----- > That defines the general rationale of the following paragraphs. > I agree with that it is the objective of this O/A requirement but = how this statement qualifies for normative statement is not clear. From the= offerer perspective, there is no control on same setting in both sides. In= case you look at the combine requirements of this draft, this object is me= t. [Aurelien] OK. I agree you can turn "MUST" into "must". I think this new pa= ragraph helps anyway. =20 >=20 > 3) > ----- > When the offer has G723 with annexa=3Dno then the answer MUST NOT have > annexa=3Dyes for G723. Thus the annexa parameter can be turned off by > the answerer, but cannot be turned on. > ----- > I don't think this new requirement is needed. > Anyway implementation that will not implement this RFC-to-be will not=20 > comply with it. >=20 As per based G723 RFC, it is expected for all the implementation t= o support annexa. This issue is discussed in http://www.ietf.org/mail-archi= ve/web/mmusic/current/msg11165.html =20 [Aurelien] Yes I agree all implementations support annexa. What I called th= e RFC-to-be is the document draft-ietf-mmusic-sdp-g723-g729. My comment was= that previous implementations will not comply with this "MUST NOT". A warn= ing should be written on this. The receiver of the SDP should be tolerant a= nd ready to receive SDP not compliant with this new requirement, without br= eaking. I the offer has annexa=3Dno and the answer (of an old implementation) has a= nnexa=3Dyes, Annex A must not be used. It is the same kind of thing you describe later about the case where the of= fer has annexa=3Dno and the answer has no annexa at all. Annex A must not b= e used. (snip) >=20 > ** Section 3.2 >=20 > 5) > After the first two paragraphs, I suggest to insert the new paragraph > below: >=20 > ---NEW > The Annex B of the codec concerns both sending and receiving, so both=20 > sides of a bi-directional session MUST have the same setting. If one=20 > party indicates that it does not support Annex B, Annex B must be=20 > deactivated both ways. > ----- > That defines the general rationale of the following paragraphs. >=20 Same as comment 2 reply. I agree with that it is the objective of = this O/A requirement but how this statement qualifies for normative stateme= nt is not clear. From the offerer perspective, there is no control on same = setting in both sides. In case you look at the combine requirements of this= draft, this object is met. [Aurelien] same as comment 2, you can keep it informative and turn the "MUS= T" into "must". >=20 > 6) > ----- > When the offer or answer has G729 and the annexb parameter is=20 > absent, > it MUST be considered as if the offer or answer has G729 with > annexb=3Dyes. > ----- > This paragraph is redundant with what is said before. > Remove it. >=20 >=20 As per based G729 RFC, it is expected for all the implementation t= o support annexb. This issue is discussed in http://www.ietf.org/mail-archi= ve/web/mmusic/current/msg11165.html [Aurelien] You did not understand me. I said to remove the paragraph becaus= e it is an exact repetition of text. I quote the whole text: ---- When the offer or answer has G729 and the annexb parameter is absent, the offerer or answerer knows that it has implied the default "annexb=3Dyes". This is because the annexb attribute is part of the original registration of audio/G729 [RFC4856]. All implementations that support G729 understand the annexb attribute. Hence, this case MUST be considered as if the offer or answer has G729 with annexb=3Dyes. When the offer or answer has G729 and the annexb parameter is absent, it MUST be considered as if the offer or answer has G729 with annexb=3Dyes. ---- As you can see, the second paragraph says the exact same thing as the first= one. > 7) > ----- > When the offer has G729 with annexb=3Dno then the answer MUST NOT have > annexb=3Dyes for G729. Thus the annexb parameter can be turned off by > the answerer, but cannot be turned on. > ----- > I don't think this new requirement is needed. > For the same reason as for G723 >=20 Same reply as comment 3. As per based G729 RFC, it is expected for= all the implementation to support annexb. This issue is discussed in http:= //www.ietf.org/mail-archive/web/mmusic/current/msg11165.html [Aurelien] Same as comment 3, I suggest adding a warning on previous implem= entation that may not comply with this new requirement. (snip) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From thomas.stach@siemens-enterprise.com Thu Jul 4 06:15: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 D2C9B21F9FD8 for ; Thu, 4 Jul 2013 06:15: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] 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 qvOXTTy14Psh for ; Thu, 4 Jul 2013 06:15:09 -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 A5DA521F9FD5 for ; Thu, 4 Jul 2013 06:15:08 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 944C01EB85FB; Thu, 4 Jul 2013 15:15:05 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 4 Jul 2013 15:15:05 +0200 From: "Stach, Thomas" To: Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BA Date: Thu, 4 Jul 2013 13:15:04 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> In-Reply-To: <51D43186.2010907@jitsi.org> Accept-Language: de-AT, 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 WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 13:15:12 -0000 Emil, inline > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Wednesday, 03 July, 2013 16:13 > To: MMUSIC IETF WG > Subject: [MMUSIC] Trickle ICE for SIP Questions >=20 > Hey all, >=20 > Christer, Enrico and I are preparing the next version of Trickle ICE > for > SIP. Now that discussions on BUNDLE and the plans seem to be winding > down, we wanted to run a few questions by the working group. >=20 > Q1: Making reliable provisional responses and PRACK mandatory. > Obviously > this would be nice to avoid, so the question is: is there a reasonable > mechanism to achieve this (and by reasonable, we mean something that > wouldn't be harder than implementing support for PRACK). >=20 > There was some discussion about this back in April and there was a > suggestion for implementing a 5245-style hack where the answerer > basically resends the 180 until it knows that it has been received. >=20 > 5245 uses connectivity checks for this (i.e. it stops 180 > retransmissions when the first connectivity check is received) but we > don't have that option here since the 180 may contain either none or > only host candidates so there are strong chances that no binding > request > would be received on them. >=20 > Thomas also suggested a second option which would be to also use INFO > requests with trickled candidates as an indication that 180 was > received. This however wouldn't work with half trickle so we are > basically back to vanilla ICE for all (non-re) INVITEs. >=20 > Another option would be to mandate an INFO request with > "end-of-candidates" in response to the 180, but that would be just the > same as mandating PRACK support. >=20 > Thomas also suggested that the answerer can start sending INFOs right > after it sends its answer in the 180 and then it can just resend the > 180 > if the INFOs result in a 481 response. >=20 > Personally I think this could potentially be made to work, but it would > imply a level of complexity that considerably exceeds PRACK support. [TS] I'm not convinced about the different level of complexity.=20 If you use PRACK you have SIP timer T1 running and would re-transmit the 18= 0 in case that the PRACK is not received.=20 Assuming that you want to wait with sending of the INFO until you saw the P= RACK, would lead to delay in that case. If you don't wait you would also have to treat a 481 response to the INFO. ... and you would detect quicker that the 180 was lost than by waiting for = the PRACK. BTW: 5245 recommends to use PRACK. However it does not mandate it, but give= s the alternative procedures as an option. You could do the same here. >=20 > Opinions? >=20 > Q2: How do we send INFOs? Are they blocking or do we just send them in > parallel? If the latter, then what happens when an INFO fails because > it > is received out of order? Do we just tell the application to resend the > candidates asap? [TS] I would go with the proposal below and send cumulatively. You also hav= e the CSeq: header field to detect late arrivals. >=20 > This also leads to the following question: >=20 > Q3: What exactly do we send in INFOs? Just the latest batch of freshly > learned candidates or all candidates we've learned so far? Dale > suggested that if we do this cumulatively we wouldn't need to worry > about the case with the out-of-order INFOs from Q2 since the > information > gets resent anyway. A drawback here would obviously be that this adds > more complexity for trickle ICE users (WebRTC applications > specifically) [TS] Again I'm not convinced about the complexity. Both peer know their can= didates, what is the issue in putting all of them into the INFO? >=20 > A third option would be to allow both and leave it to the application. [TS] This now adds complexity. ;-) I would just always send all candidates. Regards Thomas >=20 > Comments are most welcome! >=20 > Emil >=20 > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From mperumal@cisco.com Thu Jul 4 22:11: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 BC56C11E80FA for ; Thu, 4 Jul 2013 22:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 Plx2R29h4dYS for ; Thu, 4 Jul 2013 22:11:34 -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 7CEB721F9F33 for ; Thu, 4 Jul 2013 22:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9112; q=dns/txt; s=iport; t=1373001094; x=1374210694; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eqmf7QSsWMMfeIjBLbhlWXL1beGz6WzcJlYLPyrQaXw=; b=iCEC5bJzhHLVsrYwJq2Qcz+pmiMFJJQ/j+ziF3PXCRylNI4fEW2xagNU dkDjdFLNSaxzXDoxKnaKc6jPsAdn/92OVmFazXM1qFmpvYDWRi95cdDhE UknIl2YOQnBYAEbkG6NdUaMB22bZDgNzzPiUaetl432dZUT1kqj676rFC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FABRU1lGtJV2a/2dsb2JhbABagwkyQwbAOX8WdIIjAQEBBIEFBgEIEQQBAQsdORQJCQEEARIIAYgGBwWqU448jikQgQEGLQcEgn5pA4hrmwGFIoMRgXE3 X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208";a="231184922" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jul 2013 05:11:34 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r655BYte010282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 05:11:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 00:11:33 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "aurelien.sollaud@orange.com" , "Parthasarathi R" , "mmusic@ietf.org" Thread-Topic: RE:` Thread-Index: Ac55Nkbs04s/rq3fQliC5Ns4xH13+gAAQt0w Date: Fri, 5 Jul 2013 05:11:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.211.93] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] ` X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:11:39 -0000 Hi Aurelien, Partha and I had a discussion. Please see inline for [Muthu]: |-----Original Message----- |From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] |Sent: Thursday, July 04, 2013 3:44 PM |To: Parthasarathi R; mmusic@ietf.org; Muthu Arul Mozhi Perumal (mperumal) |Subject: RE:` | |Hello | |My answers inline |(I removed the agreed parts) | |Aurelien | |-----Message d'origine----- |De=A0: Parthasarathi R [mailto:partha@parthasarathi.co.in] |Envoy=E9=A0: mercredi 3 juillet 2013 19:29 |=C0=A0: SOLLAUD Aurelien OLNC/OLN; mmusic@ietf.org; mperumal@cisco.com Obj= et=A0: RE: comments on draft-ietf- |mmusic-sdp-g723-g729-03 | |Hi Aurelien, | |Sorry for the delay response. Thanks for the review comments. | |Please read inline. | |Thanks |Partha | |> -----Original Message----- |> From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] |> Sent: Thursday, June 27, 2013 1:52 PM |> To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in |> Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 |> | | (snip) |> |> |> ** Section 3.1 |> |> 2) |> After the first paragraph, I suggest to insert the new paragraph below: |> |> ---NEW |> The Annex A of the codec concerns both sending and receiving, so both |> sides of a bi-directional session MUST have the same setting. If one |> party indicates that it does not support Annex A, Annex A must be |> deactivated both ways. |> ----- |> That defines the general rationale of the following paragraphs. |> | I agree with that it is the objective of this O/A requirement but= how this statement |qualifies for normative statement is not clear. From the offerer perspecti= ve, there is no control on |same setting in both sides. In case you look at the combine requirements o= f this draft, this object is |met. | | |[Aurelien] OK. I agree you can turn "MUST" into "must". I think this new p= aragraph helps anyway. [Muthu] Agree it helps. However, the text could be reworded to make it cris= per: =20 The objective of the below statements is to make sure that if the offere= r=20 or answerer indicates it does not support Annex A, Annex A is not used. Does it sound good? | | |> |> 3) |> ----- |> When the offer has G723 with annexa=3Dno then the answer MUST NOT hav= e |> annexa=3Dyes for G723. Thus the annexa parameter can be turned off b= y |> the answerer, but cannot be turned on. |> ----- |> I don't think this new requirement is needed. |> Anyway implementation that will not implement this RFC-to-be will not |> comply with it. |> | As per based G723 RFC, it is expected for all the implementation = to support annexa. This |issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/= msg11165.html | |[Aurelien] Yes I agree all implementations support annexa. What I called t= he RFC-to-be is the document |draft-ietf-mmusic-sdp-g723-g729. My comment was that previous implementati= ons will not comply with |this "MUST NOT". A warning should be written on this. The receiver of the = SDP should be tolerant and |ready to receive SDP not compliant with this new requirement, without brea= king. |I the offer has annexa=3Dno and the answer (of an old implementation) has = annexa=3Dyes, Annex A must not |be used. |It is the same kind of thing you describe later about the case where the o= ffer has annexa=3Dno and the |answer has no annexa at all. Annex A must not be used. [Muthu] Agree. I think both this paragraph and the later paragraph (that de= scribes the case where the offer has annexa=3Dno and the answer has no anne= xa at all) can be combined together: When the offer has G723 with annexa=3Dno, after the offer/answer=20 completion the offerer and answerer MUST proceed as if G723 is=20 negotiated with annexa=3Dno. When the offer has G723 with annexa=3Dno, the reason for not mandating that the answer MUST have annexa=3Dno for G723 is that there are there implementations that omit the annexa parameter in answer and expect the least common denominator to be used. Does it sound good?=20 | | | (snip) |> |> ** Section 3.2 |> |> 5) |> After the first two paragraphs, I suggest to insert the new paragraph |> below: |> |> ---NEW |> The Annex B of the codec concerns both sending and receiving, so both |> sides of a bi-directional session MUST have the same setting. If one |> party indicates that it does not support Annex B, Annex B must be |> deactivated both ways. |> ----- |> That defines the general rationale of the following paragraphs. |> | | Same as comment 2 reply. I agree with that it is the objective of= this O/A requirement but |how this statement qualifies for normative statement is not clear. From th= e offerer perspective, there |is no control on same setting in both sides. In case you look at the combi= ne requirements of this |draft, this object is met. | |[Aurelien] same as comment 2, you can keep it informative and turn the "MU= ST" into "must". [Muthu] Same as above:=20 The objective of the below statements is to make sure that if the offere= r=20 or answerer indicates it does not support Annex B, Annex B is not used. Does it sound good? | | |> |> 6) |> ----- |> When the offer or answer has G729 and the annexb parameter is |> absent, |> it MUST be considered as if the offer or answer has G729 with |> annexb=3Dyes. |> ----- |> This paragraph is redundant with what is said before. |> Remove it. |> |> | | As per based G729 RFC, it is expected for all the implementation = to support annexb. This |issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/= msg11165.html | |[Aurelien] You did not understand me. I said to remove the paragraph becau= se it is an exact repetition |of text. I quote the whole text: | |---- | When the offer or answer has G729 and the annexb parameter is absent, | the offerer or answerer knows that it has implied the default | "annexb=3Dyes". This is because the annexb attribute is part of the | original registration of audio/G729 [RFC4856]. All implementations | that support G729 understand the annexb attribute. Hence, this case | MUST be considered as if the offer or answer has G729 with | annexb=3Dyes. | | When the offer or answer has G729 and the annexb parameter is absent, | it MUST be considered as if the offer or answer has G729 with | annexb=3Dyes. |---- | |As you can see, the second paragraph says the exact same thing as the firs= t one. [Muthu] Agree, the second paragraph is redundant. | | |> 7) |> ----- |> When the offer has G729 with annexb=3Dno then the answer MUST NOT hav= e |> annexb=3Dyes for G729. Thus the annexb parameter can be turned off b= y |> the answerer, but cannot be turned on. |> ----- |> I don't think this new requirement is needed. |> For the same reason as for G723 |> | Same reply as comment 3. As per based G729 RFC, it is expected fo= r all the implementation to |support annexb. This issue is discussed in http://www.ietf.org/mail- |archive/web/mmusic/current/msg11165.html | |[Aurelien] Same as comment 3, I suggest adding a warning on previous imple= mentation that may not |comply with this new requirement. [Muthu] Same as above: When the offer has G729 with annexb=3Dno, after the offer/answer=20 completion the offerer and answerer MUST proceed as if G729 is=20 negotiated with annexb=3Dno. When the offer has G729 with annexb=3Dno, the reason for not mandating that the answer MUST have annexb=3Dno for G729 is that there are there implementations that omit the annexb parameter in answer and expect the least common denominator to be used. Does it sound good? Thanks for your inputs, Muthu | | (snip) | |__________________________________________________________________________= ____________________________ |___________________ | |Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et |ne doivent donc |pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, |veuillez le signaler |a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant |susceptibles d'alteration, |Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. | |This message and its attachments may contain confidential or privileged in= formation that may be |protected by law; |they should not be distributed, used or copied without authorisation. |If you have received this email in error, please notify the sender and del= ete this message and its |attachments. |As emails may be altered, Orange is not liable for messages that have been= modified, changed or |falsified. |Thank you. From mperumal@cisco.com Thu Jul 4 22:24: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 E484C21F9BD0 for ; Thu, 4 Jul 2013 22:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 3uuAQQQYNZwH for ; Thu, 4 Jul 2013 22:24:43 -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 9BCA121F8BCE for ; Thu, 4 Jul 2013 22:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9601; q=dns/txt; s=iport; t=1373001883; x=1374211483; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0SvOr4FbepQUmIjtE+9n+5mvAQNrw8oWYKQoOwYZ4oI=; b=l7ySWKAucD+QfdWUkZGsymOTjFZA3d0QpCXaFTbeLHpsTylA07di/5d9 S5vFEsqvA/k5xDaAyv9BJ5uFvaREwgvyVnZh/dRjnvCMN3AzxJx407YbV yekc6fvy/UdgMwQhv/cCs4+fWbeWidzhAi8f8zkQu5CZLx3sAdN79J1WQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FABtX1lGtJXG+/2dsb2JhbABagwkyQwbAOX8WdIIjAQEBBIEFBgEIEQQBAQsdORQJCQEEARIIAYgGBwWqUI49jikQgQEGLQcEgn5pA4hrmwGFIoMRgXE3 X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208";a="231246929" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2013 05:24:40 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r655Od46010836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 05:24:39 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 00:24:39 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "aurelien.sollaud@orange.com" , "Parthasarathi R" , "mmusic@ietf.org" Thread-Topic: comments on draft-ietf-mmusic-sdp-g723-g729-03 Thread-Index: Ac55Nkbs04s/rq3fQliC5Ns4xH13+gAAQt0wAAIOmyA= Date: Fri, 5 Jul 2013 05:24:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.211.93] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 05:24:49 -0000 Fixed the subject to make it easier to search.. Muthu |-----Original Message----- |From: Muthu Arul Mozhi Perumal (mperumal) |Sent: Friday, July 05, 2013 10:42 AM |To: 'aurelien.sollaud@orange.com'; Parthasarathi R; mmusic@ietf.org |Subject: RE: RE:` | |Hi Aurelien, | |Partha and I had a discussion. Please see inline for [Muthu]: | ||-----Original Message----- ||From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] ||Sent: Thursday, July 04, 2013 3:44 PM ||To: Parthasarathi R; mmusic@ietf.org; Muthu Arul Mozhi Perumal (mperumal) ||Subject: RE:` || ||Hello || ||My answers inline ||(I removed the agreed parts) || ||Aurelien || ||-----Message d'origine----- ||De=A0: Parthasarathi R [mailto:partha@parthasarathi.co.in] ||Envoy=E9=A0: mercredi 3 juillet 2013 19:29 ||=C0=A0: SOLLAUD Aurelien OLNC/OLN; mmusic@ietf.org; mperumal@cisco.com Ob= jet=A0: RE: comments on draft- |ietf- ||mmusic-sdp-g723-g729-03 || ||Hi Aurelien, || ||Sorry for the delay response. Thanks for the review comments. || ||Please read inline. || ||Thanks ||Partha || ||> -----Original Message----- ||> From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] ||> Sent: Thursday, June 27, 2013 1:52 PM ||> To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in ||> Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 ||> || || (snip) ||> ||> ||> ** Section 3.1 ||> ||> 2) ||> After the first paragraph, I suggest to insert the new paragraph below: ||> ||> ---NEW ||> The Annex A of the codec concerns both sending and receiving, so both ||> sides of a bi-directional session MUST have the same setting. If one ||> party indicates that it does not support Annex A, Annex A must be ||> deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> || I agree with that it is the objective of this O/A requirement bu= t how this statement ||qualifies for normative statement is not clear. From the offerer perspect= ive, there is no control on ||same setting in both sides. In case you look at the combine requirements = of this draft, this object |is ||met. || || ||[Aurelien] OK. I agree you can turn "MUST" into "must". I think this new = paragraph helps anyway. | |[Muthu] Agree it helps. However, the text could be reworded to make it cri= sper: | | The objective of the below statements is to make sure that if the offer= er | or answerer indicates it does not support Annex A, Annex A is not used. | |Does it sound good? | || || ||> ||> 3) ||> ----- ||> When the offer has G723 with annexa=3Dno then the answer MUST NOT ha= ve ||> annexa=3Dyes for G723. Thus the annexa parameter can be turned off = by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> Anyway implementation that will not implement this RFC-to-be will not ||> comply with it. ||> || As per based G723 RFC, it is expected for all the implementation= to support annexa. This ||issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current= /msg11165.html || ||[Aurelien] Yes I agree all implementations support annexa. What I called = the RFC-to-be is the |document ||draft-ietf-mmusic-sdp-g723-g729. My comment was that previous implementat= ions will not comply with ||this "MUST NOT". A warning should be written on this. The receiver of the= SDP should be tolerant and ||ready to receive SDP not compliant with this new requirement, without bre= aking. ||I the offer has annexa=3Dno and the answer (of an old implementation) has= annexa=3Dyes, Annex A must not ||be used. ||It is the same kind of thing you describe later about the case where the = offer has annexa=3Dno and the ||answer has no annexa at all. Annex A must not be used. | |[Muthu] Agree. I think both this paragraph and the later paragraph (that d= escribes the case where the |offer has annexa=3Dno and the answer has no annexa at all) can be combined= together: | | When the offer has G723 with annexa=3Dno, after the offer/answer | completion the offerer and answerer MUST proceed as if G723 is | negotiated with annexa=3Dno. | | When the offer has G723 with annexa=3Dno, the reason for not mandating | that the answer MUST have annexa=3Dno for G723 is that there are there | implementations that omit the annexa parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | || || || (snip) ||> ||> ** Section 3.2 ||> ||> 5) ||> After the first two paragraphs, I suggest to insert the new paragraph ||> below: ||> ||> ---NEW ||> The Annex B of the codec concerns both sending and receiving, so both ||> sides of a bi-directional session MUST have the same setting. If one ||> party indicates that it does not support Annex B, Annex B must be ||> deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> || || Same as comment 2 reply. I agree with that it is the objective o= f this O/A requirement but ||how this statement qualifies for normative statement is not clear. From t= he offerer perspective, |there ||is no control on same setting in both sides. In case you look at the comb= ine requirements of this ||draft, this object is met. || ||[Aurelien] same as comment 2, you can keep it informative and turn the "M= UST" into "must". | |[Muthu] Same as above: | | The objective of the below statements is to make sure that if the offer= er | or answerer indicates it does not support Annex B, Annex B is not used. | |Does it sound good? | || || ||> ||> 6) ||> ----- ||> When the offer or answer has G729 and the annexb parameter is ||> absent, ||> it MUST be considered as if the offer or answer has G729 with ||> annexb=3Dyes. ||> ----- ||> This paragraph is redundant with what is said before. ||> Remove it. ||> ||> || || As per based G729 RFC, it is expected for all the implementation= to support annexb. This ||issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current= /msg11165.html || ||[Aurelien] You did not understand me. I said to remove the paragraph beca= use it is an exact |repetition ||of text. I quote the whole text: || ||---- || When the offer or answer has G729 and the annexb parameter is absent, || the offerer or answerer knows that it has implied the default || "annexb=3Dyes". This is because the annexb attribute is part of the || original registration of audio/G729 [RFC4856]. All implementations || that support G729 understand the annexb attribute. Hence, this case || MUST be considered as if the offer or answer has G729 with || annexb=3Dyes. || || When the offer or answer has G729 and the annexb parameter is absent, || it MUST be considered as if the offer or answer has G729 with || annexb=3Dyes. ||---- || ||As you can see, the second paragraph says the exact same thing as the fir= st one. | |[Muthu] Agree, the second paragraph is redundant. | || || ||> 7) ||> ----- ||> When the offer has G729 with annexb=3Dno then the answer MUST NOT ha= ve ||> annexb=3Dyes for G729. Thus the annexb parameter can be turned off = by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> For the same reason as for G723 ||> || Same reply as comment 3. As per based G729 RFC, it is expected f= or all the implementation to ||support annexb. This issue is discussed in http://www.ietf.org/mail- ||archive/web/mmusic/current/msg11165.html || ||[Aurelien] Same as comment 3, I suggest adding a warning on previous impl= ementation that may not ||comply with this new requirement. | |[Muthu] Same as above: | | When the offer has G729 with annexb=3Dno, after the offer/answer | completion the offerer and answerer MUST proceed as if G729 is | negotiated with annexb=3Dno. | | When the offer has G729 with annexb=3Dno, the reason for not mandating | that the answer MUST have annexb=3Dno for G729 is that there are there | implementations that omit the annexb parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | |Thanks for your inputs, | |Muthu | || || (snip) || ||_________________________________________________________________________= ____________________________ |_ ||___________________ || ||Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ||ne doivent donc ||pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, ||veuillez le signaler ||a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant ||susceptibles d'alteration, ||Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. || ||This message and its attachments may contain confidential or privileged i= nformation that may be ||protected by law; ||they should not be distributed, used or copied without authorisation. ||If you have received this email in error, please notify the sender and de= lete this message and its ||attachments. ||As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or ||falsified. ||Thank you. From aurelien.sollaud@orange.com Fri Jul 5 02: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 3EB3411E8264 for ; Fri, 5 Jul 2013 02:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 uFpRT98if6SR for ; Fri, 5 Jul 2013 02:02:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B4B2911E825E for ; Fri, 5 Jul 2013 02:02:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4FAF722D7F4; Fri, 5 Jul 2013 11:02:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2D89D27C095; Fri, 5 Jul 2013 11:02:21 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 5 Jul 2013 11:02:20 +0200 From: To: "Muthu Arul Mozhi Perumal (mperumal)" , "Parthasarathi R" , "mmusic@ietf.org" Thread-Topic: comments on draft-ietf-mmusic-sdp-g723-g729-03 Thread-Index: Ac55Nkbsp2qz/2AGQwu/7apfDc5rAAAAQt0wAAIOmyAAB3itEA== Date: Fri, 5 Jul 2013 09:02:20 +0000 Message-ID: <14148_1373014941_51D68B9D_14148_2017_1_719DF432C01EA6418EBA5185063A16610D4404@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] 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.7.1.45418 Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 09:02:29 -0000 Hello I fully agree with these modifications. I have no other comment. Thanks Aurelien -----Message d'origine----- De=A0: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Envoy=E9=A0: vendredi 5 juillet 2013 07:25 =C0=A0: SOLLAUD Aurelien OLNC/OLN; Parthasarathi R; mmusic@ietf.org Objet=A0: RE: comments on draft-ietf-mmusic-sdp-g723-g729-03 Fixed the subject to make it easier to search.. Muthu |-----Original Message----- |From: Muthu Arul Mozhi Perumal (mperumal) |Sent: Friday, July 05, 2013 10:42 AM |To: 'aurelien.sollaud@orange.com'; Parthasarathi R; mmusic@ietf.org |Subject: RE: RE:` | |Hi Aurelien, | |Partha and I had a discussion. Please see inline for [Muthu]: | ||-----Original Message----- ||From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] ||Sent: Thursday, July 04, 2013 3:44 PM ||To: Parthasarathi R; mmusic@ietf.org; Muthu Arul Mozhi Perumal=20 ||(mperumal) ||Subject: RE:` || ||Hello || ||My answers inline ||(I removed the agreed parts) || ||Aurelien || ||-----Message d'origine----- ||De=A0: Parthasarathi R [mailto:partha@parthasarathi.co.in] ||Envoy=E9=A0: mercredi 3 juillet 2013 19:29 =C0=A0: SOLLAUD Aurelien OLNC/= OLN;=20 ||mmusic@ietf.org; mperumal@cisco.com Objet=A0: RE: comments on draft- |ietf- ||mmusic-sdp-g723-g729-03 || ||Hi Aurelien, || ||Sorry for the delay response. Thanks for the review comments. || ||Please read inline. || ||Thanks ||Partha || ||> -----Original Message----- ||> From: aurelien.sollaud@orange.com=20 ||> [mailto:aurelien.sollaud@orange.com] ||> Sent: Thursday, June 27, 2013 1:52 PM ||> To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in ||> Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 ||> || || (snip) ||> ||> ||> ** Section 3.1 ||> ||> 2) ||> After the first paragraph, I suggest to insert the new paragraph below: ||> ||> ---NEW ||> The Annex A of the codec concerns both sending and receiving, so=20 ||> both sides of a bi-directional session MUST have the same setting.=20= =20 ||> If one party indicates that it does not support Annex A, Annex A=20=20 ||> must be deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> || I agree with that it is the objective of this O/A requirement=20 ||but how this statement qualifies for normative statement is not clear.=20 ||From the offerer perspective, there is no control on same setting in=20 ||both sides. In case you look at the combine requirements of this=20 ||draft, this object |is ||met. || || ||[Aurelien] OK. I agree you can turn "MUST" into "must". I think this new = paragraph helps anyway. | |[Muthu] Agree it helps. However, the text could be reworded to make it cri= sper: | | The objective of the below statements is to make sure that if the offer= er | or answerer indicates it does not support Annex A, Annex A is not used. | |Does it sound good? | || || ||> ||> 3) ||> ----- ||> When the offer has G723 with annexa=3Dno then the answer MUST NOT ha= ve ||> annexa=3Dyes for G723. Thus the annexa parameter can be turned off = by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> Anyway implementation that will not implement this RFC-to-be will=20 ||> not comply with it. ||> || As per based G723 RFC, it is expected for all the=20 ||implementation to support annexa. This issue is discussed in=20 ||http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html=20 || || ||[Aurelien] Yes I agree all implementations support annexa. What I=20 ||called the RFC-to-be is the |document ||draft-ietf-mmusic-sdp-g723-g729. My comment was that previous=20 ||implementations will not comply with this "MUST NOT". A warning should=20 ||be written on this. The receiver of the SDP should be tolerant and ready = to receive SDP not compliant with this new requirement, without breaking. ||I the offer has annexa=3Dno and the answer (of an old implementation)=20 ||has annexa=3Dyes, Annex A must not be used. ||It is the same kind of thing you describe later about the case where=20 ||the offer has annexa=3Dno and the answer has no annexa at all. Annex A mu= st not be used. | |[Muthu] Agree. I think both this paragraph and the later paragraph=20 |(that describes the case where the offer has annexa=3Dno and the answer ha= s no annexa at all) can be combined together: | | When the offer has G723 with annexa=3Dno, after the offer/answer | completion the offerer and answerer MUST proceed as if G723 is | negotiated with annexa=3Dno. | | When the offer has G723 with annexa=3Dno, the reason for not mandating | that the answer MUST have annexa=3Dno for G723 is that there are there | implementations that omit the annexa parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | || || || (snip) ||> ||> ** Section 3.2 ||> ||> 5) ||> After the first two paragraphs, I suggest to insert the new=20 ||> paragraph ||> below: ||> ||> ---NEW ||> The Annex B of the codec concerns both sending and receiving, so=20 ||> both sides of a bi-directional session MUST have the same setting.=20= =20 ||> If one party indicates that it does not support Annex B, Annex B=20 ||> must be deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> || || Same as comment 2 reply. I agree with that it is the=20 ||objective of this O/A requirement but how this statement qualifies for=20 ||normative statement is not clear. From the offerer perspective, |there ||is no control on same setting in both sides. In case you look at the=20 ||combine requirements of this draft, this object is met. || ||[Aurelien] same as comment 2, you can keep it informative and turn the "M= UST" into "must". | |[Muthu] Same as above: | | The objective of the below statements is to make sure that if the offer= er | or answerer indicates it does not support Annex B, Annex B is not used. | |Does it sound good? | || || ||> ||> 6) ||> ----- ||> When the offer or answer has G729 and the annexb parameter is=20 ||> absent, ||> it MUST be considered as if the offer or answer has G729 with ||> annexb=3Dyes. ||> ----- ||> This paragraph is redundant with what is said before. ||> Remove it. ||> ||> || || As per based G729 RFC, it is expected for all the=20 ||implementation to support annexb. This issue is discussed in=20 ||http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html=20 || || ||[Aurelien] You did not understand me. I said to remove the paragraph=20 ||because it is an exact |repetition ||of text. I quote the whole text: || ||---- || When the offer or answer has G729 and the annexb parameter is absent, || the offerer or answerer knows that it has implied the default || "annexb=3Dyes". This is because the annexb attribute is part of the || original registration of audio/G729 [RFC4856]. All implementations || that support G729 understand the annexb attribute. Hence, this case || MUST be considered as if the offer or answer has G729 with || annexb=3Dyes. || || When the offer or answer has G729 and the annexb parameter is absent, || it MUST be considered as if the offer or answer has G729 with || annexb=3Dyes. ||---- || ||As you can see, the second paragraph says the exact same thing as the fir= st one. | |[Muthu] Agree, the second paragraph is redundant. | || || ||> 7) ||> ----- ||> When the offer has G729 with annexb=3Dno then the answer MUST NOT ha= ve ||> annexb=3Dyes for G729. Thus the annexb parameter can be turned off = by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> For the same reason as for G723 ||> || Same reply as comment 3. As per based G729 RFC, it is=20 ||expected for all the implementation to support annexb. This issue is=20 ||discussed in http://www.ietf.org/mail-=20 ||archive/web/mmusic/current/msg11165.html || ||[Aurelien] Same as comment 3, I suggest adding a warning on previous=20 ||implementation that may not comply with this new requirement. | |[Muthu] Same as above: | | When the offer has G729 with annexb=3Dno, after the offer/answer | completion the offerer and answerer MUST proceed as if G729 is | negotiated with annexb=3Dno. | | When the offer has G729 with annexb=3Dno, the reason for not mandating | that the answer MUST have annexb=3Dno for G729 is that there are there | implementations that omit the annexb parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | |Thanks for your inputs, | |Muthu | || || (snip) || ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From emil@sip-communicator.org Fri Jul 5 07:12: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 C083F11E80F4 for ; Fri, 5 Jul 2013 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=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 WSe9L02TAQSK for ; Fri, 5 Jul 2013 07:12:42 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 597AC21F9A57 for ; Fri, 5 Jul 2013 07:12:42 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so2021598wgh.0 for ; Fri, 05 Jul 2013 07:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=xdcXLTq9fD20hAJUPtFZLnsGloH5Ep0/dwr+E+7OuV8=; b=V14XO9JZTl6nDwPOK6AKI0EEM1mZwnI2b1SFCQcPgYFAOD8KYnQPwsxE163akmYTWt XRYxFRfJ9o7UZmaI60JB2BYwFL9Et2D5nKIExecjuxU0Ebw+BmP+lZOPTMABx8bLg7yz Mn28YScN4/F+1wZbXEpnDBc3C7ExKsGnvSGql5XHSI6wbiAgGSv12PqSI+oaehTTLMsX OZ3ZD04nXttLfHZVTqmYFwesexUmEoTAc0w89W5syjCVkHjclTUQmMc/+P6Ol6mHSxDu 51RoHVtg8RzFM702u3M5tzNTcB4GTdYflarJYLE/4xyLnMUOQwXhlER9jNa8xmO1ELz6 RmLg== X-Received: by 10.194.170.168 with SMTP id an8mr6168721wjc.72.1373033561380; Fri, 05 Jul 2013 07:12:41 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:cde3:166e:a5b2:5687]) by mx.google.com with ESMTPSA id fs8sm41152831wib.0.2013.07.05.07.12.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 07:12:40 -0700 (PDT) Message-ID: <51D6D456.7090900@jitsi.org> Date: Fri, 05 Jul 2013 16:12:38 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stach, Thomas" References: <51D43186.2010907@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnG8mECXowkB1DBz5Iv+JttP/oOJMKbLyvZc7nN8fhgF/V+22hT9u384uXp19GC4rHJYuxp Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 14:12:46 -0000 Hey Thomas On 04.07.13, 15:15, Stach, Thomas wrote: > Emil, > inline > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Emil Ivov >> Sent: Wednesday, 03 July, 2013 16:13 >> To: MMUSIC IETF WG >> Subject: [MMUSIC] Trickle ICE for SIP Questions >> >> Hey all, >> >> Christer, Enrico and I are preparing the next version of Trickle ICE >> for >> SIP. Now that discussions on BUNDLE and the plans seem to be winding >> down, we wanted to run a few questions by the working group. >> >> Q1: Making reliable provisional responses and PRACK mandatory. >> Obviously >> this would be nice to avoid, so the question is: is there a reasonable >> mechanism to achieve this (and by reasonable, we mean something that >> wouldn't be harder than implementing support for PRACK). >> >> There was some discussion about this back in April and there was a >> suggestion for implementing a 5245-style hack where the answerer >> basically resends the 180 until it knows that it has been received. >> >> 5245 uses connectivity checks for this (i.e. it stops 180 >> retransmissions when the first connectivity check is received) but we >> don't have that option here since the 180 may contain either none or >> only host candidates so there are strong chances that no binding >> request >> would be received on them. >> >> Thomas also suggested a second option which would be to also use INFO >> requests with trickled candidates as an indication that 180 was >> received. This however wouldn't work with half trickle so we are >> basically back to vanilla ICE for all (non-re) INVITEs. >> >> Another option would be to mandate an INFO request with >> "end-of-candidates" in response to the 180, but that would be just the >> same as mandating PRACK support. >> >> Thomas also suggested that the answerer can start sending INFOs right >> after it sends its answer in the 180 and then it can just resend the >> 180 >> if the INFOs result in a 481 response. >> >> Personally I think this could potentially be made to work, but it would >> imply a level of complexity that considerably exceeds PRACK support. > [TS] I'm not convinced about the different level of complexity. > If you use PRACK you have SIP timer T1 running and would re-transmit the 180 in case that the PRACK is not received. Right. > Assuming that you want to wait with sending of the INFO until you saw the PRACK, would lead to delay in that case. True. Is this the only problem that we are trying to optimize? Save half an RTT? (This is a really a question. I am not trying to make a point. I am simply trying to understand why PRACK is an issue.) > If you don't wait you would also have to treat a 481 response to the INFO. I am always a bit nervous when it comes to interpreting error responses. We are indeed likely to get a 481 when sending INFOs and the 180 hasn't yet made it to the remote side. However 481 might also imply that our dialog is simply dead for some reason and in this case 3261 says: If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. > ... and you would detect quicker that the 180 was lost than by waiting for the PRACK. As said above: a lost 180 is not the only possible cause for a 408 in this case. > BTW: 5245 recommends to use PRACK. However it does not mandate it, but gives the alternative procedures as an option. > You could do the same here. Of course. I should have made that clearer: all alternative approaches were meant as something we could have in addition to the PRACK one. Also, keep in mind that the 180 carries an entire SDP answer. If INFOs are competing with 180s then they may potentially need to carry that too (or at least the ICE parts) and it would be good if we don't have to open that can of worms. >> Opinions? >> >> Q2: How do we send INFOs? Are they blocking or do we just send them in >> parallel? If the latter, then what happens when an INFO fails because >> it >> is received out of order? Do we just tell the application to resend the >> candidates asap? > [TS] I would go with the proposal below and send cumulatively. You also have the CSeq: header field to detect late arrivals. > >> >> This also leads to the following question: >> >> Q3: What exactly do we send in INFOs? Just the latest batch of freshly >> learned candidates or all candidates we've learned so far? Dale >> suggested that if we do this cumulatively we wouldn't need to worry >> about the case with the out-of-order INFOs from Q2 since the >> information >> gets resent anyway. A drawback here would obviously be that this adds >> more complexity for trickle ICE users (WebRTC applications >> specifically) > [TS] Again I'm not convinced about the complexity. Both peer know their candidates, what is the issue in putting all of them into the INFO? I am not sure how current WebRTC stacks handle provisioning of repeating candidates. If they don't then it would be up to the receiving JS app, to sort our which are the new candidates and which were already there. The sending side would be similarly tricky for a JS app: it would need to construct SDP so that the a=candidate attributes appear under the right "a=mid" line. >> A third option would be to allow both and leave it to the application. > [TS] This now adds complexity. ;-) Likely yes. Emil > I would just always send all candidates. > Regards > Thomas >> >> Comments are most welcome! >> >> Emil >> >> -- >> https://jitsi.org >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From pkyzivat@alum.mit.edu Fri Jul 5 09:47: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 E4D1211E80A2 for ; Fri, 5 Jul 2013 09:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 fSsiEdxh4CiF for ; Fri, 5 Jul 2013 09:47:11 -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 5C06011E8135 for ; Fri, 5 Jul 2013 09:47:11 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id wdg41l0020ldTLk53gnAJL; Fri, 05 Jul 2013 16:47:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id wgnA1l00k3ZTu2S01gnA6m; Fri, 05 Jul 2013 16:47:10 +0000 Message-ID: <51D6F88E.5000209@alum.mit.edu> Date: Fri, 05 Jul 2013 12:47:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> In-Reply-To: <51D6D456.7090900@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=1373042830; bh=mXUgRIi0n1NwJoxHrmtt3hT0/YZ9wNYMbJ/oXFZFG28=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=q33QfXfLVqEHvGVM6NxVQ+6ckzuU8zD//6li8dVhV0Ibn9ZXi68tRDcd1PfDzA4yk TKcgiB1ROrzyTKUSuEkoyPEQ/zihw1pJOsQRlE72D0CUVoInvOyun3ljy5dgkoDV20 zzvXGsRwA5j2EdlXpTluyyunypHv9tWXtXo+oRTOSnEfzyUdGL26zZXdKOBSzxHRGX vdFKlW1/tpy5x5yw537nkqSQEd46pGPPBuWjBIZ/+txgLbARlhM3IiJunxYufX44ar HyBkNaZ179QTMLlPdN5cKeoR8r1E38r9t2U9nCCmuiu3y3l55F7KBfzIrsezr0dBg8 Is+YtQtIq74FQ== Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 16:47:16 -0000 On 7/5/13 10:12 AM, Emil Ivov wrote: > Hey Thomas > > On 04.07.13, 15:15, Stach, Thomas wrote: >> Emil, >> inline >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Emil Ivov >>> Sent: Wednesday, 03 July, 2013 16:13 >>> To: MMUSIC IETF WG >>> Subject: [MMUSIC] Trickle ICE for SIP Questions >>> >>> Hey all, >>> >>> Christer, Enrico and I are preparing the next version of Trickle ICE >>> for >>> SIP. Now that discussions on BUNDLE and the plans seem to be winding >>> down, we wanted to run a few questions by the working group. >>> >>> Q1: Making reliable provisional responses and PRACK mandatory. Yes. >>> Obviously >>> this would be nice to avoid, so the question is: is there a reasonable >>> mechanism to achieve this (and by reasonable, we mean something that >>> wouldn't be harder than implementing support for PRACK). >>> >>> There was some discussion about this back in April and there was a >>> suggestion for implementing a 5245-style hack where the answerer >>> basically resends the 180 until it knows that it has been received. >>> >>> 5245 uses connectivity checks for this (i.e. it stops 180 >>> retransmissions when the first connectivity check is received) but we >>> don't have that option here since the 180 may contain either none or >>> only host candidates so there are strong chances that no binding >>> request >>> would be received on them. >>> >>> Thomas also suggested a second option which would be to also use INFO >>> requests with trickled candidates as an indication that 180 was >>> received. This however wouldn't work with half trickle so we are >>> basically back to vanilla ICE for all (non-re) INVITEs. >>> >>> Another option would be to mandate an INFO request with >>> "end-of-candidates" in response to the 180, but that would be just the >>> same as mandating PRACK support. >>> >>> Thomas also suggested that the answerer can start sending INFOs right >>> after it sends its answer in the 180 and then it can just resend the >>> 180 >>> if the INFOs result in a 481 response. >>> >>> Personally I think this could potentially be made to work, but it would >>> imply a level of complexity that considerably exceeds PRACK support. >> [TS] I'm not convinced about the different level of complexity. >> If you use PRACK you have SIP timer T1 running and would re-transmit >> the 180 in case that the PRACK is not received. > > Right. > >> Assuming that you want to wait with sending of the INFO until you saw >> the PRACK, would lead to delay in that case. > > True. Is this the only problem that we are trying to optimize? Save half > an RTT? (This is a really a question. I am not trying to make a point. I > am simply trying to understand why PRACK is an issue.) Yes, why is it such an issue to require PRACK? It is a good thing to implement for many reasons. So in conjunction with defining other new functionality, why not require it? >> If you don't wait you would also have to treat a 481 response to the >> INFO. > > I am always a bit nervous when it comes to interpreting error responses. > We are indeed likely to get a 481 when sending INFOs and the 180 hasn't > yet made it to the remote side. However 481 might also imply that our > dialog is simply dead for some reason and in this case 3261 says: > > > If the response for a request within a dialog is a 481 > (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC > SHOULD terminate the dialog. > >> ... and you would detect quicker that the 180 was lost than by waiting >> for the PRACK. This just highlights how "delicate" things get if you start trying to work around the lack of PRACK. It might be possible to get something that seems to work, but its a house of cards. > As said above: a lost 180 is not the only possible cause for a 408 in > this case. > >> BTW: 5245 recommends to use PRACK. However it does not mandate it, but >> gives the alternative procedures as an option. >> You could do the same here. > > Of course. I should have made that clearer: all alternative approaches > were meant as something we could have in addition to the PRACK one. > > Also, keep in mind that the 180 carries an entire SDP answer. If INFOs > are competing with 180s then they may potentially need to carry that too > (or at least the ICE parts) and it would be good if we don't have to > open that can of worms. Yes. The trickle ICE INFOs are *relative* to what was set up in the O/A. In the absence of the answer the trickle ICE is problematic. >>> Opinions? >>> >>> Q2: How do we send INFOs? Are they blocking or do we just send them in >>> parallel? If the latter, then what happens when an INFO fails because >>> it >>> is received out of order? Do we just tell the application to resend the >>> candidates asap? *If* you are going to send in a non-blocking way then they should be cumulative. If you treat them as blocking, then they don't have to be, but it might still be better. >> [TS] I would go with the proposal below and send cumulatively. You >> also have the CSeq: header field to detect late arrivals. Yes, you can detect the late arrival. But you have at that point already acted on the one that should have been preceded by it. >>> This also leads to the following question: >>> >>> Q3: What exactly do we send in INFOs? Just the latest batch of freshly >>> learned candidates or all candidates we've learned so far? Dale >>> suggested that if we do this cumulatively we wouldn't need to worry >>> about the case with the out-of-order INFOs from Q2 since the >>> information >>> gets resent anyway. Exactly. >>> A drawback here would obviously be that this adds >>> more complexity for trickle ICE users (WebRTC applications >>> specifically) >> [TS] Again I'm not convinced about the complexity. Both peer know >> their candidates, what is the issue in putting all of them into the INFO? > > I am not sure how current WebRTC stacks handle provisioning of repeating > candidates. If they don't then it would be up to the receiving JS app, > to sort our which are the new candidates and which were already there. > > The sending side would be similarly tricky for a JS app: it would need > to construct SDP so that the a=candidate attributes appear under the > right "a=mid" line. I don't know enough about ICE to comment specifically on this. But ISTM that this is analogous to what a SIP device must do to manage the target set of destinations for a request - it is required to keep track and not add the same address to the target set more than once. Thanks, Paul >>> A third option would be to allow both and leave it to the application. >> [TS] This now adds complexity. ;-) > > Likely yes. > > Emil > >> I would just always send all candidates. > > > > >> Regards >> Thomas >>> >>> Comments are most welcome! >>> >>> Emil >>> >>> -- >>> https://jitsi.org >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > From petithug@acm.org Fri Jul 5 10:28: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 389C911E8135 for ; Fri, 5 Jul 2013 10:28:29 -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 Gi+PgkiaPOeJ for ; Fri, 5 Jul 2013 10:28:28 -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 1DC1611E80F3 for ; Fri, 5 Jul 2013 10:28:28 -0700 (PDT) Received: from [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c] (unknown [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c]) (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 B3A57204D3; Fri, 5 Jul 2013 19:28:25 +0200 (CEST) Message-ID: <51D70236.5070508@acm.org> Date: Fri, 05 Jul 2013 10:28:22 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51D43186.2010907@jitsi.org> In-Reply-To: <51D43186.2010907@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 17:28:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I did not receive much comments on my proposal to use STUN packets to carry the new ICE candidates. To summarize, instead of using the SDP in an INFO and or UPDATE transaction, the new candidates can be sent on the same path that the media will use by default (i.e. using the candidate that is copied in the m= and c= line). Because this candidate is chosen to always succeed (using a TURN server), the candidate will always reach their destination. This will remove any problem in the signaling path, because it is no longer used to update the candidates. Thanks. On 07/03/2013 07:13 AM, Emil Ivov wrote: > Hey all, > > Christer, Enrico and I are preparing the next version of Trickle ICE for > SIP. Now that discussions on BUNDLE and the plans seem to be winding down, > we wanted to run a few questions by the working group. > > Q1: Making reliable provisional responses and PRACK mandatory. Obviously > this would be nice to avoid, so the question is: is there a reasonable > mechanism to achieve this (and by reasonable, we mean something that > wouldn't be harder than implementing support for PRACK). > > There was some discussion about this back in April and there was a > suggestion for implementing a 5245-style hack where the answerer basically > resends the 180 until it knows that it has been received. > > 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions > when the first connectivity check is received) but we don't have that > option here since the 180 may contain either none or only host candidates > so there are strong chances that no binding request would be received on > them. > > Thomas also suggested a second option which would be to also use INFO > requests with trickled candidates as an indication that 180 was received. > This however wouldn't work with half trickle so we are basically back to > vanilla ICE for all (non-re) INVITEs. > > Another option would be to mandate an INFO request with "end-of-candidates" > in response to the 180, but that would be just the same as mandating PRACK > support. > > Thomas also suggested that the answerer can start sending INFOs right after > it sends its answer in the 180 and then it can just resend the 180 if the > INFOs result in a 481 response. > > Personally I think this could potentially be made to work, but it would > imply a level of complexity that considerably exceeds PRACK support. > > Opinions? > > Q2: How do we send INFOs? Are they blocking or do we just send them in > parallel? If the latter, then what happens when an INFO fails because it is > received out of order? Do we just tell the application to resend the > candidates asap? > > This also leads to the following question: > > Q3: What exactly do we send in INFOs? Just the latest batch of freshly > learned candidates or all candidates we've learned so far? Dale suggested > that if we do this cumulatively we wouldn't need to worry about the case > with the out-of-order INFOs from Q2 since the information gets resent > anyway. A drawback here would obviously be that this adds more complexity > for trickle ICE users (WebRTC applications specifically) > > A third option would be to allow both and leave it to the application. > > Comments are most welcome! > > Emil > - -- 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) iQIcBAEBCAAGBQJR1wI1AAoJECnERZXWan7EpOUQAIEFAeuFxkj0IJoWhiPXBb/L ulHURlg00WoK9RJFxLFWHP36lmaQ2y0v7LaFgX1hFoG9TMmMCbyxIfnva+5QFYzx LkiOZcgM5XuXjk6Ruke2/vrgByCPPYiCc7+K01+7NMO6tQL8rKxKr1Hq5PPRkUHY V6PO+XQd+KK8dm2W1qsR9s16goxqqQzeYJsEOX9mTGjqQdaju75FY88FdFE2rhib pdNrr+crC+gqdz/LKMS9so+dKtMMl3KNT39umDQuFkN9Gt+xorbKkvARCbB24xO3 jPX7koQ0v/eJd1lZwmgkrzMiBDnr/RHigIX3OIuNhL5xilf0Daps5jIkvIJT31gJ CUsfR78ykrWp3wJJ7Ck+PQpAyUrCpcctCUR6kEZ4g1gaKRAEWfw1MgieETqtLE8x Dwsy2c3Qw7XPi1VRMfc6BmCbrd59hQtIsF07yHZEJuHz8zuJoWN9mKLMsGJn4E4G ipIQwruOde7B23YUI0kqBzldRnw5sQ5XDi//rNnd2/KaMhSdxB5+A+g+yy2yQIyN m7It4KZ1+BiyOrgK2w8JHkkmbclSV5j3hEEv0pfgt3OoXWwuUqF2rjdQ4NfsXRj4 D05DUrhrgP7HKp+wxsIi2yyxFaZhkIBnooV/AhyDEh4Lk1KbKPPrSaEUyo6/5CmQ CtZLNHXi/Xv3Y3PjrpJF =DFTv -----END PGP SIGNATURE----- From emcho@sip-communicator.org Fri Jul 5 15:00: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 0DF8B21F9CAE for ; Fri, 5 Jul 2013 15:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UkqsxwyLA-qa for ; Fri, 5 Jul 2013 15:00:02 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 07AEA21F9971 for ; Fri, 5 Jul 2013 15:00:01 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so2118759veb.41 for ; Fri, 05 Jul 2013 15:00:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=MqcyEpdyFE2M8rZNHFwAWVQRCSqLkojkmR52/W69A00=; b=hr31QGn5vpFcrHSJHo2W4klEalUpV47UrDBbreQXAv5tOF4eXCVJ7Wd+0P6jmjZpHu pidCGPg8L4sm+Ye46Exao8wD3G8gOnUIBuyN9Uoe9Mfet62eJQ9HEMYH040yustdDVY/ yUG23QSc9f0gVb1eT42Rr21hs6PyDNQiIv9sDkcBCiqAwV8CFXReBzDRMMq9MLmQGO20 FDuiUwifimiuYA9k/MzIPrD/jnwdz0/4IkKkO9iiQ6i5a6jax0npmvJZUtaLJaq36PPs ftVcnpFU69xhVYPvJsGhLsReert14mq27F6GdctvELRy2o/AMYo7sskjJpZePes0JzZY RZcQ== X-Received: by 10.58.214.105 with SMTP id nz9mr8125162vec.58.1373061601090; Fri, 05 Jul 2013 15:00:01 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [2607:f8b0:400c:c01::235]) by mx.google.com with ESMTPSA id wf4sm2891814vdb.12.2013.07.05.15.00.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 15:00:00 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so2103637veb.26 for ; Fri, 05 Jul 2013 15:00:00 -0700 (PDT) X-Received: by 10.58.216.97 with SMTP id op1mr8299749vec.60.1373061600558; Fri, 05 Jul 2013 15:00:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.45.71 with HTTP; Fri, 5 Jul 2013 14:59:40 -0700 (PDT) In-Reply-To: <51D70236.5070508@acm.org> References: <51D43186.2010907@jitsi.org> <51D70236.5070508@acm.org> From: Emil Ivov Date: Fri, 5 Jul 2013 23:59:40 +0200 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk4YHnD/TMeSrcX/TraGa4YeXgGdNFNUCL9cVWwAfmfhFCiw0cjJbE0srySrSApk/vAyOjR Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 22:00:06 -0000 On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I did not receive much comments on my proposal to use STUN packets to carry > the new ICE candidates. To summarize, instead of using the SDP in an INFO and > or UPDATE transaction, the new candidates can be sent on the same path that > the media will use by default (i.e. using the candidate that is copied in the > m= and c= line). Because this candidate is chosen to always succeed (using a > TURN server), the candidate will always reach their destination. This will > remove any problem in the signaling path, because it is no longer used to > update the candidates. Here's my take: Default candidates are not guaranteed to work. Also, you only get to place one candidate as default. What if your peer is IPv6 only and you chose an IPv4 candidate? Or, what if you are both on the same LAN with limited Internet connectivity? Or what if the service you use doesn't even have a TURN server? I am sure we can come up with many other similar situations. The only transport that's guaranteed to work prior to ICE is signalling. There's nothing else that's as reliable as this. (If there was then we probably wouldn't even need ICE in the first place). Emil -- https://jitsi.org > > Thanks. > > On 07/03/2013 07:13 AM, Emil Ivov wrote: >> Hey all, >> >> Christer, Enrico and I are preparing the next version of Trickle ICE for >> SIP. Now that discussions on BUNDLE and the plans seem to be winding down, >> we wanted to run a few questions by the working group. >> >> Q1: Making reliable provisional responses and PRACK mandatory. Obviously >> this would be nice to avoid, so the question is: is there a reasonable >> mechanism to achieve this (and by reasonable, we mean something that >> wouldn't be harder than implementing support for PRACK). >> >> There was some discussion about this back in April and there was a >> suggestion for implementing a 5245-style hack where the answerer basically >> resends the 180 until it knows that it has been received. >> >> 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions >> when the first connectivity check is received) but we don't have that >> option here since the 180 may contain either none or only host candidates >> so there are strong chances that no binding request would be received on >> them. >> >> Thomas also suggested a second option which would be to also use INFO >> requests with trickled candidates as an indication that 180 was received. >> This however wouldn't work with half trickle so we are basically back to >> vanilla ICE for all (non-re) INVITEs. >> >> Another option would be to mandate an INFO request with "end-of-candidates" >> in response to the 180, but that would be just the same as mandating PRACK >> support. >> >> Thomas also suggested that the answerer can start sending INFOs right after >> it sends its answer in the 180 and then it can just resend the 180 if the >> INFOs result in a 481 response. >> >> Personally I think this could potentially be made to work, but it would >> imply a level of complexity that considerably exceeds PRACK support. >> >> Opinions? >> >> Q2: How do we send INFOs? Are they blocking or do we just send them in >> parallel? If the latter, then what happens when an INFO fails because it is >> received out of order? Do we just tell the application to resend the >> candidates asap? >> >> This also leads to the following question: >> >> Q3: What exactly do we send in INFOs? Just the latest batch of freshly >> learned candidates or all candidates we've learned so far? Dale suggested >> that if we do this cumulatively we wouldn't need to worry about the case >> with the out-of-order INFOs from Q2 since the information gets resent >> anyway. A drawback here would obviously be that this adds more complexity >> for trickle ICE users (WebRTC applications specifically) >> >> A third option would be to allow both and leave it to the application. >> >> Comments are most welcome! >> >> Emil >> > > > - -- > 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) > > iQIcBAEBCAAGBQJR1wI1AAoJECnERZXWan7EpOUQAIEFAeuFxkj0IJoWhiPXBb/L > ulHURlg00WoK9RJFxLFWHP36lmaQ2y0v7LaFgX1hFoG9TMmMCbyxIfnva+5QFYzx > LkiOZcgM5XuXjk6Ruke2/vrgByCPPYiCc7+K01+7NMO6tQL8rKxKr1Hq5PPRkUHY > V6PO+XQd+KK8dm2W1qsR9s16goxqqQzeYJsEOX9mTGjqQdaju75FY88FdFE2rhib > pdNrr+crC+gqdz/LKMS9so+dKtMMl3KNT39umDQuFkN9Gt+xorbKkvARCbB24xO3 > jPX7koQ0v/eJd1lZwmgkrzMiBDnr/RHigIX3OIuNhL5xilf0Daps5jIkvIJT31gJ > CUsfR78ykrWp3wJJ7Ck+PQpAyUrCpcctCUR6kEZ4g1gaKRAEWfw1MgieETqtLE8x > Dwsy2c3Qw7XPi1VRMfc6BmCbrd59hQtIsF07yHZEJuHz8zuJoWN9mKLMsGJn4E4G > ipIQwruOde7B23YUI0kqBzldRnw5sQ5XDi//rNnd2/KaMhSdxB5+A+g+yy2yQIyN > m7It4KZ1+BiyOrgK2w8JHkkmbclSV5j3hEEv0pfgt3OoXWwuUqF2rjdQ4NfsXRj4 > D05DUrhrgP7HKp+wxsIi2yyxFaZhkIBnooV/AhyDEh4Lk1KbKPPrSaEUyo6/5CmQ > CtZLNHXi/Xv3Y3PjrpJF > =DFTv > -----END PGP SIGNATURE----- From petithug@acm.org Fri Jul 5 15:45: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 DE82521F9D7A for ; Fri, 5 Jul 2013 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Az0BBwGoaCWP for ; Fri, 5 Jul 2013 15:45:30 -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 A0D5E21F9D78 for ; Fri, 5 Jul 2013 15:45:30 -0700 (PDT) Received: from [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c] (unknown [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c]) (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 05E1520415; Sat, 6 Jul 2013 00:45:27 +0200 (CEST) Message-ID: <51D74C85.2080700@acm.org> Date: Fri, 05 Jul 2013 15:45:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51D43186.2010907@jitsi.org> <51D70236.5070508@acm.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 22:45:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/05/2013 02:59 PM, Emil Ivov wrote: > On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin > wrote: Hi, > > I did not receive much comments on my proposal to use STUN packets to > carry the new ICE candidates. To summarize, instead of using the SDP in an > INFO and or UPDATE transaction, the new candidates can be sent on the same > path that the media will use by default (i.e. using the candidate that is > copied in the m= and c= line). Because this candidate is chosen to always > succeed (using a TURN server), the candidate will always reach their > destination. This will remove any problem in the signaling path, because > it is no longer used to update the candidates. > >> Here's my take: Default candidates are not guaranteed to work. Sorry, my summary was incorrect. It is assumed that half-trickle is used (for the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3), so the offerer sends the full set of candidates. >> Also, you only get to place one candidate as default. What if your peer >> is IPv6 only and you chose an IPv4 candidate? With the offerer full set of candidates, it is easy to find the IPv6 TURN candidate. > Or, what if you are both on the same LAN with >> limited Internet connectivity? Or what if the service you use doesn't >> even have a TURN server? Then what about sending the answerer candidates using all the offerer candidates available, but in reversed priority order? >> I am sure we can come up with many other similar situations. > >> The only transport that's guaranteed to work prior to ICE is signalling. >> There's nothing else that's as reliable as this. (If there was then we >> probably wouldn't even need ICE in the first place). ICE is less about reliability than about latency, i.e. so far nobody proposed to tunnel the media over SIP :-) > >> Emil > >> -- https://jitsi.org > > > Thanks. > > On 07/03/2013 07:13 AM, Emil Ivov wrote: >>>> Hey all, >>>> >>>> Christer, Enrico and I are preparing the next version of Trickle ICE >>>> for SIP. Now that discussions on BUNDLE and the plans seem to be >>>> winding down, we wanted to run a few questions by the working group. >>>> >>>> Q1: Making reliable provisional responses and PRACK mandatory. >>>> Obviously this would be nice to avoid, so the question is: is there a >>>> reasonable mechanism to achieve this (and by reasonable, we mean >>>> something that wouldn't be harder than implementing support for >>>> PRACK). >>>> >>>> There was some discussion about this back in April and there was a >>>> suggestion for implementing a 5245-style hack where the answerer >>>> basically resends the 180 until it knows that it has been received. >>>> >>>> 5245 uses connectivity checks for this (i.e. it stops 180 >>>> retransmissions when the first connectivity check is received) but we >>>> don't have that option here since the 180 may contain either none or >>>> only host candidates so there are strong chances that no binding >>>> request would be received on them. >>>> >>>> Thomas also suggested a second option which would be to also use >>>> INFO requests with trickled candidates as an indication that 180 was >>>> received. This however wouldn't work with half trickle so we are >>>> basically back to vanilla ICE for all (non-re) INVITEs. >>>> >>>> Another option would be to mandate an INFO request with >>>> "end-of-candidates" in response to the 180, but that would be just >>>> the same as mandating PRACK support. >>>> >>>> Thomas also suggested that the answerer can start sending INFOs right >>>> after it sends its answer in the 180 and then it can just resend the >>>> 180 if the INFOs result in a 481 response. >>>> >>>> Personally I think this could potentially be made to work, but it >>>> would imply a level of complexity that considerably exceeds PRACK >>>> support. >>>> >>>> Opinions? >>>> >>>> Q2: How do we send INFOs? Are they blocking or do we just send them >>>> in parallel? If the latter, then what happens when an INFO fails >>>> because it is received out of order? Do we just tell the application >>>> to resend the candidates asap? >>>> >>>> This also leads to the following question: >>>> >>>> Q3: What exactly do we send in INFOs? Just the latest batch of >>>> freshly learned candidates or all candidates we've learned so far? >>>> Dale suggested that if we do this cumulatively we wouldn't need to >>>> worry about the case with the out-of-order INFOs from Q2 since the >>>> information gets resent anyway. A drawback here would obviously be >>>> that this adds more complexity for trickle ICE users (WebRTC >>>> applications specifically) >>>> >>>> A third option would be to allow both and leave it to the >>>> application. >>>> >>>> Comments are most welcome! >>>> >>>> Emil >>>> > > > _______________________________________________ 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) iQIcBAEBCAAGBQJR10yBAAoJECnERZXWan7EmtYP+wa1qTpgQNYZpZc5T+/f9+j7 QJRnTlcU7aIiCX2wDHUILbUk4YCiOh8wKHf7OiLbtAKYlgq+98KyQuViVeiRoVGl qpRQnE+Y1SjqY/jVVc4UwJvEeP2TbW5ARmUG/bqN/dLQzNyhyJeBmBIMzYTpmxl7 SJ1M8xB5Emn8d03zb7jdUtTcy0HqN4a88R3HZqmVWH4M+wRWKVZlq4RGbpiy03Or WKc4VFUsuQnRGMZbmkG3EGrEJEhA+kCAthKY1+EORSO6sIUYQVxq58pRmuF8DTgm h7MO6Qtco8dJsVqgT2HQ9BZiQ60XP6X+xUPIIjJ3cHaZfjqxC6oSUKo+FXpP9Gaq euoEbKdxiA9D37CN2vMWpcLqk0GUOE+7uJ8QVWMfYWTVWCZE1XO9uVhYnNkYtcNN 15zmqvzTRrv0qQlCzgLSfeXpBAcsv46GZdqd/HKcczlgutFil7QNFyKAJD9njNLg VeO5nWs5Koqn8cug+GlBG/dFNTdFss/0vlX6HsBdyqIpWKPdf4gwueAS3QVieUEb cMFKOUzThLpOgTkkhzJQuY9N6ynBiF8Cn1t1cPJQZksMtuKRjRJo5BKHOfwLufk4 fgLJOuUEJkcklrrBIbqRfpfERGQ4aFZMxvWN3LO3vx4a3bL4/M8kGst871MWMR1S EEdIVr/mOjJMEimq9cjK =bnR1 -----END PGP SIGNATURE----- From emil@sip-communicator.org Fri Jul 5 15:53: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 2BFC321F9D80 for ; Fri, 5 Jul 2013 15:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM4F6Sejzg7e for ; Fri, 5 Jul 2013 15:53:35 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 49C0121F9D83 for ; Fri, 5 Jul 2013 15:53:35 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so2326009wes.37 for ; Fri, 05 Jul 2013 15:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=BmfjBl2ibX0eAJh/2EYEB9dIIWOEjKsucFOC6ca2sqY=; b=DukV6IxelaRCkRSmLoQSR0Uib+Q1mCy/Pptp+4VnM5BjEI2zYtWTobswIcoTgvvFjy NAb8H2bYMMbULGj9/AHvQ5pBka7mO83yL2MfGVkbWzfGCgxJID6XoqdPIV8nw0fTywZE g/Vp6epIZ9qIoL7fKK2gjC99OkIPEtmKrzdaRFBUDlTeasbcFH+7pAxzHbzQOzOasNm+ nDHK19B1dGRT9xLGMiNzHDynHm8V1eABDsJbnDrzRgWiHLEQVZEZMy3k/WjJzOBHkdxI B8WIaiIpC+ivRgceRBGHjG/h3zv1gxtLuhxMmcvrUzsEz5za5UCrStVkAs/N2aCJa4HX hdoQ== X-Received: by 10.194.234.100 with SMTP id ud4mr7232688wjc.44.1373064814271; Fri, 05 Jul 2013 15:53:34 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id fb9sm43225519wid.2.2013.07.05.15.53.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 15:53:31 -0700 (PDT) Message-ID: <51D74E6A.7020902@jitsi.org> Date: Sat, 06 Jul 2013 00:53:30 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <51D43186.2010907@jitsi.org> <51D70236.5070508@acm.org> <51D74C85.2080700@acm.org> In-Reply-To: <51D74C85.2080700@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlaYieBRaktD/fd5yI6duj7uQvW36N6sXskXmhX3ZL2CJugmCBUepalErzouMWQuBGMOPWk Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 22:53:44 -0000 On 06.07.13, 00:45, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/05/2013 02:59 PM, Emil Ivov wrote: >> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin >> wrote: Hi, >> >> I did not receive much comments on my proposal to use STUN packets to >> carry the new ICE candidates. To summarize, instead of using the SDP in an >> INFO and or UPDATE transaction, the new candidates can be sent on the same >> path that the media will use by default (i.e. using the candidate that is >> copied in the m= and c= line). Because this candidate is chosen to always >> succeed (using a TURN server), the candidate will always reach their >> destination. This will remove any problem in the signaling path, because >> it is no longer used to update the candidates. >> >>> Here's my take: Default candidates are not guaranteed to work. > > Sorry, my summary was incorrect. It is assumed that half-trickle is used (for > the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3), so the > offerer sends the full set of candidates. Are you suggesting that we would always need to do half trickle, even when we know the other party has support for trickle and can switch to full? > >>> Also, you only get to place one candidate as default. What if your peer >>> is IPv6 only and you chose an IPv4 candidate? > > With the offerer full set of candidates, it is easy to find the IPv6 TURN > candidate. > >> Or, what if you are both on the same LAN with >>> limited Internet connectivity? Or what if the service you use doesn't >>> even have a TURN server? > > Then what about sending the answerer candidates using all the offerer > candidates available, but in reversed priority order? Even then, endpoint dependent filtering (which seems to be the default these days) requires that both ends start sending packets simultaneously for server-reflexive addresses to work. In the case above the trickled candidates wouldn't be able to reach the offerer because it wouldn't be sending anything toward the answerer. >>> I am sure we can come up with many other similar situations. >> >>> The only transport that's guaranteed to work prior to ICE is signalling. >>> There's nothing else that's as reliable as this. (If there was then we >>> probably wouldn't even need ICE in the first place). > > ICE is less about reliability than about latency, I believe it's always been about both. (Otherwise we would have probably stopped at STUN). > i.e. so far nobody proposed > to tunnel the media over SIP :-) You'd be surprised ;) https://java.net/projects/jain-sip-applet-phone Emil > >> >>> Emil >> >>> -- https://jitsi.org >> >> >> Thanks. >> >> On 07/03/2013 07:13 AM, Emil Ivov wrote: >>>>> Hey all, >>>>> >>>>> Christer, Enrico and I are preparing the next version of Trickle ICE >>>>> for SIP. Now that discussions on BUNDLE and the plans seem to be >>>>> winding down, we wanted to run a few questions by the working group. >>>>> >>>>> Q1: Making reliable provisional responses and PRACK mandatory. >>>>> Obviously this would be nice to avoid, so the question is: is there a >>>>> reasonable mechanism to achieve this (and by reasonable, we mean >>>>> something that wouldn't be harder than implementing support for >>>>> PRACK). >>>>> >>>>> There was some discussion about this back in April and there was a >>>>> suggestion for implementing a 5245-style hack where the answerer >>>>> basically resends the 180 until it knows that it has been received. >>>>> >>>>> 5245 uses connectivity checks for this (i.e. it stops 180 >>>>> retransmissions when the first connectivity check is received) but we >>>>> don't have that option here since the 180 may contain either none or >>>>> only host candidates so there are strong chances that no binding >>>>> request would be received on them. >>>>> >>>>> Thomas also suggested a second option which would be to also use >>>>> INFO requests with trickled candidates as an indication that 180 was >>>>> received. This however wouldn't work with half trickle so we are >>>>> basically back to vanilla ICE for all (non-re) INVITEs. >>>>> >>>>> Another option would be to mandate an INFO request with >>>>> "end-of-candidates" in response to the 180, but that would be just >>>>> the same as mandating PRACK support. >>>>> >>>>> Thomas also suggested that the answerer can start sending INFOs right >>>>> after it sends its answer in the 180 and then it can just resend the >>>>> 180 if the INFOs result in a 481 response. >>>>> >>>>> Personally I think this could potentially be made to work, but it >>>>> would imply a level of complexity that considerably exceeds PRACK >>>>> support. >>>>> >>>>> Opinions? >>>>> >>>>> Q2: How do we send INFOs? Are they blocking or do we just send them >>>>> in parallel? If the latter, then what happens when an INFO fails >>>>> because it is received out of order? Do we just tell the application >>>>> to resend the candidates asap? >>>>> >>>>> This also leads to the following question: >>>>> >>>>> Q3: What exactly do we send in INFOs? Just the latest batch of >>>>> freshly learned candidates or all candidates we've learned so far? >>>>> Dale suggested that if we do this cumulatively we wouldn't need to >>>>> worry about the case with the out-of-order INFOs from Q2 since the >>>>> information gets resent anyway. A drawback here would obviously be >>>>> that this adds more complexity for trickle ICE users (WebRTC >>>>> applications specifically) >>>>> >>>>> A third option would be to allow both and leave it to the >>>>> application. >>>>> >>>>> Comments are most welcome! >>>>> >>>>> Emil >>>>> >> >> >> _______________________________________________ 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) > > iQIcBAEBCAAGBQJR10yBAAoJECnERZXWan7EmtYP+wa1qTpgQNYZpZc5T+/f9+j7 > QJRnTlcU7aIiCX2wDHUILbUk4YCiOh8wKHf7OiLbtAKYlgq+98KyQuViVeiRoVGl > qpRQnE+Y1SjqY/jVVc4UwJvEeP2TbW5ARmUG/bqN/dLQzNyhyJeBmBIMzYTpmxl7 > SJ1M8xB5Emn8d03zb7jdUtTcy0HqN4a88R3HZqmVWH4M+wRWKVZlq4RGbpiy03Or > WKc4VFUsuQnRGMZbmkG3EGrEJEhA+kCAthKY1+EORSO6sIUYQVxq58pRmuF8DTgm > h7MO6Qtco8dJsVqgT2HQ9BZiQ60XP6X+xUPIIjJ3cHaZfjqxC6oSUKo+FXpP9Gaq > euoEbKdxiA9D37CN2vMWpcLqk0GUOE+7uJ8QVWMfYWTVWCZE1XO9uVhYnNkYtcNN > 15zmqvzTRrv0qQlCzgLSfeXpBAcsv46GZdqd/HKcczlgutFil7QNFyKAJD9njNLg > VeO5nWs5Koqn8cug+GlBG/dFNTdFss/0vlX6HsBdyqIpWKPdf4gwueAS3QVieUEb > cMFKOUzThLpOgTkkhzJQuY9N6ynBiF8Cn1t1cPJQZksMtuKRjRJo5BKHOfwLufk4 > fgLJOuUEJkcklrrBIbqRfpfERGQ4aFZMxvWN3LO3vx4a3bL4/M8kGst871MWMR1S > EEdIVr/mOjJMEimq9cjK > =bnR1 > -----END PGP SIGNATURE----- > -- https://jitsi.org From petithug@acm.org Fri Jul 5 16:14: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 7101C21F9B4D for ; Fri, 5 Jul 2013 16:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDvwftO7bkrX for ; Fri, 5 Jul 2013 16:14:42 -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 635BB21F9A13 for ; Fri, 5 Jul 2013 16:14:37 -0700 (PDT) Received: from [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c] (unknown [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c]) (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 62BAB20415; Sat, 6 Jul 2013 01:14:36 +0200 (CEST) Message-ID: <51D75359.30409@acm.org> Date: Fri, 05 Jul 2013 16:14:33 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51D43186.2010907@jitsi.org> <51D70236.5070508@acm.org> <51D74C85.2080700@acm.org> <51D74E6A.7020902@jitsi.org> In-Reply-To: <51D74E6A.7020902@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 23:14:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/05/2013 03:53 PM, Emil Ivov wrote: > > > On 06.07.13, 00:45, Marc Petit-Huguenin wrote: On 07/05/2013 02:59 PM, Emil > Ivov wrote: >>>> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin >>>> wrote: Hi, >>>> >>>> I did not receive much comments on my proposal to use STUN packets >>>> to carry the new ICE candidates. To summarize, instead of using the >>>> SDP in an INFO and or UPDATE transaction, the new candidates can be >>>> sent on the same path that the media will use by default (i.e. using >>>> the candidate that is copied in the m= and c= line). Because this >>>> candidate is chosen to always succeed (using a TURN server), the >>>> candidate will always reach their destination. This will remove any >>>> problem in the signaling path, because it is no longer used to update >>>> the candidates. >>>> >>>>> Here's my take: Default candidates are not guaranteed to work. > > Sorry, my summary was incorrect. It is assumed that half-trickle is used > (for the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3), > so the offerer sends the full set of candidates. > >> Are you suggesting that we would always need to do half trickle, even >> when we know the other party has support for trickle and can switch to >> full? No, I just am saying that the solution that I propose does not take in account full-trickle. > >>>>> Also, you only get to place one candidate as default. What if your >>>>> peer is IPv6 only and you chose an IPv4 candidate? > > With the offerer full set of candidates, it is easy to find the IPv6 TURN > candidate. > >>>> Or, what if you are both on the same LAN with >>>>> limited Internet connectivity? Or what if the service you use >>>>> doesn't even have a TURN server? > > Then what about sending the answerer candidates using all the offerer > candidates available, but in reversed priority order? > >> Even then, endpoint dependent filtering (which seems to be the default >> these days) requires that both ends start sending packets simultaneously >> for server-reflexive addresses to work. > >> In the case above the trickled candidates wouldn't be able to reach the >> offerer because it wouldn't be sending anything toward the answerer. Right. > >>>>> I am sure we can come up with many other similar situations. >>>> >>>>> The only transport that's guaranteed to work prior to ICE is >>>>> signalling. There's nothing else that's as reliable as this. (If >>>>> there was then we probably wouldn't even need ICE in the first >>>>> place). > > ICE is less about reliability than about latency, > >> I believe it's always been about both. (Otherwise we would have probably >> stopped at STUN). You mean TURN? As long as you do not care about latency, TURN is all you need as it always works (and that's all we used for a long time, even if it was not called TURN). ICE was invented because latency was important - so STUN was useful - but there is no reliable way to predict if it will work. > > i.e. so far nobody proposed to tunnel the media over SIP :-) > >> You'd be surprised ;) > >> https://java.net/projects/jain-sip-applet-phone Hmm, I do not see SIP as media transport in this project. What I meant was something like transporting the media in a SIP INFO. > >> Emil > >>>> >>>>> Emil >>>> >>>>> -- https://jitsi.org >>>> >>>> >>>> Thanks. >>>> >>>> On 07/03/2013 07:13 AM, Emil Ivov wrote: >>>>>>> Hey all, >>>>>>> >>>>>>> Christer, Enrico and I are preparing the next version of >>>>>>> Trickle ICE for SIP. Now that discussions on BUNDLE and the >>>>>>> plans seem to be winding down, we wanted to run a few questions >>>>>>> by the working group. >>>>>>> >>>>>>> Q1: Making reliable provisional responses and PRACK mandatory. >>>>>>> Obviously this would be nice to avoid, so the question is: is >>>>>>> there a reasonable mechanism to achieve this (and by >>>>>>> reasonable, we mean something that wouldn't be harder than >>>>>>> implementing support for PRACK). >>>>>>> >>>>>>> There was some discussion about this back in April and there >>>>>>> was a suggestion for implementing a 5245-style hack where the >>>>>>> answerer basically resends the 180 until it knows that it has >>>>>>> been received. >>>>>>> >>>>>>> 5245 uses connectivity checks for this (i.e. it stops 180 >>>>>>> retransmissions when the first connectivity check is received) >>>>>>> but we don't have that option here since the 180 may contain >>>>>>> either none or only host candidates so there are strong chances >>>>>>> that no binding request would be received on them. >>>>>>> >>>>>>> Thomas also suggested a second option which would be to also >>>>>>> use INFO requests with trickled candidates as an indication >>>>>>> that 180 was received. This however wouldn't work with half >>>>>>> trickle so we are basically back to vanilla ICE for all >>>>>>> (non-re) INVITEs. >>>>>>> >>>>>>> Another option would be to mandate an INFO request with >>>>>>> "end-of-candidates" in response to the 180, but that would be >>>>>>> just the same as mandating PRACK support. >>>>>>> >>>>>>> Thomas also suggested that the answerer can start sending INFOs >>>>>>> right after it sends its answer in the 180 and then it can just >>>>>>> resend the 180 if the INFOs result in a 481 response. >>>>>>> >>>>>>> Personally I think this could potentially be made to work, but >>>>>>> it would imply a level of complexity that considerably exceeds >>>>>>> PRACK support. >>>>>>> >>>>>>> Opinions? >>>>>>> >>>>>>> Q2: How do we send INFOs? Are they blocking or do we just send >>>>>>> them in parallel? If the latter, then what happens when an INFO >>>>>>> fails because it is received out of order? Do we just tell the >>>>>>> application to resend the candidates asap? >>>>>>> >>>>>>> This also leads to the following question: >>>>>>> >>>>>>> Q3: What exactly do we send in INFOs? Just the latest batch of >>>>>>> freshly learned candidates or all candidates we've learned so >>>>>>> far? Dale suggested that if we do this cumulatively we wouldn't >>>>>>> need to worry about the case with the out-of-order INFOs from >>>>>>> Q2 since the information gets resent anyway. A drawback here >>>>>>> would obviously be that this adds more complexity for trickle >>>>>>> ICE users (WebRTC applications specifically) >>>>>>> >>>>>>> A third option would be to allow both and leave it to the >>>>>>> application. >>>>>>> >>>>>>> Comments are most welcome! >>>>>>> >>>>>>> Emil >>>>>>> >>>> >>>> >>>> _______________________________________________ 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) iQIcBAEBCAAGBQJR11NYAAoJECnERZXWan7ECZwP/0skdKa9lXHs4/ogcAR+IFUA INllP0esEp62ZtB5jOMJ2HrMEqOdyi/kFS1Ya5MnK+l5UzYnxCwDWIxC8EH/RHkp k8MoT2W98lcIevlSiF1qZnOw8b8EJjUBbM2uQA0r3wiksRL6McbKF1iCnhhIoFOG W4i8ap7XJYy2vc5SNUcyWyDboIG6lMt2RFAw0FZiHoCZmtSjQBVJUIxqdrfQ0zvA gFJLnKLSCAyuk7wtpeQhXvys8I4ZmGBx2J2WRORE1lyoxGJm8C0f3Eh+4IsjMcL3 JKgdRiOIpCjBDvtD4mONp+zsVTc6O5+ngn49ew5yUnqE+IEiysMWFvKzQKuwzFqE q1OYXU8tY3W+r39qcGy8ov0Eiyuyf7i7O5pcMeRGhDvgQZkFxI9iP2ArSEKUSxOZ FnWBESZ5Z3HkXbbS1Rw+4RxaMOT7DvJzDvKNbfW08DK4lpifPpcNThIvOlHnoO8u F6iZpuQ8PHYBw3ZFn2255KvwK3LA8vwcKj2ZYSY7btHBg/gP6PoVK2KNewxp+CDa kn+8SpETE8BcbirJPKoMVxGFMYBQQBnHx9i7ikpDLOxS8G85M6mRnPQdH3D3Gavg BBgXp+dvMV4hTKz5Kd9BmACUaxD47RAp3Faplrq/lmDcC3xqsLmqu0/C5UdPR5Jm CzjedrEUr+QNmpmd/VFU =sbN1 -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Sun Jul 7 11:59: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 C7B8221F9AA2 for ; Sun, 7 Jul 2013 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 iHuFPCwbgNFk for ; Sun, 7 Jul 2013 11:59:32 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id F084021F99AE for ; Sun, 7 Jul 2013 11:59:31 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id xWr21l0011wpRvQ5FWzXAT; Sun, 07 Jul 2013 18:59:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id xWzW1l00l3ZTu2S3eWzXjX; Sun, 07 Jul 2013 18:59:31 +0000 Message-ID: <51D9BA91.8020306@alum.mit.edu> Date: Sun, 07 Jul 2013 14:59:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.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=1373223571; bh=xpiTdkfIUuZrF8V3EgWlxVV+sh4rvdHW9LnEZ0NPy6E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TVpArb3nOhsUCKvMoAJn0VqBtb8M0N5x9Kn2iOIIxYzUZfkmZNZwh2a6TDUUV1YfK JB5mqTlNcxGSYbXimUQJzgQEFjazeziK8lEHSHRhsDNSDoBb5AjB911rRFzDnjIUAR BfYCQmEWSyZCOSNaGTbTUAVhhuSThkPd/vxcYP3DSjygTj6lMLscDfgyUWQ+DOrUrl pgjXojDz17V2aqqA0tchjPs9jrH8CnyO7RD+EX7clBB+sA0h2+OMv87KnZ56Tq/laR zWG8nC/+KpfjXV86wuOVrPucuyKhA+J47CtQu4uc7X9g4X3YToLyIH48G7qo463ivC PS4rd6fiB2Xgw== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Sun, 07 Jul 2013 18:59:36 -0000 On 7/3/13 1:06 AM, Mo Zanaty (mzanaty) wrote: > To clarify, I have no plan to use or abuse Plan A. The implementations I'm most interested in are all closer to Plan B. However, I'm aware of widely deployed implementations (from other vendors) which are closer to Plan A in general, and specifically for the thumbnail example below (one m-line per thumbnail, all with the same port/PT). While I personally would not chose this, I see no reason to forbid it, because I recognize it is just personal preference. Since there currently is no BUNDLE, I don't know how you can say an implementation is closer to any of the plans. Instead, you can only hypothesize on how such an application might use any of the bundling schemes if it became available. Thanks, Paul > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 6:40 PM > To: Mo Zanaty (mzanaty) > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. >> >> It seems you both want to mandate this (Plan B). Why? I see no reason for bundle to pick a plan. Let the plan wars rage outside bundle. > > So you want to use plan A *without* the association, so that the *only* > purpose of the extra m-lines is to denote the number of flows? > > How would the receiver know if an incoming packet was associated with > one of the flows defined by the m-lines? > > How would the receiver know if each ssrc should be treated as a > different flow, or if appid should be used to define flows? > > I think you abuse plan A. Its different with plan B or No Plan. There > you still need the ability to associate packets to m-lines, but that > isn't sufficient to map them to flows. It is assumed that "extra" > information, learned by different means, is used to sort out the flows. > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 4:00 PM >> To: Christer Holmberg >> Cc: Mo Zanaty (mzanaty); mmusic@ietf.org >> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> +1 >> (Except that I *am* Paul) >> >> On 7/2/13 2:30 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I am not Paul, but just to verify that I understand his issue, the question is: >>> >>> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line? >>> >>> Regards, >>> >>> Christer >>> >>> -----Alkuperäinen viesti----- >>> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty) >>> Lähetetty: 2. heinäkuuta 2013 19:09 >>> Vastaanottaja: Paul Kyzivat >>> Kopio: mmusic@ietf.org >>> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>> >>> An attempt at "an answer that makes sense". (Just snippets, not full SDP.) >>> >>> m=video 10000 RTP/SAVPF 96 >>> a=rtpmap:96 H264/90000 >>> a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker). >>> >>> You could mandate that PT must be unique to allow unique mapping. >>> >>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. >>> >>> Which do you want to mandate and why? >>> >>> Cheers, >>> Mo >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Tuesday, July 02, 2013 10:06 AM >>> To: Mo Zanaty (mzanaty) >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>> >>> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>>> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology? >>>> >>>> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan. >>> >>> I'm going to keep asking this question until I get an answer that makes >>> sense: >>> >>> Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. >>> >>> The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. >>> If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. >>> >>> The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping. >>> >>> Thanks, >>> Paul >>> >>>> Mo >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Saturday, June 29, 2013 12:12 PM >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>>> >>>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>>> Christer, >>>>> >>>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed. >>>>>> >>>>>> We haven't had that much discussion about it yet, so I will not ask >>>>>> a DECISION question at this point, but I would really like to get >>>>>> some input from people who have opinions about this :) >>>>> >>>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. >>>> >>>> I just replied elsewhere on this. >>>> My opinion turns out to be the exact opposite of yours: we need to >>>> support multiple algorithms, and that all applications should care. >>>> >>>> I won't repeat the stuff about multiple algorithms. >>>> >>>> I will repeat what I have said about the need for being able to associate: >>>> >>>> There must have been *some* reason that two m-lines were used, rather >>>> than just one. Each m-line heads a media section of the SDP that >>>> contains a bunch of declarations. Something must be different in those >>>> two media sections, or else a single media section would have been >>>> enough. Presumably whatever it is that is different is intended to >>>> affect how received packets are processed or interpreted. (If not, >>>> again there is no need for it to be there.) If you can't associate the >>>> packet with the m-line, then you don't know which of the multiple >>>> interpretations to apply to the packet. >>>> >>>> Maybe there is some exception to this, though I haven't come up with >>>> anything. If there is, then I hope someone will call it out. If so, >>>> then the constraint can be tightened. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> > > From pkyzivat@alum.mit.edu Sun Jul 7 12:13: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 E9B8411E80FC for ; Sun, 7 Jul 2013 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.87 X-Spam-Level: X-Spam-Status: No, score=0.87 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 oJSEQGTpFIyg for ; Sun, 7 Jul 2013 12:13:14 -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 5484811E80FB for ; Sun, 7 Jul 2013 12:13:13 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id xWUZ1l0030EZKEL56XDDBT; Sun, 07 Jul 2013 19:13:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id xXDD1l00F3ZTu2S3MXDD0L; Sun, 07 Jul 2013 19:13:13 +0000 Message-ID: <51D9BDC8.80507@alum.mit.edu> Date: Sun, 07 Jul 2013 15:13:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se> <51D33146.9010402@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DE77@xmb-rcd-x14.cisco.com> <51D356C7.2030909@alum.mit.edu>, <3879D71E758A7E4AA99A35DD8D41D3D91D48E258@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C1F8C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3C1F8C@ESESSMB209.ericsson.se> 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=1373224393; bh=i4c5IYAqTUrIc1h6trLl1Vo0ERWCDMmk/d+N+c4OicY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jVlxMI2ocPsWuJtzkdn530NbB5hICHV24Ph3b2eWCN4in4Lm9zIFbKl+dS8ecpw8m cRdhZ/1pWNpCHSbpDKmLMJX4h1baIml04CUZ6cI+j81tA0ulZVlTUZSzbW97tuEeix RjOItIQ25Iry1PLxFWjTkS9oKLJ6NNkZAo9W/Fsn6vYOd6eN7UGXv+vEehL0NvdznC Sv1QzQ1bp3BN+idTtlMwuiVo5c4tvPdE9EIBDJYwr2MMu15dWDpah7TnOUz/MZXz7D tFtZzQGFN3D97bwkE4hRvoDcpqnsqUX8cn+qqcm2TUOvTxHA/Naynpbn5SksPr/0m1 Oomvc3qOUoo5g== Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to 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: Sun, 07 Jul 2013 19:13:19 -0000 On 7/3/13 7:38 AM, Christer Holmberg wrote: > > Hi, > I guess one advantage with 4 m- lines is that, if the remote endpoint > does not support BUNDLE, it will allow to have a separate 5-tuple for > each thumbnail stream, without having to send a "fallack" offer. > When both endpoints do support BUNDLE it makes little sense, but when > thinking about it I really wonder if there is a reason to forbid it. Yes, perhaps it is an interesting case to consider. I think there is still an issue, but maybe it needs to be refined. ISTM that *if* there is a subset of bundled media-sections that are indistinguishable other than by position or the address-info that will become common when the bundle is accepted, then it is only necessary that there be a way to associate a media packet to the subset, not to an individual m-line within that subset. (This is because being able to do so would not yield any useful information.) Unfortunately, trying to turn that into clear text in the draft will be a challenge. :-( The point I am trying to make about this is that when there is something *different* about the media sections, then only by associating media packets to m-lines is is possible to associate that other info with the packet. For instance, suppose each of the bundled m-lines has an associated a=label attribute. Then it is necessary to be able to associate a packet to an m-line in order to know which label applies to it, and that can impact what application level processing is done. Thanks, Paul > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Mo Zanaty (mzanaty) [mzanaty@cisco.com] > *To:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; > mmusic@ietf.org [mmusic@ietf.org] > *Subject:* RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism > to map received data to m- line? > To clarify, I have no plan to use or abuse Plan A. The implementations > I'm most interested in are all closer to Plan B. However, I'm aware of > widely deployed implementations (from other vendors) which are closer to > Plan A in general, and specifically for the thumbnail example below (one > m-line per thumbnail, all with the same port/PT). While I personally > would not chose this, I see no reason to forbid it, because I recognize > it is just personal preference. > > Mo > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 6:40 PM > To: Mo Zanaty (mzanaty) > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to > map received data to m- line? > > On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote: >>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. >> >> It seems you both want to mandate this (Plan B). Why? I see no reason for bundle to pick a plan. Let the plan wars rage outside bundle. > > So you want to use plan A *without* the association, so that the *only* > purpose of the extra m-lines is to denote the number of flows? > > How would the receiver know if an incoming packet was associated with > one of the flows defined by the m-lines? > > How would the receiver know if each ssrc should be treated as a > different flow, or if appid should be used to define flows? > > I think you abuse plan A. Its different with plan B or No Plan. There > you still need the ability to associate packets to m-lines, but that > isn't sufficient to map them to flows. It is assumed that "extra" > information, learned by different means, is used to sort out the flows. > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 02, 2013 4:00 PM >> To: Christer Holmberg >> Cc: Mo Zanaty (mzanaty); mmusic@ietf.org >> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> +1 >> (Except that I *am* Paul) >> >> On 7/2/13 2:30 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I am not Paul, but just to verify that I understand his issue, the question is: >>> >>> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line? >>> >>> Regards, >>> >>> Christer >>> >>> -----Alkuperäinen viesti----- >>> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty) >>> Lähetetty: 2. heinäkuuta 2013 19:09 >>> Vastaanottaja: Paul Kyzivat >>> Kopio: mmusic@ietf.org >>> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>> >>> An attempt at "an answer that makes sense". (Just snippets, not full SDP.) >>> >>> m=video 10000 RTP/SAVPF 96 >>> a=rtpmap:96 H264/90000 >>> a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> m=video 10000 RTP/SAVPF 97 >>> a=rtpmap:97 H264/90000 >>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly >>> >>> No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker). >>> >>> You could mandate that PT must be unique to allow unique mapping. >>> >>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. >>> >>> Which do you want to mandate and why? >>> >>> Cheers, >>> Mo >>> >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Tuesday, July 02, 2013 10:06 AM >>> To: Mo Zanaty (mzanaty) >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>> >>> On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >>>> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping > mechanism. You MAY use the mechanism(s) described here, or some other > mechanism." But why mandate such a tautology? >>>> >>>> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for > multiple streams with the same processing. I don't think we want to > force bundle to pick a plan. >>> >>> I'm going to keep asking this question until I get an answer that makes >>> sense: >>> >>> Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. >>> >>> The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. >>> If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. >>> >>> The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be > doing something *equivalent* to the mapping. >>> >>> Thanks, >>> Paul >>> >>>> Mo >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Saturday, June 29, 2013 12:12 PM >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >>>> >>>> On 6/29/13 8:50 AM, Colin Perkins wrote: >>>>> Christer, >>>>> >>>>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's > not needed. >>>>>> >>>>>> We haven't had that much discussion about it yet, so I will not ask >>>>>> a DECISION question at this point, but I would really like to get >>>>>> some input from people who have opinions about this :) >>>>> >>>>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. >>>> >>>> I just replied elsewhere on this. >>>> My opinion turns out to be the exact opposite of yours: we need to >>>> support multiple algorithms, and that all applications should care. >>>> >>>> I won't repeat the stuff about multiple algorithms. >>>> >>>> I will repeat what I have said about the need for being able to associate: >>>> >>>> There must have been *some* reason that two m-lines were used, rather >>>> than just one. Each m-line heads a media section of the SDP that >>>> contains a bunch of declarations. Something must be different in those >>>> two media sections, or else a single media section would have been >>>> enough. Presumably whatever it is that is different is intended to >>>> affect how received packets are processed or interpreted. (If not, >>>> again there is no need for it to be there.) If you can't associate the >>>> packet with the m-line, then you don't know which of the multiple >>>> interpretations to apply to the packet. >>>> >>>> Maybe there is some exception to this, though I haven't come up with >>>> anything. If there is, then I hope someone will call it out. If so, >>>> then the constraint can be tightened. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>>https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> > From randy@qti.qualcomm.com Sun Jul 7 15:43: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 BA30511E8147 for ; Sun, 7 Jul 2013 15:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RcRMIss5tM3v for ; Sun, 7 Jul 2013 15:43:30 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7092C11E8146 for ; Sun, 7 Jul 2013 15:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373237010; x=1404773010; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=1BnA3AmhO6wAeVJqWVKlB+o5hKYyQhGRcWeo6vrYR3I=; b=EPC70OLK4RshOmklIHUO1n378OYhj45EHRIt6rfr4ajGfkoI4MNK3VJP y+FV5YiIpasl9Aviu+6nR++W/k6cRc9h9mHKykt+Lfm4Tmg//HqX+Y/Rl ulwi2sscQ671mkFCNRLK5or8PrFoecTK8+gdXX8/y1EXMnOmkG/k5LCvD o=; X-IronPort-AV: E=Sophos;i="4.87,1015,1363158000"; d="scan'208";a="47022306" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 07 Jul 2013 15:43:28 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2013 15:43:28 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 7 Jul 2013 15:43:28 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 7 Jul 2013 15:43:27 -0700 Message-ID: In-Reply-To: <514FE5A9.3060900@nteczone.com> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Sun, 7 Jul 2013 15:40:38 -0700 To: Christian Groves , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 22:43:34 -0000 At 4:50 PM +1100 3/25/13, Christian Groves wrote: > Hello, > > One thing that doesn't seem to be noted is an overlap with the work > of the CLUE WG. There has been some discussion in the CLUE working > group about adding attributes to captures to describe the language, > whether sub-titles are used, whether a stream comes from an > interpreter, etc. Where multiple streams are used I would expect > any work in this area should be aligned. > > Regards, Christian Hi Christian, Thanks for the info. Would it make sense to talk about this in Berlin? I agree that if there is overlap in the approaches we should align them. Also, I have an updated draft that was just uploaded. It is now named 'draft-gellens-mmusic-negotiating-human-language-00' (adding -mmusic and hence reverting back to -00). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If you can't annoy somebody there's little point in writing --Kingsley Amis From ari.keranen@ericsson.com Sun Jul 7 15:55: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 21D2B21F9F3A for ; Sun, 7 Jul 2013 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-1.412, 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 W70NzXRnsNd2 for ; Sun, 7 Jul 2013 15:55:34 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63421F99A6 for ; Sun, 7 Jul 2013 15:55:33 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-83-51d9f1e421c2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.6C.11907.4E1F9D15; Mon, 8 Jul 2013 00:55:32 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Mon, 8 Jul 2013 00:55: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 3C9B91102AF; Mon, 8 Jul 2013 01:55:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D9342556D2; Mon, 8 Jul 2013 01:55:28 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89853552AC; Mon, 8 Jul 2013 01:55:28 +0300 (EEST) Message-ID: <51D9F1EA.60001@ericsson.com> Date: Mon, 8 Jul 2013 01:55:38 +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/20130509 Thunderbird/17.0.6 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+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre6TjzcDDda3GFu8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2Ppjm0sBa1sFZ33vzI1MH5i6WLk5JAQMJG4 3beRCcIWk7hwbz1bFyMXh5DAUUaJtwv2MkM46xklLq9awArh7GWUmHx7A1i7kMA6Ronj1/Mh EisYJT7Ovc4GkuAV0JRYfqiDvYuRg4NFQEXi+QUvkDCbgL3EzQnX2UFsUYFkiQP97awQ5YIS J2c+AZspIiAjsXfTZmYQW1hAS2JT8zewOLOArcSFOdehbHmJ7W/nMEOcrSZx9dwmZoh7VCWu /nvFOIFRaBaSsbOQtM9C0r6AkXkVI0dxanFSbrqRwSZGYLge3PLbYgfj5b82hxilOViUxHm3 6J0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cB4/QTji5mebiqOUhI8Mc//7jpj2aM8eZZk lrl568SgOfr9Wlt+LNoedbTFwuiVJ+uK4pzWQreMrjsKLF7qho5dnz1z/O2rVucWrtsr+lpQ RsBf/MVf+RkM2jkMkvJTFRJWKptPuPHlhrfd7I7JmxcJPOpV8tgU/MPd0WpToeAJ5uSlrHOy kpVYijMSDbWYi4oTAUst3JYlAgAA Subject: [MMUSIC] Draft submission deadlines change X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 22:55:40 -0000 FYI, since many of you may have missed this: "Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July." http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11651.html However, as the announcement says: "But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas." So please, submit rather early than late. Thanks, Ari From thomas.stach@siemens-enterprise.com Mon Jul 8 02:25: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 ADA2621F8D6D for ; Mon, 8 Jul 2013 02:25:30 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=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 dlxj-2kQvl1p for ; Mon, 8 Jul 2013 02:25:24 -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 ACE4921F920B for ; Mon, 8 Jul 2013 02:25:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0A5F71EB85AF; Mon, 8 Jul 2013 11:24:59 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 11:24:56 +0200 From: "Stach, Thomas" To: Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCABH+3wA== Date: Mon, 8 Jul 2013 09:24:55 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> In-Reply-To: <51D6D456.7090900@jitsi.org> Accept-Language: de-AT, 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 WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 08 Jul 2013 09:25:38 -0000 A few thoughts/response inline > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Friday, 05 July, 2013 16:13 > To: Stach, Thomas > Cc: MMUSIC IETF WG > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >=20 > Hey Thomas >=20 > On 04.07.13, 15:15, Stach, Thomas wrote: > > Emil, > > inline > > > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Emil Ivov > >> Sent: Wednesday, 03 July, 2013 16:13 > >> To: MMUSIC IETF WG > >> Subject: [MMUSIC] Trickle ICE for SIP Questions > >> > >> Hey all, > >> > >> Christer, Enrico and I are preparing the next version of Trickle ICE > >> for > >> SIP. Now that discussions on BUNDLE and the plans seem to be winding > >> down, we wanted to run a few questions by the working group. > >> > >> Q1: Making reliable provisional responses and PRACK mandatory. > >> Obviously > >> this would be nice to avoid, so the question is: is there a > reasonable > >> mechanism to achieve this (and by reasonable, we mean something that > >> wouldn't be harder than implementing support for PRACK). > >> > >> There was some discussion about this back in April and there was a > >> suggestion for implementing a 5245-style hack where the answerer > >> basically resends the 180 until it knows that it has been received. > >> > >> 5245 uses connectivity checks for this (i.e. it stops 180 > >> retransmissions when the first connectivity check is received) but > we > >> don't have that option here since the 180 may contain either none or > >> only host candidates so there are strong chances that no binding > >> request > >> would be received on them. > >> > >> Thomas also suggested a second option which would be to also use > INFO > >> requests with trickled candidates as an indication that 180 was > >> received. This however wouldn't work with half trickle so we are > >> basically back to vanilla ICE for all (non-re) INVITEs. > >> > >> Another option would be to mandate an INFO request with > >> "end-of-candidates" in response to the 180, but that would be just > the > >> same as mandating PRACK support. > >> > >> Thomas also suggested that the answerer can start sending INFOs > right > >> after it sends its answer in the 180 and then it can just resend the > >> 180 > >> if the INFOs result in a 481 response. > >> > >> Personally I think this could potentially be made to work, but it > would > >> imply a level of complexity that considerably exceeds PRACK support. > > [TS] I'm not convinced about the different level of complexity. > > If you use PRACK you have SIP timer T1 running and would re-transmit > the 180 in case that the PRACK is not received. >=20 > Right. >=20 > > Assuming that you want to wait with sending of the INFO until you saw > the PRACK, would lead to delay in that case. >=20 > True. Is this the only problem that we are trying to optimize? Save > half > an RTT? (This is a really a question. I am not trying to make a point. > I > am simply trying to understand why PRACK is an issue.) [TS] Saving the half RTT is not my primary goal. When implementing ICE we g= ot away without requiring PRACK.=20 I want to keep this property, since it allows=20 >=20 > > If you don't wait you would also have to treat a 481 response to the > INFO. >=20 > I am always a bit nervous when it comes to interpreting error > responses. [TS] We are actually specifying new behavior here.=20 Thus, we can specify the rule for the new info package and its application = for trickle-ICE in way as exact as possible such that there would be no nee= d for interpretation or nervousness. > We are indeed likely to get a 481 when sending INFOs and the 180 hasn't > yet made it to the remote side. However 481 might also imply that our > dialog is simply dead for some reason and in this case 3261 says: >=20 >=20 > If the response for a request within a dialog is a 481 > (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the > UAC > SHOULD terminate the dialog. [TS] We are in the dialog establishing phase here and when the 180 was lost= we don't even have an early dialog. So this rule does not apply. The 481 to the INFO would rather be the indica= tor for this situation. As stated above we can prescribe that the 481 (and = only the 481) is to be sent for the INFO and what happens next, i.e. retran= smit the 180. >=20 > > ... and you would detect quicker that the 180 was lost than by > waiting for the PRACK. >=20 > As said above: a lost 180 is not the only possible cause for a 408 in > this case. [TS] I assume you mean 481. >=20 > > BTW: 5245 recommends to use PRACK. However it does not mandate it, > but gives the alternative procedures as an option. > > You could do the same here. >=20 > Of course. I should have made that clearer: all alternative approaches > were meant as something we could have in addition to the PRACK one. >=20 > Also, keep in mind that the 180 carries an entire SDP answer. If INFOs > are competing with 180s then they may potentially need to carry that > too > (or at least the ICE parts) and it would be good if we don't have to > open that can of worms. [TS] For the trickle-ICE application of the info-package I would just recom= mend sending (all) the ICE candidates. This eliminates the competition, you just take what you got last. >=20 > >> Opinions? > >> > >> Q2: How do we send INFOs? Are they blocking or do we just send them > in > >> parallel? If the latter, then what happens when an INFO fails > because > >> it > >> is received out of order? Do we just tell the application to resend > the > >> candidates asap? > > [TS] I would go with the proposal below and send cumulatively. You > also have the CSeq: header field to detect late arrivals. > > > >> > >> This also leads to the following question: > >> > >> Q3: What exactly do we send in INFOs? Just the latest batch of > freshly > >> learned candidates or all candidates we've learned so far? Dale > >> suggested that if we do this cumulatively we wouldn't need to worry > >> about the case with the out-of-order INFOs from Q2 since the > >> information > >> gets resent anyway. A drawback here would obviously be that this > adds > >> more complexity for trickle ICE users (WebRTC applications > >> specifically) > > [TS] Again I'm not convinced about the complexity. Both peer know > their candidates, what is the issue in putting all of them into the > INFO? >=20 > I am not sure how current WebRTC stacks handle provisioning of > repeating > candidates.=20 [TS] As Trickle-ICE is just being specified, we are in a position to specif= y this handling. >If they don't then it would be up to the receiving JS app, > to sort our which are the new candidates and which were already there. >=20 > The sending side would be similarly tricky for a JS app: it would need > to construct SDP so that the a=3Dcandidate attributes appear under the > right "a=3Dmid" line. [TS] As the ICE/STUN logic resides in the browser not in the JS app, this w= ould be a matter of the API definition to always provide all known candidat= es towards the JS APP for sending. On the receiving side the JS APP would a= lso just have to push all received candidates through the browser API. Regards Thomas >=20 > >> A third option would be to allow both and leave it to the > application. > > [TS] This now adds complexity. ;-) >=20 > Likely yes. >=20 > Emil >=20 > > I would just always send all candidates. >=20 >=20 >=20 >=20 > > Regards > > Thomas > >> > >> Comments are most welcome! > >> > >> Emil > >> > >> -- > >> https://jitsi.org > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > -- > https://jitsi.org From thomas.stach@siemens-enterprise.com Mon Jul 8 02:44: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 A2B8A11E81BA for ; Mon, 8 Jul 2013 02:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_19=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 JAcwH-3W9d4f for ; Mon, 8 Jul 2013 02:44: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 ADB0F11E819F for ; Mon, 8 Jul 2013 02:44:15 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 18AEF1EB85A4; Mon, 8 Jul 2013 11:44:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 11:44:14 +0200 From: "Stach, Thomas" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCAACstAIAEXPYA Date: Mon, 8 Jul 2013 09:44:14 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51D6F88E.5000209@alum.mit.edu> In-Reply-To: <51D6F88E.5000209@alum.mit.edu> Accept-Language: de-AT, 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] Trickle ICE for SIP 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, 08 Jul 2013 09:44:25 -0000 Paul,=20 inline > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, 05 July, 2013 18:47 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >=20 > On 7/5/13 10:12 AM, Emil Ivov wrote: > > Hey Thomas > > > > On 04.07.13, 15:15, Stach, Thomas wrote: > >> Emil, > >> inline > >> > >>> -----Original Message----- > >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>> Behalf Of Emil Ivov > >>> Sent: Wednesday, 03 July, 2013 16:13 > >>> To: MMUSIC IETF WG > >>> Subject: [MMUSIC] Trickle ICE for SIP Questions > >>> > >>> Hey all, > >>> > >>> Christer, Enrico and I are preparing the next version of Trickle > ICE > >>> for > >>> SIP. Now that discussions on BUNDLE and the plans seem to be > winding > >>> down, we wanted to run a few questions by the working group. > >>> > >>> Q1: Making reliable provisional responses and PRACK mandatory. >=20 > Yes. >=20 > >>> Obviously > >>> this would be nice to avoid, so the question is: is there a > reasonable > >>> mechanism to achieve this (and by reasonable, we mean something > that > >>> wouldn't be harder than implementing support for PRACK). > >>> > >>> There was some discussion about this back in April and there was a > >>> suggestion for implementing a 5245-style hack where the answerer > >>> basically resends the 180 until it knows that it has been received. > >>> > >>> 5245 uses connectivity checks for this (i.e. it stops 180 > >>> retransmissions when the first connectivity check is received) but > we > >>> don't have that option here since the 180 may contain either none > or > >>> only host candidates so there are strong chances that no binding > >>> request > >>> would be received on them. > >>> > >>> Thomas also suggested a second option which would be to also use > INFO > >>> requests with trickled candidates as an indication that 180 was > >>> received. This however wouldn't work with half trickle so we are > >>> basically back to vanilla ICE for all (non-re) INVITEs. > >>> > >>> Another option would be to mandate an INFO request with > >>> "end-of-candidates" in response to the 180, but that would be just > the > >>> same as mandating PRACK support. > >>> > >>> Thomas also suggested that the answerer can start sending INFOs > right > >>> after it sends its answer in the 180 and then it can just resend > the > >>> 180 > >>> if the INFOs result in a 481 response. > >>> > >>> Personally I think this could potentially be made to work, but it > would > >>> imply a level of complexity that considerably exceeds PRACK > support. > >> [TS] I'm not convinced about the different level of complexity. > >> If you use PRACK you have SIP timer T1 running and would re-transmit > >> the 180 in case that the PRACK is not received. > > > > Right. > > > >> Assuming that you want to wait with sending of the INFO until you > saw > >> the PRACK, would lead to delay in that case. > > > > True. Is this the only problem that we are trying to optimize? Save > half > > an RTT? (This is a really a question. I am not trying to make a > point. I > > am simply trying to understand why PRACK is an issue.) >=20 > Yes, why is it such an issue to require PRACK? [TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, t= hat did not implement PRACK > It is a good thing to implement for many reasons.=20 [TS] There are also good reasons against PRACK. e.g. the much more complica= ted state machine. So in conjunction > with > defining other new functionality, why not require it? [TS] We did not need to require PRACK for vanilla ICE, why require it now. = There is a proposal on the table that solves the problem without the comple= xity of PRACK.=20 As already said I don't object to recommending PRACK (as in 5245), I just d= on't want it mandatory.=20 >=20 > >> If you don't wait you would also have to treat a 481 response to the > >> INFO. > > > > I am always a bit nervous when it comes to interpreting error > responses. > > We are indeed likely to get a 481 when sending INFOs and the 180 > hasn't > > yet made it to the remote side. However 481 might also imply that our > > dialog is simply dead for some reason and in this case 3261 says: > > > > > > If the response for a request within a dialog is a 481 > > (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the > UAC > > SHOULD terminate the dialog. > > > >> ... and you would detect quicker that the 180 was lost than by > waiting > >> for the PRACK. >=20 > This just highlights how "delicate" things get if you start trying to > work around the lack of PRACK. It might be possible to get something > that seems to work, but its a house of cards. [TS] Please refer to my reply to Emil, the rule above does not apply here. >=20 > > As said above: a lost 180 is not the only possible cause for a 408 in > > this case. > > > >> BTW: 5245 recommends to use PRACK. However it does not mandate it, > but > >> gives the alternative procedures as an option. > >> You could do the same here. > > > > Of course. I should have made that clearer: all alternative > approaches > > were meant as something we could have in addition to the PRACK one. > > > > Also, keep in mind that the 180 carries an entire SDP answer. If > INFOs > > are competing with 180s then they may potentially need to carry that > too > > (or at least the ICE parts) and it would be good if we don't have to > > open that can of worms. >=20 > Yes. The trickle ICE INFOs are *relative* to what was set up in the > O/A. > In the absence of the answer the trickle ICE is problematic. >=20 > >>> Opinions? > >>> > >>> Q2: How do we send INFOs? Are they blocking or do we just send them > in > >>> parallel? If the latter, then what happens when an INFO fails > because > >>> it > >>> is received out of order? Do we just tell the application to resend > the > >>> candidates asap? >=20 > *If* you are going to send in a non-blocking way then they should be > cumulative. >=20 > If you treat them as blocking, then they don't have to be, but it might > still be better. >=20 > >> [TS] I would go with the proposal below and send cumulatively. You > >> also have the CSeq: header field to detect late arrivals. >=20 > Yes, you can detect the late arrival. But you have at that point > already > acted on the one that should have been preceded by it. [TS] What is the problem? The previous INFO had fewer candidates, you just = got all additional candidates. =20 I can't see a case were a candidate got removed in a subsequent INFO. >=20 > >>> This also leads to the following question: > >>> > >>> Q3: What exactly do we send in INFOs? Just the latest batch of > freshly > >>> learned candidates or all candidates we've learned so far? Dale > >>> suggested that if we do this cumulatively we wouldn't need to worry > >>> about the case with the out-of-order INFOs from Q2 since the > >>> information > >>> gets resent anyway. >=20 > Exactly. >=20 > >>> A drawback here would obviously be that this adds > >>> more complexity for trickle ICE users (WebRTC applications > >>> specifically) > >> [TS] Again I'm not convinced about the complexity. Both peer know > >> their candidates, what is the issue in putting all of them into the > INFO? > > > > I am not sure how current WebRTC stacks handle provisioning of > repeating > > candidates. If they don't then it would be up to the receiving JS > app, > > to sort our which are the new candidates and which were already > there. > > > > The sending side would be similarly tricky for a JS app: it would > need > > to construct SDP so that the a=3Dcandidate attributes appear under the > > right "a=3Dmid" line. >=20 > I don't know enough about ICE to comment specifically on this. >=20 > But ISTM that this is analogous to what a SIP device must do to manage > the target set of destinations for a request - it is required to keep > track and not add the same address to the target set more than once. >=20 > Thanks, > Paul >=20 > >>> A third option would be to allow both and leave it to the > application. > >> [TS] This now adds complexity. ;-) > > > > Likely yes. > > > > Emil > > > >> I would just always send all candidates. > > > > > > > > > >> Regards > >> Thomas > >>> > >>> Comments are most welcome! > >>> > >>> Emil > >>> > >>> -- > >>> https://jitsi.org > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >> > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gunnar.hellstrom@omnitor.se Mon Jul 8 03:09: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 1496611E81CD for ; Mon, 8 Jul 2013 03:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 PuN9oFq+qaQj for ; Mon, 8 Jul 2013 03:09:24 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 641E411E81B9 for ; Mon, 8 Jul 2013 03:09:23 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 8 Jul 2013 12:08:37 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id DEE583A10F for ; Mon, 8 Jul 2013 12:08:36 +0200 (CEST) Message-ID: <51DA8FA6.4060705@omnitor.se> Date: Mon, 08 Jul 2013 12:08:38 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> In-Reply-To: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090403080603080901080905" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 10:09:30 -0000 This is a multi-part message in MIME format. --------------090403080603080901080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Randall, It is good to see this shape up. One initial comment: The draft discourages in an infavourable way from specifying asymmetrical preferences. In 7.1, it says: "In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive. Both SHOULD have the same values in the same order, because otherwise it is harder to match desired resources." A typical example of a user who do not want to specify the same value in both directions is a hard-of-hearing user who prefers to speak English but might accept to type English text on the transmission side, but prefers to read English text and do not have sufficient hearing to at all handle hearing spoken English on the receiving side. In the audio media specification there would then be humintlang-send value English, and nothing in the humintlang-recv. While in the text media specification there would be humintlang-send value for English, that would need a very much lower preference than the audio send, and the humintlang-recv value for English. Note also the need for an absolute preference indication. Or relative between media. This user will be quite disappointed to be forced to handle the call in text both ways. With this background, the SHOULD in the cited section is not desirable. I suggest to delete that sentence. There is a similar problem with the last paragraph in 7.1 " When placing an emergency call, and in any other case where the language cannot be assumed from context, each media stream in an offer SHOULD specify both 'humintlang-send' and 'humintlang-recv' attributes (to avoid ambiguity), and both SHOULD be set to the same values in the same order." Since users may have capability for only one direction of a modality, it is not reasonable to require them to specify a value in the direction they do not have a capability in. So this paragraph should be deleted or modified. Thanks Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-07-08 00:39, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Negotiating Human Language Using SDP > Author(s) : Randall Gellens > Filename : draft-gellens-mmusic-negotiating-human-language-00.txt > Pages : 13 > Date : 2013-07-07 > > Abstract: > Users have various human (natural) language needs, abilities, and > preferences regarding spoken, written, and signed languages. When > establishing interactive communication "calls" there needs to be a > way to communicate and ideally match (i.e., negotiate) the caller's > language preferences with the capabilities of the called party. This > is especially important with emergency calls, where a call can be > routed to a Public Safety Answering Point (PSAP) or call taker > capable of communicating with the user, or a translator or relay > operator can be bridged into the call during setup, but this applies > to non-emergency calls as well (as an example, when calling a company > call center). > > This document describes the need and expected use, and describes a > solution using new SDP stream attributes plus an optional SIP "hint." > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gellens-mmusic-negotiating-human-language > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-gellens-mmusic-negotiating-human-language-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090403080603080901080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Randall,
It is good to see this shape up.

One initial comment:

The draft discourages in an infavourable way from specifying asymmetrical preferences.

In 7.1, it says:

"In an offer, the 'humintlang-send' values constitute a list in
   preference order (first is most preferred) of the languages the
   offerer wishes to send, and the 'humintlang-recv' values constitute a
   list in preference order of the languages the offerer wishes to
   receive.  Both SHOULD have the same values in the same order, because
   otherwise it is harder to match desired resources."

A typical example of a user who do not want to specify the same value in both directions is a hard-of-hearing user who prefers to speak English but might accept to type English text on the transmission side,  but prefers to read English text and do not have sufficient hearing to at all handle hearing spoken English on the receiving side.

In the audio media specification there would then be humintlang-send value English,  and nothing in the humintlang-recv.
While in the text media specification there would be humintlang-send value for English, that would need a very much lower preference than the audio send, and the humintlang-recv value for English.

Note also the need for an absolute preference indication. Or relative between media. This user will be quite disappointed to be forced to handle the call in text both ways.

With this background, the SHOULD in the cited section is not desirable. I suggest to delete that sentence.

There is a similar problem with the last paragraph in 7.1

"  When placing an emergency call, and in any other case where the
   language cannot be assumed from context, each media stream in an
   offer SHOULD specify both 'humintlang-send' and 'humintlang-recv'
   attributes (to avoid ambiguity), and both SHOULD be set to the same
   values in the same order."

Since users may have capability for only one direction of a modality, it is not reasonable to require them to
 specify a value in the direction they do not have a capability in.

So this paragraph should be deleted or modified.


Thanks

Gunnar










Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-08 00:39, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Negotiating Human Language Using SDP
	Author(s)       : Randall Gellens
	Filename        : draft-gellens-mmusic-negotiating-human-language-00.txt
	Pages           : 13
	Date            : 2013-07-07

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  When
   establishing interactive communication "calls" there needs to be a
   way to communicate and ideally match (i.e., negotiate) the caller's
   language preferences with the capabilities of the called party.  This
   is especially important with emergency calls, where a call can be
   routed to a Public Safety Answering Point (PSAP) or call taker
   capable of communicating with the user, or a translator or relay
   operator can be bridged into the call during setup, but this applies
   to non-emergency calls as well (as an example, when calling a company
   call center).

   This document describes the need and expected use, and describes a
   solution using new SDP stream attributes plus an optional SIP "hint."


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gellens-mmusic-negotiating-human-language

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-gellens-mmusic-negotiating-human-language-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--------------090403080603080901080905-- From gunnar.hellstrom@omnitor.se Mon Jul 8 05:08: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 3043F11E81B6 for ; Mon, 8 Jul 2013 05:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 ekSOS8oY404G for ; Mon, 8 Jul 2013 05:08:41 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 6B34021F826B for ; Mon, 8 Jul 2013 05:08:39 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 8 Jul 2013 14:08:31 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 8A2073A11A for ; Mon, 8 Jul 2013 14:08:31 +0200 (CEST) Message-ID: <51DAABC0.5030205@omnitor.se> Date: Mon, 08 Jul 2013 14:08:32 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> <51DA8FA6.4060705@omnitor.se> In-Reply-To: <51DA8FA6.4060705@omnitor.se> Content-Type: multipart/alternative; boundary="------------050103020308090703000309" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - two modalities in video X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:08:48 -0000 This is a multi-part message in MIME format. --------------050103020308090703000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit There is a good description of avoidance of using subtags in 7.1, third paragraph from the end. It may be good to inform after that paragraph about the language tags that can be used for video. There are separate language tags for sign languages. So, for the video medium, that can be used to distinguish between two different usages of video; for sign language versus for assisting hearing with the view of the speaking human for lip-reading or for just emphasizing the understanding by a view of the speaker. Insert a new paragraph to be the third from the end of 7.1: For indication of preferences and capabilities of sign languages, the specific sign language tags of RFC 5646 SHALL be used in the video media specifications. Preference and capability of a spoken language tag (i.e. not a sign language) indicated in the video media specification SHOULD be used for indicating a view of the speaking human that may be needed or preferred for speech-reading assisted hearing. Regards Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 > --------------050103020308090703000309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There is a good description of avoidance of using subtags in 7.1, third paragraph from the end.

It may be good to inform after that paragraph about the language tags that can be used for video.
There are separate language tags for sign languages.
So, for the video medium, that can be used to distinguish between two different usages of video; for sign language versus for assisting hearing with the view of the speaking human for lip-reading or for just emphasizing the understanding by a view of the speaker.

Insert a new paragraph to be the third from the end of 7.1:

For indication of preferences and capabilities of sign languages, the specific sign language tags of RFC 5646 SHALL be used in the video media specifications.
Preference and capability of a spoken language tag (i.e. not a sign language) indicated in the video media specification SHOULD be used for indicating a view of the speaking human that may be needed or preferred for speech-reading assisted hearing.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288



--------------050103020308090703000309-- From pkyzivat@alum.mit.edu Mon Jul 8 08:53: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 92B4321F9D5D for ; Mon, 8 Jul 2013 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.422, 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 OhL3LcByrW7h for ; Mon, 8 Jul 2013 08:53:38 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 0116621F9D57 for ; Mon, 8 Jul 2013 08:53:18 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id xpDp1l0050QuhwU57rtHug; Mon, 08 Jul 2013 15:53:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id xrtH1l00m3ZTu2S3NrtH2h; Mon, 08 Jul 2013 15:53:17 +0000 Message-ID: <51DAE06C.1030203@alum.mit.edu> Date: Mon, 08 Jul 2013 11:53:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> 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=1373298797; bh=6Q/zSoLsbn6ffEv3jNjZHzw6k1+Ia+MDHzj6zO9U29c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AoyX7MN3bKr/ynkz5llLvtFn9s0kNJdygJn6dL/BgyS+/7DDKMB77rmdMr4S+S+5i NGgb9di4kmyCKHw60foxPLVA9mGcEaeXDnJ/RldXp0vasTdV4qC+jLsXIajJP6hPLv FdKiLGj24YcPCNf/YtEtBId0Jy0iRJuPwbXa6NbmJ9FfMvgdAtW2TjDuswk04nvcrc PNDC8Uu0Iz0LuoU+fCQ7HgzI1ny7tlmBUOyFzzTiWNvZxVpjkNLJMevOvX/K6l9jCe zcYPRf+rUmVL8TDyw2xgZRJoQ16YxJzkBYnmILsaC5bFYhmZ6RSu5v6HsHVcQJNxxM KbRgVn55w3b3Q== Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 08 Jul 2013 15:53:45 -0000 Thomas, On 7/8/13 5:24 AM, Stach, Thomas wrote: > [TS] Saving the half RTT is not my primary goal. When implementing ICE we got away without requiring PRACK. > I want to keep this property, since it allows I get it that you think PRACK is hard to implement. But hard compared to *what*? I suspect that this will introduce complexity elsewhere. >> If the response for a request within a dialog is a 481 >> (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the >> UAC >> SHOULD terminate the dialog. > [TS] We are in the dialog establishing phase here and when the 180 was lost we don't even have an early dialog. > So this rule does not apply. The 481 to the INFO would rather be the indicator for this situation. As stated above we can prescribe that the 481 (and only the 481) is to be sent for the INFO and what happens next, i.e. retransmit the 180. This is part of the house of cards that I was talking about. You seem to be saying that a special rule should be be adopted, allowing INFO to be sent from INVITE-UAS before it is known that the dialog has been established. And then a special rule for processing 481 responses to INFO in this context. >> Also, keep in mind that the 180 carries an entire SDP answer. If INFOs >> are competing with 180s then they may potentially need to carry that >> too >> (or at least the ICE parts) and it would be good if we don't have to >> open that can of worms. > [TS] For the trickle-ICE application of the info-package I would just recommend sending (all) the ICE candidates. > This eliminates the competition, you just take what you got last. Certainly it will be simpler if all candidates are sent each time. But I don't think that means you can just take what you got last. You still need to check if what you got is *older* than what you already have, and if so ignore it. Thanks, Paul From pkyzivat@alum.mit.edu Mon Jul 8 09:05: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 B644621F9B4B for ; Mon, 8 Jul 2013 09:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AWL=0.406, 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 toVaxHymnJtp for ; Mon, 8 Jul 2013 09:05:43 -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 AD5C421F87BB for ; Mon, 8 Jul 2013 09:05:17 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id xoTt1l0031wpRvQ5Cs5GXH; Mon, 08 Jul 2013 16:05:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id xs5G1l0133ZTu2S3es5G7N; Mon, 08 Jul 2013 16:05:16 +0000 Message-ID: <51DAE33B.3070507@alum.mit.edu> Date: Mon, 08 Jul 2013 12:05:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stach, Thomas" References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51D6F88E.5000209@alum.mit.edu> 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=1373299517; bh=txirXh2g9p1W/umAUM+pS4lQ84K/feFkP/P5gOTQOmQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hEF0zI8yJEeOzzYDo+Sx0wTz3CHC3WAOU9BZeQ1D2fSkW0EUmJWL8/Y3IfVLHhzyn cT8WmZ97I4couyWYcsnRs8ivHgkPAKTQoZMT/kif8V+Mqae/G7JoMIKqEOxEZ5Sh5S phrZRXmCnJsvervBfAvny51gSbo94PjOJDivOncOPu4wougilsL6ZTuvoh1NcNeay4 6WWH8mazmhsm5Fusqv636OxKpt4ZKvPf8LGo5RTsJs/rpnK2x9WEueR9DDsuSDyBLa aG0G0pWNE0VlU41S4l7yKZSAo8uXP9QORNwpt2m/Ws7jhD9C7ED/WlTlm+UlIc9j8J wCXn5PQk65Ekg== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 08 Jul 2013 16:05:48 -0000 Just responding to things that haven't already been covered. On 7/8/13 5:44 AM, Stach, Thomas wrote: >> Yes, why is it such an issue to require PRACK? > [TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, that did not implement PRACK I don't get it. If you are talking about SBCs that terminate/relay media, then the leg doing trickle-ICE is separate from the leg doing vanilla-ICE. So what is the issue? And if you have a signaling-only SBC, and one leg supports trickle-ICE while the other side supports only vanilla-ICE, then just use vanilla-ICE e2e. You won't gain anything by an intermediary trying to map trickle-ICE to vanilla-ICE. >> It is a good thing to implement for many reasons. > [TS] There are also good reasons against PRACK. e.g. the much more complicated state machine. Yes, but once you have done it then it is there to use for all sorts of things. The alternative seems to be to instead introduce a lot of new complexity that is *only* applicable to trickle-ICE. Thanks, Paul From ietf-secretariat-reply@ietf.org Mon Jul 8 12:49: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 0318721F9C70 for ; Mon, 8 Jul 2013 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, 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 SnZPcX3lU7pU for ; Mon, 8 Jul 2013 12:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8739021F9D65 for ; Mon, 8 Jul 2013 12:49:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708194907.30303.69979.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 12:49:07 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 08 Jul 2013 14:21:59 -0700 Subject: [MMUSIC] Milestones changed for mmusic 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: Mon, 08 Jul 2013 19:49:08 -0000 Changed milestone "Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard", set due date to December 2012 from December 2012. Changed milestone "Submit SDP extensions for audio media streams over Circuit- Switched bearers as Proposed Standard", set due date to December 2012 from December 2012. Changed milestone "Submit revised RTSP spec for Proposed Standard", set due date to December 2012 from December 2012. Changed milestone "Submit SDP extensions to classify traffic as Proposed Standard", set due date to February 2013 from February 2013. Changed milestone "Submit SDP extensions for duplicated streams as Proposed Standard", set due date to February 2013 from February 2013. Changed milestone "Submit SDP considerations for G.723 Annex A and G.729 Annex B as Proposed Standard", set due date to February 2013 from February 2013. Changed milestone "Submit Considerations for using SDP offer/answer with middleboxes for Informational", set due date to March 2013 from March 2013. Changed milestone "Submit revised SDP specification to IETF as Proposed Standard", set due date to March 2013 from March 2013. Changed milestone "Submit SDP extension for cross session stream identification as Proposed Standard", set due date to March 2013 from March 2013. Changed milestone "Submit SCTP-Based Media Transport in SDP as Proposed Standard.", set due date to April 2013 from April 2013. Changed milestone "Submit a document describing current practices in hosted NAT traversal as Informational", set due date to April 2013 from April 2013. Changed milestone "Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard", set due date to June 2013 from June 2013. Changed milestone "Submit RTSP NAT considerations draft as a Proposed Standard", set due date to July 2013 from January 2013. Changed milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard", set due date to July 2013 from July 2013. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From ietf-secretariat-reply@ietf.org Mon Jul 8 12:54: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 824D621F9D83 for ; Mon, 8 Jul 2013 12:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, 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 ioNXr1c5NX8u for ; Mon, 8 Jul 2013 12:54:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77CC21F9DA0 for ; Mon, 8 Jul 2013 12:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708195454.8074.84007.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 12:54:54 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 08 Jul 2013 14:22:01 -0700 Subject: [MMUSIC] Milestones changed for mmusic 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: Mon, 08 Jul 2013 19:54:55 -0000 Changed milestone "Submit SDP extensions for duplicated streams as Proposed Standard", set due date to July 2013 from February 2013. Changed milestone "Submit SDP considerations for G.723 Annex A and G.729 Annex B as Proposed Standard", set due date to July 2013 from February 2013. Changed milestone "Submit a document describing current practices in hosted NAT traversal as Informational", set due date to July 2013 from April 2013. Changed milestone "Submit SDP extensions to classify traffic as Proposed Standard", set due date to September 2013 from February 2013. Changed milestone "Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard", set due date to September 2013 from June 2013. Changed milestone "Submit Considerations for using SDP offer/answer with middleboxes for Informational", set due date to October 2013 from March 2013. Changed milestone "Submit revised SDP specification to IETF as Proposed Standard", set due date to November 2013 from March 2013. Changed milestone "Submit SCTP-Based Media Transport in SDP as Proposed Standard.", set due date to November 2013 from April 2013. Changed milestone "Submit SDP extension for cross session stream identification as Proposed Standard", set due date to December 2013 from March 2013. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From ietf-secretariat-reply@ietf.org Mon Jul 8 12:58: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 0C98C21F9DCE for ; Mon, 8 Jul 2013 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, 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 Fg5Ow966lpID for ; Mon, 8 Jul 2013 12:58:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 222DF21F9DB6 for ; Mon, 8 Jul 2013 12:57:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708195741.8085.11157.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 12:57:41 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 08 Jul 2013 14:22:02 -0700 Subject: [MMUSIC] Milestones changed for mmusic 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: Mon, 08 Jul 2013 19:58:02 -0000 Deleted milestone "Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard". Deleted milestone "Submit SDP extensions for audio media streams over Circuit- Switched bearers as Proposed Standard". Deleted milestone "Submit revised RTSP spec for Proposed Standard". Deleted milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard". Added milestone "Submit Trickle ICE as Proposed Standard", due December 2013. Added milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard", due January 2014. Added milestone "Submit SIP usage for Trickle ICE as Proposed Standard", due March 2014. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From gunnar.hellstrom@omnitor.se Mon Jul 8 22:51: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 478DF21F9F2E for ; Mon, 8 Jul 2013 22:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 dH+Z2f5rJB8R for ; Mon, 8 Jul 2013 22:50:55 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 420FA21F9F2B for ; Mon, 8 Jul 2013 22:50:53 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Tue, 9 Jul 2013 07:50:14 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 802593A11C; Tue, 9 Jul 2013 07:50:14 +0200 (CEST) Message-ID: <51DBA497.6050400@omnitor.se> Date: Tue, 09 Jul 2013 07:50:15 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> <51DA8FA6.4060705@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070008070308010608020104" Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:51:01 -0000 This is a multi-part message in MIME format. --------------070008070308010608020104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2013-07-09 03:51, Randall Gellens wrote: > Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua > Hi Gunnar, > > Thanks for the quick review and comments. > > > At 12:08 PM +0200 7/8/13, Gunnar Hellstrom wrote: > >> In 7.1, it says: >> "In an offer, the 'humintlang-send' values constitute a list in >> preference order (first is most preferred) of the languages the >> offerer wishes to send, and the 'humintlang-recv' values constitute a >> list in preference order of the languages the offerer wishes to >> receive. Both SHOULD have the same values in the same order, because >> otherwise it is harder to match desired resources." >> >> A typical example of a user who do not want to specify the same value >> in both directions is a hard-of-hearing user who prefers to speak >> English but might accept to type English text on the transmission >> side, but prefers to read English text and do not have sufficient >> hearing to at all handle hearing spoken English on the receiving side. > > This is very similar to the use case included of a user who can hear > English but not speak; an audio and text stream are set up, both using > English. The point of negotiating language is to get the call to a > callee who can communicate with the caller (e.g., a PSAP and call > taker who understand at least one language in common with the > caller). The point is not to fully specify exactly how the media will > be used; there is no need to do so and it won't help get the call to > the right callee, but will make things much more complex. > > It is simpler and more robust to handle cases such as you describe and > the one in the document now by negotiating the needed media as two-way > streams. Yes, two-way streams should usually be setup, on the media level. A media direction without a declared preference is usually valuable anyway. But that is not what the language specification aims at. The goal is to match caller, callee and possibly required assisting services to fill gaps between in preferences and capabilites between caller and callee. I said that the proper declaration for this example would be: In the audio media specification there would be humintlang-send value English, and nothing in the humintlang-recv. While in the text media specification there would be humintlang-send value for English, (that would need a very much lower preference than the audio send), and the humintlang-recv value for English. > > You say that the declaration should instead be symmetrical: In the audio media specification there would be humintlang-send value English, and English in the humintlang-recv. This is falsely declaring a preference, and cannot contribute to more successful matching. If this person calls another person with the same characteristics, and the same declaration, a comparison of their preferences would result in connecting them together without assisting service, because the language specifications indicate that they happily both talk and hear. Resulting in that they are left there without an opportunity to talk to each other. Instead keeping the declaration to the truth and not have a value for audio humintlang-recv, makes it possible to evaluate the need, and provide a two-way captioned telephony service for the call. Another point for truthful declaration is that the parties can get indications on how to behave in the call. If a call-center get a call from the deaf person in the example above with spoken English declaration both ways, and English text specification both ways, it is natural for the call center to try speaking a welcome phrase. There is no indication that typing will be needed. The calling person has no hearing capability and need therefore to explain with voice "I am deaf, please type". The call starts with a disappointing confusion instead of a nice welcome in the appropriate language and modality that would be achievable if the declaration shows the real preferences and capabilities. So, therefore I suggest to delete the sentences requiring symmetric humintlang declarations. Thanks Gunnar Hellström > > -- > Randall Gellens --------------070008070308010608020104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2013-07-09 03:51, Randall Gellens wrote:
Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
Hi Gunnar,

Thanks for the quick review and comments.


At 12:08 PM +0200 7/8/13, Gunnar Hellstrom wrote:

In 7.1, it says:
"In an offer, the 'humintlang-send' values constitute a list in
   preference order (first is most preferred) of the languages the
   offerer wishes to send, and the 'humintlang-recv' values constitute a
   list in preference order of the languages the offerer wishes to
   receive.  Both SHOULD have the same values in the same order, because
   otherwise it is harder to match desired resources."

A typical example of a user who do not want to specify the same value in both directions is a hard-of-hearing user who prefers to speak English but might accept to type English text on the transmission side,  but prefers to read English text and do not have sufficient hearing to at all handle hearing spoken English on the receiving side.

This is very similar to the use case included of a user who can hear English but not speak; an audio and text stream are set up, both using English.  The point of negotiating language is to get the call to a callee who can communicate with the caller (e.g., a PSAP and call taker who understand at least one language in common with the caller).  The point is not to fully specify exactly how the media will be used; there is no need to do so and it won't help get the call to the right callee, but will make things much more complex.

It is simpler and more robust to handle cases such as you describe and the one in the document now by negotiating the needed media as two-way streams.
Yes, two-way streams should usually be setup, on the media level. A media direction without a declared preference is usually valuable anyway. But that is not what the language specification aims at. The goal is to match caller, callee and possibly required assisting services to fill gaps between in preferences and capabilites between caller and callee.

I said that the proper declaration for this example would be:
In the audio media specification there would be humintlang-send value English,  and nothing in the humintlang-recv.
While in the text media specification there would be humintlang-send value for English, (that would need a very much lower preference than the audio send), and the humintlang-recv value for English.


You say that the declaration should instead be symmetrical:
In the audio media specification there would be humintlang-send value English,  and English in the humintlang-recv.

This is falsely declaring a preference, and cannot contribute to more successful matching.

If this person calls another person with the same characteristics, and the same declaration, a comparison of their preferences would result in connecting them together without assisting service, because the language specifications indicate that they happily both talk and hear.
Resulting in that they are left there without an opportunity to talk to each other.

Instead keeping the declaration to the truth and not have a value for audio humintlang-recv, makes it possible to evaluate the need, and provide a two-way captioned telephony service for the call.

Another point for truthful declaration is that the parties can get indications on how to behave in the call. If a call-center get a call from the deaf person in the example above with spoken English declaration both ways, and English text specification both ways, it is natural for the call center to try speaking a welcome phrase. There is no indication that typing will be needed. The calling person has no hearing capability and need therefore to explain with voice  "I am deaf, please type". The call starts with a disappointing confusion instead of a nice welcome in the appropriate language and modality that would be achievable if the declaration shows the real preferences and capabilities.

So, therefore I suggest to delete the sentences requiring symmetric humintlang declarations.

Thanks
Gunnar Hellström

 

--
Randall Gellens

--------------070008070308010608020104-- From bernard_aboba@hotmail.com Mon Jul 8 23:56: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 52D0621F9EA8 for ; Mon, 8 Jul 2013 23:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.139, 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 OAJod+xPDp8e for ; Mon, 8 Jul 2013 23:56:35 -0700 (PDT) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id C78C321F9EA1 for ; Mon, 8 Jul 2013 23:56:35 -0700 (PDT) Received: from BLU169-W139 ([65.55.116.73]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Jul 2013 23:56:35 -0700 X-TMN: [IvHVBu/8knPKifJ9A/07/iy1cX60J/hR] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a29b1acf-3497-4503-b87f-927eca5f359b_" From: Bernard Aboba To: Gunnar Hellstrom Date: Mon, 8 Jul 2013 23:56:34 -0700 Importance: Normal In-Reply-To: <51DBA497.6050400@omnitor.se> References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com>, <51DA8FA6.4060705@omnitor.se>, , <51DBA497.6050400@omnitor.se> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2013 06:56:35.0792 (UTC) FILETIME=[73E5ED00:01CE7C71] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 06:56:45 -0000 --_a29b1acf-3497-4503-b87f-927eca5f359b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =0A= This is very similar to the use case included of a user who=0A= can=0A= hear English but not speak=3B an audio and text stream are set up= =2C=0A= both=0A= using English. The point of negotiating language is to get the=0A= call to a callee who can communicate with the caller (e.g.=2C a=0A= PSAP and=0A= call taker who understand at least one language in common with=0A= the=0A= caller). The point is not to fully specify exactly how the=0A= media=0A= will be used=3B there is no need to do so and it won't help get=0A= the call=0A= to the right callee=2C but will make things much more complex. =0A= =0A= It is simpler and more robust to handle cases such as you=0A= describe and the one in the document now by negotiating the=0A= needed=0A= media as two-way streams.=0A= =0A= [BA] I think this example points out the limitations of a call routing= approach that relies solely on language. In this case=2C it is important f= or the "hint" to cause the call to be routed to an endpoint that can handle= text media=2C since otherwise the caller will not be able to communicate. = Since both the audio and text media are set up using English in both direc= tions=2C one might conclude that the "hint" need only express the language = preference (English)=2C but that would not be sufficient to get a satisfact= ory result. What needs to be expressed in the "hint" is *both* a preferenc= e for English and a requirement for text media support. =0A= = --_a29b1acf-3497-4503-b87f-927eca5f359b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3B
=0A=
This is very similar to the use case included of a user who=0A= can=0A= hear English but not speak=3B an audio and text stream are set up= =2C=0A= both=0A= using English. =3B The point of negotiating language is to get = the=0A= call to a callee who can communicate with the caller (e.g.=2C a=0A= PSAP and=0A= call taker who understand at least one language in common with=0A= the=0A= caller). =3B The point is not to fully specify exactly how the= =0A= media=0A= will be used=3B there is no need to do so and it won't help get=0A= the call=0A= to the right callee=2C but will make things much more complex.
= =0A=  =3B =3B =3B =3B =3B
=0A=
It is simpler and more robust to handle cases such as you=0A= describe and the one in the document now by negotiating the=0A= needed=0A= media as two-way streams.
=0A=
=0A=
[BA] =3B I think this example points out the limitations= of a call routing approach that relies solely on language. In this case=2C= it is important for the "hint" to cause the call to be routed to an endpoi= nt that can handle text media=2C since otherwise the caller will not be abl= e to communicate. =3B Since both the audio and text media are set up us= ing English in both directions=2C =3Bone might conclude that the = =3B"hint" =3Bneed only express the language preference (English)=2C but= that would not be sufficient to get a satisfactory result. =3B What ne= eds to be expressed in the "hint" is *both* a preference for English and a = requirement for text media support.
 =3B
=0A=
= --_a29b1acf-3497-4503-b87f-927eca5f359b_-- From Christian.Groves@nteczone.com Tue Jul 9 00:13: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 EA02D21F9F6F; Tue, 9 Jul 2013 00:13:29 -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 d2QFhiFZLtxR; Tue, 9 Jul 2013 00:13:29 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id E7BE821F9F34; Tue, 9 Jul 2013 00:13:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHe321F20QPz/2dsb2JhbAANTcITgneBM4MXAQEBBDgbFRABEAsOCgkWDwkDAgECAUUGDQEHAQGuXpI+j2sHg3ADrD4 Received: from ppp118-209-3-243.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.3.243]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Jul 2013 16:43:27 +0930 Message-ID: <51DBB813.4060607@nteczone.com> Date: Tue, 09 Jul 2013 17:13:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" , mmusic@ietf.org Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 07:13:30 -0000 Hello Randall, I had a look at the draft with respect to CLUE. The main difference between the CLUE usage of language and what is being proposed is the ability for the sender to specify sending AND receiving preferences. The current CLUE model is that an each endpoint Advertises what it can do and then each consumer chooses from this list. This could still result in an asymmetric usage of language (just negotiated differently). You may need to consider the case where there are multiple streams of the same media type with different languages. e.g. an audio conference where one stream is the main audio of the conference and there's a second stream with a translation/s. This is the type of thing CLUE is considering. I'm not sure how this fits in with your work? Some other comments: With regards to the SIP "hint" it wasn't clear to me how this matches the languages in "humintlang-send" and "humintlang-recv". Is it planned that both will be supported in the header? The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller sets media and language) but in the final paragraph of the 7.3 it sounds like the "hint" is only for audio? 7.4 Silly states - How do the language sub-tags come into play here? For example: the endpoint might specify a language for an audio stream which may be valid. If the endpoint also specified a sub-tag with "script" I guess it makes it a silly state? Regards, Christian On 8/07/2013 8:40 AM, Randall Gellens wrote: > At 4:50 PM +1100 3/25/13, Christian Groves wrote: > >> Hello, >> >> One thing that doesn't seem to be noted is an overlap with the work >> of the CLUE WG. There has been some discussion in the CLUE working >> group about adding attributes to captures to describe the language, >> whether sub-titles are used, whether a stream comes from an >> interpreter, etc. Where multiple streams are used I would expect any >> work in this area should be aligned. >> >> Regards, Christian > > Hi Christian, > > Thanks for the info. Would it make sense to talk about this in > Berlin? I agree that if there is overlap in the approaches we should > align them. > > Also, I have an updated draft that was just uploaded. It is now named > 'draft-gellens-mmusic-negotiating-human-language-00' (adding -mmusic > and hence reverting back to -00). > From gunnar.hellstrom@omnitor.se Tue Jul 9 00:58: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 9F00E21F9DAB for ; Tue, 9 Jul 2013 00:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 U-9o-dpVi6Uh for ; Tue, 9 Jul 2013 00:58:34 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C570A21F9DA6 for ; Tue, 9 Jul 2013 00:58:27 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 9 Jul 2013 09:58:19 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id ADADE3A0DA for ; Tue, 9 Jul 2013 09:58:19 +0200 (CEST) Message-ID: <51DBC29C.9030200@omnitor.se> Date: Tue, 09 Jul 2013 09:58:20 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com>, <51DA8FA6.4060705@omnitor.se>, , <51DBA497.6050400@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060707010607050006050004" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - preferences between media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 07:58:39 -0000 This is a multi-part message in MIME format. --------------060707010607050006050004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2013-07-09 08:56, Bernard Aboba wrote: > > This is very similar to the use case included of a user who can > hear English but not speak; an audio and text stream are set up, > both using English. The point of negotiating language is to get > the call to a callee who can communicate with the caller (e.g., a > PSAP and call taker who understand at least one language in common > with the caller). The point is not to fully specify exactly how > the media will be used; there is no need to do so and it won't > help get the call to the right callee, but will make things much > more complex. > It is simpler and more robust to handle cases such as you describe > and the one in the document now by negotiating the needed media as > two-way streams. > > [BA] I think this example points out the limitations of a call > routing approach that relies solely on language. In this case, it is > important for the "hint" to cause the call to be routed to an endpoint > that can handle text media, since otherwise the caller will not be > able to communicate. Since both the audio and text media are set up > using English in both directions, one might conclude that > the "hint" need only express the language preference (English), but > that would not be sufficient to get a satisfactory result. What needs > to be expressed in the "hint" is *both* a preference for English and a > requirement for text media support. And the humintlang specification allows that if the requirement to have symmetric specifications per media is deleted ( as described in another mail ). But there is also a need for absolute preference. Or relative order of preference between media. It is easy to use a sign language example fort that situation. A person prefers to use British sign language in both directions but is capable with some reluctance to use English text. That is natural. Text is always slower and less expressive than sign language or spoken language. A call goes to a call center that declared spoken English and English text in both directions. The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English. An ability to declare that the British sign language is preferred over the English text would result in the invocation of the sign relay service and make both sides happy with a call with good flow. Without the relative preference between media, the call will likely result in the direct text communication that will work but with less satisfaction. This can be solved either by an absolute preference indication : British sing language *preferred* , English text *managed* Or by some order of preference between the media; video *preferred* text *managed* I think an absolute preference indication is easiest to handle. Media preference will collide with relative preference between languages in each medium. I suggest that that is introduced with some suitable coding. /Gunnar Hellström > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------060707010607050006050004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2013-07-09 08:56, Bernard Aboba wrote:
 
This is very similar to the use case included of a user who can hear English but not speak; an audio and text stream are set up, both using English.  The point of negotiating language is to get the call to a callee who can communicate with the caller (e.g., a PSAP and call taker who understand at least one language in common with the caller).  The point is not to fully specify exactly how the media will be used; there is no need to do so and it won't help get the call to the right callee, but will make things much more complex.
     
It is simpler and more robust to handle cases such as you describe and the one in the document now by negotiating the needed media as two-way streams.
[BA]  I think this example points out the limitations of a call routing approach that relies solely on language. In this case, it is important for the "hint" to cause the call to be routed to an endpoint that can handle text media, since otherwise the caller will not be able to communicate.  Since both the audio and text media are set up using English in both directions, one might conclude that the "hint" need only express the language preference (English), but that would not be sufficient to get a satisfactory result.  What needs to be expressed in the "hint" is *both* a preference for English and a requirement for text media support.
<GH>And the humintlang specification allows that if the requirement to have symmetric specifications per media is deleted ( as described in another mail ).

But there is also a need for absolute preference. Or relative order of preference between media.

It is easy to use a sign language example fort that situation.

A person prefers to use British sign language in both directions but is capable with some reluctance to use English text. That is natural. Text is always slower and less expressive than sign language or spoken language.

A call goes to a call center that declared spoken English and English text in both directions.
The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English.

An ability to declare that the British sign language is preferred over the English text would result in the invocation of the sign relay service and make both sides happy with a call with good flow.

Without the relative preference between media, the call will likely result in the direct text communication that will work but with less satisfaction.

This can be solved either by an absolute preference indication  : British sing language *preferred*  , English text *managed*  
Or by some order of preference between the media;  video *preferred* text *managed*

I think an absolute preference indication is easiest to handle. Media preference will collide with relative preference between languages in each medium.

I suggest that that is introduced with some suitable coding.

/Gunnar Hellström

 


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

--------------060707010607050006050004-- From rg+ietf@qualcomm.com Mon Jul 8 18:52: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 06B1011E80F5 for ; Mon, 8 Jul 2013 18:52:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 DxbwEEg96IUc for ; Mon, 8 Jul 2013 18:52:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D073221F9B16 for ; Mon, 8 Jul 2013 18:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1373334746; x=1404870746; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:content-type; bh=hH/15DmC3mWkjwsffCOdOzivGgfW3QjhR3BRh4OLohM=; b=Mfzc1F6YLvf5ova73cks6480oTLuNo7tmsfi/UsdIJw7V4wqIWabGiT+ q5avC1lG9INvYbeWSWDinxqCbqesDCkSBG3d7eK1/QyTqSaCrxtRChreX OmAAdy+0bwIkQx+KBWjcXm1ePVlAivrsirZDklZGDpT8qtbBXem42jscv I=; X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="61347552" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 08 Jul 2013 18:52:25 -0700 X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="70348982" Received: from warlock.qualcomm.com ([129.46.50.49]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2013 18:52:25 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r691qOQi016372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2013 18:52:24 -0700 X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="511306292" Received: from unknown (HELO [99.111.97.136]) ([10.64.207.198]) by Ironmsg03-R.qualcomm.com with ESMTP; 08 Jul 2013 18:52:22 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <51DA8FA6.4060705@omnitor.se> References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> <51DA8FA6.4060705@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Mon, 8 Jul 2013 18:51:25 -0700 To: Gunnar Hellstrom , "mmusic (E-mail)" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Mailman-Approved-At: Tue, 09 Jul 2013 04:56:26 -0700 Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 01:52:32 -0000 Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
Hi Gunnar,

Thanks for the quick review and comments.


At 12:08 PM +0200 7/8/13, Gunnar Hellstrom wrote:

In 7.1, it says:
"In an offer, the 'humintlang-send' values constitute a list in
   preference order (first is most preferred) of the languages the
   offerer wishes to send, and the 'humintlang-recv' values constitute a
   list in preference order of the languages the offerer wishes to
   receive.  Both SHOULD have the same values in the same order, because
   otherwise it is harder to match desired resources."

A typical example of a user who do not want to specify the same value in both directions is a hard-of-hearing user who prefers to speak English but might accept to type English text on the transmission side,  but prefers to read English text and do not have sufficient hearing to at all handle hearing spoken English on the receiving side.

This is very similar to the use case included of a user who can hear English but not speak; an audio and text stream are set up, both using English.  The point of negotiating language is to get the call to a callee who can communicate with the caller (e.g., a PSAP and call taker who understand at least one language in common with the caller).  The point is not to fully specify exactly how the media will be used; there is no need to do so and it won't help get the call to the right callee, but will make things much more complex.

It is simpler and more robust to handle cases such as you describe and the one in the document now by negotiating the needed media as two-way streams.



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
... Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental.  Any resemblance between the above and my own
views is non-deterministic.  The question of the existence of
views in the absence of anyone to hold them is left as an
exercise for the reader.  The question of the existence of the
reader is left as an exercise for the second god coefficient.
(A discussion of non-orthogonal, non-integral polytheism
is beyond the scope of this article.)
From rg+ietf@qualcomm.com Mon Jul 8 19:03: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 7FA7211E80FD for ; Mon, 8 Jul 2013 19:03:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 OadDAtZgSEU6 for ; Mon, 8 Jul 2013 19:03:31 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E0DD411E80F9 for ; Mon, 8 Jul 2013 19:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1373335411; x=1404871411; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:content-type:content-transfer-encoding; bh=iI0LG3fp0RQQu1elYHyiWfEDa0U1ixdVA/L3ZXpUyic=; b=J08vdq7OEmiPBTioWjc9LXjHt3dUWYS8rSBwoTpFcNNS2TxC+7iIUNTO tyeJ++ScQSTdm9PRdIiYHcOJk9d2yJYfM9FT0SZd2asU4DckJFx66WaUo W6x7bc0lcTmL+x+ogoXVt43kw07dtWLyJTjSHkUDoTRbcIE6sRJsy8fTZ g=; X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="61352025" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 08 Jul 2013 19:03:27 -0700 X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="72584363" Received: from warlock.qualcomm.com ([129.46.50.49]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2013 19:03:27 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r6923Qkt017560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2013 19:03:26 -0700 X-IronPort-AV: E=Sophos;i="4.87,1024,1363158000"; d="scan'208,217";a="564998647" Received: from unknown (HELO [99.111.97.136]) ([10.64.207.198]) by Ironmsg04-R.qualcomm.com with ESMTP; 08 Jul 2013 19:03:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <51DAABC0.5030205@omnitor.se> References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com> <51DA8FA6.4060705@omnitor.se> <51DAABC0.5030205@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Mon, 8 Jul 2013 19:03:22 -0700 To: Gunnar Hellstrom , "mmusic (E-mail)" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Mailman-Approved-At: Tue, 09 Jul 2013 04:56:27 -0700 Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - two modalities in video X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:03:36 -0000 Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
Hi Gunnar,

Thanks again for the quick review and comments.

I agree it can be helpful to include a clarifying note that a spoken language can be used with a video stream to indicate a request to see the speaker.  I'm not sure that normative language is needed here but I have added informative text to both 7.1 and 7.4 (on silly states).

At 2:08 PM +0200 7/8/13, Gunnar Hellstrom wrote:

There is a good description of avoidance of using subtags in 7.1, third paragraph from the end.

It may be good to inform after that paragraph about the language tags that can be used for video.
There are separate language tags for sign languages.
So, for the video medium, that can be used to distinguish between two different usages of video; for sign language versus for assisting hearing with the view of the speaking human for lip-reading or for just emphasizing the understanding by a view of the speaker.

Insert a new paragraph to be the third from the end of 7.1:

=46or indication of preferences and capabilities of sign languages, the specific sign language tags of RFC 5646 SHALL be used in the video media specifications.
Preference and capability of a spoken language tag (i.e. not a sign language) indicated in the video media specification SHOULD be used for indicating a view of the speaking human that may be needed or preferred for speech-reading assisted hearing.

Regards

Gunnar
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288




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



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Studied carefully, a modern payphone reveals itself as a little
fortress, carefully designed and redesigned over generations, to resist
coin, slugs, zaps of electricity, chunks of coin-shaped ice, prybars,
magnets, lockpicks, blasting caps. Public pay- phones must survive in a
world of unfriendly, greedy people, and a modern payphone is as
exquisitely evolved as a cactus.
     --Bruce Sterling
From emil@sip-communicator.org Tue Jul 9 05:44: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 2149711E80FB for ; Tue, 9 Jul 2013 05:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=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 LDKey8o62lZQ for ; Tue, 9 Jul 2013 05:44:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 951D911E80E1 for ; Tue, 9 Jul 2013 05:44:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4699956wgh.23 for ; Tue, 09 Jul 2013 05:44:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=3prPMSE9PMicv5C5SGQGHymujc6PvmBgkoFlZlYh0K8=; b=BCvHQtr0c7O2GDweQTKmLIDTIY+LqHIWhWeR1spLZhXcxsjN5c7oaW+pIzAnrOvmM4 VdcAGIh4cPm87GzAkTgpisY8TiPYuZr9M7nqj3kWHHeK31cbAqJpi/Yr4Ir7aFlyXb9p 9pDUDF2v+O3rO0stfPW/F/JZzXjhJGOuKtI1R3j1Glb5no6i55+VdP22gpnbYSM5JN8L eXr2O93AWM3YpdGF39H/CUlfQw5wjQg8zX8+MY/G8B6t5F/7t4/ZXHlbOOVjZV2rU+9H AJSKg02K4ajab3ekpMeei7C5MU1wV1q0CCq5Zm3YVn4NVZt71KfCUuRPnVh+6AMWdnZX 8eDw== X-Received: by 10.180.10.138 with SMTP id i10mr28640319wib.53.1373373843465; Tue, 09 Jul 2013 05:44:03 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:5cd6:e1f6:214:667b]) by mx.google.com with ESMTPSA id fs8sm60990325wib.0.2013.07.09.05.44.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 05:44:02 -0700 (PDT) Message-ID: <51DC0595.4070203@jitsi.org> Date: Tue, 09 Jul 2013 14:44:05 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: MMUSIC IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlkcEmLg0QcZxI+2iXFu9EekrEgGqeTDa8pddJr+gC9R5lKAAbNERBO8P+p1QiFslHeIMAJ Subject: [MMUSIC] Trickle ICE and frozen candidates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:44:09 -0000 Hey all, In Orlando we discussed a few issues around trickle ICE without reaching any form of consensus so it would be great if we could do so here. The most delicate is about handling frozen candidates with trickle ICE. I apologise for the long e-mail that's about to follow. It's just one of those gluey, hairy issues. The faster we get rid of it, the better, so please don't be intimidated by the text ;). With vanilla ICE, we have the advantage of knowing that candidate pairs will be ordered the same way on both sides. Checks are executed in the same order, which allows NATs to open all the necessary holes in their filters. The "frozen candidates" algorithm relies on this. It starts by unfreezing, on both sides, all the first pairs for all foundations. In other words, for an audio/video rtp/rtcp call, we normally start ICE processing with Audio.RTP and then unfreeze RTCP and Video when the first checks have succeeded (roughly put). The problem with trickle ICE is that such an order is no longer guaranteed. It is hence possible that both agents obtain their STUN candidates in different order. For example, one of them first obtains Audio.RTP, while the other one first learns a mapping for Video RTCP. Here's a more specific example: Imagine Alice and Bob both have a single host address each: A1 and B1 (both are NATed in different LANs). They both use ports 5000/5001 for Audio RTP/RTCP and ports 5002/5004 for Video RTP/RTCP. They also both use a STUN server (no TURN for simplicity). Now let's say that Alice gets (and trickles) a STUN candidate for her Audio.RTP base, while Bob first obtains one for RTCP. For clarity, their check lists would hence look something like this: Foundation: A1B1 A1B2 A2B1 Audio.RTP A1:5000/B1:5000 A2:5000/B1:5000 Audio.RTCP A1:5001/B1:5001 A1:5001/B2:5001 Video.RTP A1:5002/B1:5002 Video.RTCP A1:5003/B1:5003 We now arrive at the essence: If we are to use freezing in a way that's similar to 5245, then Alice and Bob would both unfreeze the first pair they have for a given foundation and keep everyone else frozen: Alice will thus be sending STUN checks to Bob for Audio.RTCP, while Bob tries to conn. check Alice's Audio.RTP candidate. While they do this, they will learn and trickle all the other candidates for these foundations but this wouldn't matter as they would have to remain frozen. Both of the above checks and their entire foundations will hence fail since they won't be symmetric. I hope the description makes sense. So we basically have two ways to go about this: 1. Try to come up with some rules that avoid or fix the above situation. We could try to formulate text that basically starts the unfreezing only once we have symmetric candidates for all foundations. 2. We could start by unfreezing the first available pair for any foundation and then also unfreeze new pairs with a higher priority. New pairs with a lower priority will remain frozen until at least one higher priority pair succeeds. 3. We could also get rid of freezing and just start checks for anything we get. STUN transactions give us quite some leash in terms of time so that even if one of the peers starts checks for a given component earlier than the other, this should not be reason enough for failure. (Although it could lead to delays in some cases). While 1 and especially 2 may be preferable in terms of efficiency, personally, I am worried that getting it right in terms of spec and implementation is non-trivial and this may become a common reason for interoperability problems. Therefore, 3 does seem like the simplest way to go. Opinions? Cheers, Emil -- https://jitsi.org From emil@sip-communicator.org Tue Jul 9 05:55: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 4E3F721F9C17 for ; Tue, 9 Jul 2013 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 RR3LjH9E5kF3 for ; Tue, 9 Jul 2013 05:55:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB37B21F8475 for ; Tue, 9 Jul 2013 05:55:36 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4758619wes.3 for ; Tue, 09 Jul 2013 05:55:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=9kfr3AeDUwaLn6fLPP0qGBHHTbrRPD17JlIvUspDDBY=; b=CC/9X0X1kkKtvNJcKW+JB70KWZUul7zclnhx2U6JVoyagQoGHRgUOzabyFnqjiXw2E MrpoNmAI+llxjwC8ryTxBmEE9uMTQREm6kRulasTtMgmwajBObmuI2ukPtt6naE+vVsf uw4MY54BEMV0gkdnRYHfgoz+TR8h5Oely6bCkodEmgQ1N6Fi6JoARWWMhz0CfNO6gK6L tQQPpaatGjxY4GhLI4gHh8PVoLFXPxk9ok2zbdKDD3a55ysv2ii5gq0SzWIeYbX56kpK x2f5OzepPpPKjY/yn/lhXTTl5V1voynUTr35x24QWLVJ1ikopy5ohpnz8nnyW0gncKV7 WhLg== X-Received: by 10.181.13.106 with SMTP id ex10mr14212245wid.16.1373374535545; Tue, 09 Jul 2013 05:55:35 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:5cd6:e1f6:214:667b]) by mx.google.com with ESMTPSA id j20sm29788611wie.7.2013.07.09.05.55.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 05:55:34 -0700 (PDT) Message-ID: <51DC0848.7060109@jitsi.org> Date: Tue, 09 Jul 2013 14:55:36 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: MMUSIC IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnuAwltBb3WM15PfO5ZFMsQ18xUlX3dqtsPFvcGQC38SFnnrJ/XwdnPx/uN2Z39Q8vJTx31 Subject: [MMUSIC] 2 simple Trickle ICE questions (bike shed warning) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:55:41 -0000 Hey all, In Orlando there were a couple of points with trickle ICE that triggered some discussion but that didn't lead to a specific decision. They are relatively simple and can hence be contentious, so hopefully, we could agree to focus on actual problems as opposed to "it just doesn't look that pretty" concerns. Here goes: Q1. Is it OK to keep using ::0 and port 9 in offers and answers that carry no other candidates. Q2. Is it OK to mandate use of "mid" when mapping candidates to an m= line (as opposed to an m= line index or a label). Emil -- https://jitsi.org From richard.ejzak@alcatel-lucent.com Tue Jul 9 12:32: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 2926721F9D01; Tue, 9 Jul 2013 12:32:46 -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 3-CQnYM62pcu; Tue, 9 Jul 2013 12:32:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F221F9D02; Tue, 9 Jul 2013 12:32:35 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r69JWVRv009433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Jul 2013 14:32:32 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r69JWVTA027735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 15:32:31 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 9 Jul 2013 15:32:28 -0400 From: "Ejzak, Richard P (Richard)" To: "dispatch@ietf.org" , "mmusic@ietf.org WG" Thread-Topic: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt Thread-Index: AQHOfDMs+G1XaZJM/UuxFbqIPUpRyplcuxag Date: Tue, 9 Jul 2013 19:32:28 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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.39 Subject: [MMUSIC] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:32:46 -0000 UGxlYXNlIG5vdGUgb3VyIHByb3Bvc2VkIGFsdGVybmF0aXZlIHRvIGRyYWZ0LXBkLW1zcnAtd2Vi cnRjLTAwIGZvciBob3cgdG8gdXNlIERhdGFDaGFubmVsIHRyYW5zcG9ydCBmb3IgTVNSUC4gIE91 ciBkcmFmdCBkb2VzIG5vdCBwbGFjZSByZXN0cmljdGlvbnMgb24gdGhlIG51bWJlciBvZiBNU1JQ IHNlc3Npb25zIHRoYXQgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGhpbiBhbiBTQ1RQIGFzc29jaWF0 aW9uIGFuZCBkZXNjcmliZXMgYWx0ZXJuYXRpdmVzIGZvciB1c2luZyBhIGdhdGV3YXkgdG8gaW50 ZXJjb25uZWN0IHRvIGV4aXN0aW5nIE1TUlAgZW5kcG9pbnRzLiAgVGhlIFNEUCBleHRlbnNpb25z IGRlc2NyaWJlZCBhcmUgYXBwbGljYWJsZSB0byBvdGhlciBwb3RlbnRpYWwgRGF0YUNoYW5uZWwg c3ViLXByb3RvY29scyBzdWNoIGFzIFQuMTQwLCBCRkNQLCBULjM4LCBldGMuDQoNClJpY2hhcmQN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1 bHkgMDgsIDIwMTMgNjozMSBQTQ0KVG86IEVqemFrLCBSaWNoYXJkIFAgKFJpY2hhcmQpOyBNQVJD T04sIEpFUk9NRSAoSkVST01FKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzLTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRh LWNoYW5uZWxzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKZXJv bWUgTWFyY29uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzDQpSZXZpc2lvbjoJ IDAwDQpUaXRsZToJCSBNU1JQIG92ZXIgV2ViUlRDIGRhdGEgY2hhbm5lbHMNCkNyZWF0aW9uIGRh dGU6CSAyMDEzLTA3LTA5DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogMTINClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWFyY29uLW1zcnAtb3Zlci13ZWJydGMtZGF0YS1jaGFubmVscy0wMC50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tYXJjb24tbXNycC1vdmVyLXdlYnJ0Yy1kYXRhLWNoYW5uZWxzDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcmNvbi1tc3JwLW92ZXItd2VicnRj LWRhdGEtY2hhbm5lbHMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBSZWFsLVRpbWUgQ29tbXVu aWNhdGlvbiBpbiBXRUItYnJvd3NlcnMgKFJUQ1dlYikgd29ya2luZyBncm91cCBpcw0KICAgY2hh cmdlZCB0byBwcm92aWRlIHByb3RvY29scyB0byBzdXBwb3J0IGRpcmVjdCBpbnRlcmFjdGl2ZSBy aWNoDQogICBjb21tdW5pY2F0aW9uIHVzaW5nIGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEgYmV0d2Vl biB0d28gcGVlcnMnIHdlYi0NCiAgIGJyb3dzZXJzLiAgRm9yIHRoZSBzdXBwb3J0IG9mIGRhdGEg Y29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYiB3b3JraW5nDQogICBncm91cCBoYXMgaW4gcGFydGlj dWxhciBkZWZpbmVkIHRoZSBjb25jZXB0IG9mIGJpLWRpcmVjdGlvbmFsIGRhdGENCiAgIGNoYW5u ZWxzIG92ZXIgU0NUUCwgd2hlcmUgZWFjaCBkYXRhIGNoYW5uZWwgbWlnaHQgYmUgdXNlZCB0bw0K ICAgdHJhbnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkIHN1Yi1wcm90b2NvbHMuICBUaGlz IGRvY3VtZW50DQogICBzcGVjaWZpZXMgaG93IHRoZSBNZXNzYWdlIFNlc3Npb24gUmVsYXkgUHJv dG9jb2wgKE1TUlApIGNhbiBiZQ0KICAgaW5zdGFudGlhdGVkIGFzIGEgV2ViUlRDIGRhdGEgY2hh bm5lbCBzdWItcHJvdG9jb2wsIHVzaW5nIHRoZSBTRFANCiAgIG9mZmVyL2V4Y2hhbmdlIHRvIG5l Z290aWF0ZSBvdXQtb2YtYmFuZCB0aGUgc3ViLXByb3RvY29sIHNwZWNpZmljDQogICBwYXJhbWV0 ZXJzLiAgVHdvIG5ldHdvcmsgY29uZmlndXJhdGlvbnMgYXJlIGRvY3VtZW50ZWQ6IGEgV2ViUlRD IGVuZC0NCiAgIHRvLWVuZCBjb25maWd1cmF0aW9uIChjb25uZWN0aW5nIHR3byBNU1JQIG92ZXIg ZGF0YSBjaGFubmVsDQogICBlbmRwb2ludHMpLCBhbmQgYSBnYXRld2F5IGNvbmZpZ3VyYXRpb24g KGNvbm5lY3RpbmcgYW4gTVNSUCBvdmVyIGRhdGENCiAgIGNoYW5uZWwgZW5kcG9pbnQgd2l0aCBh biBNU1JQIG92ZXIgVENQIGVuZHBvaW50KS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From martin.thomson@gmail.com Tue Jul 9 12:45: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 5101B11E813F for ; Tue, 9 Jul 2013 12:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 kJV+8Gkl27+t for ; Tue, 9 Jul 2013 12:45:46 -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 A771711E813A for ; Tue, 9 Jul 2013 12:45:45 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so5015976wes.5 for ; Tue, 09 Jul 2013 12:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KUYa+Ic75HA5qwwuzYwK/9i1WJshONWorot7rmgztPE=; b=s9zwybPIYRFRG0hZgUtUfPhOt7rSrdpa89Na984laMrYylO/6YYeZaawIiu5ep6mhy aeq/YqtfeICfUpnzmRgTL7tFVI6RAyt4bkGzaeCk+Z4ZRRmc6ePsjmwr7jTVFMrqymFp L2p2bIsjhgqcqjmgD8aRqwZC/j6EjWRlNeisbo86UerhnWNNUsC/JNi4jJpLaMbgmbo3 FqChwGW3Y1WVEBkK+Y43vxksj6VNurrKUxreIEM6CIyAMBP6mJgx5/GQ9aUuHyMxKU5n hN6OVOGVlC6ELggV/DOfujrOGCk4eIwFJhNuAvjvcCzpTBo2Mw0il6iJa47AjJF22RXt ZBeQ== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr32871647wik.14.1373399144849; Tue, 09 Jul 2013 12:45:44 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 9 Jul 2013 12:45:44 -0700 (PDT) In-Reply-To: <51DC0595.4070203@jitsi.org> References: <51DC0595.4070203@jitsi.org> Date: Tue, 9 Jul 2013 12:45:44 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE and frozen candidates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 19:45:46 -0000 On 9 July 2013 05:44, Emil Ivov wrote: > While 1 and especially 2 may be preferable in terms of efficiency, > personally, I am worried that getting it right in terms of spec and > implementation is non-trivial and this may become a common reason for > interoperability problems. Therefore, 3 does seem like the simplest way to > go. You are going to want to ensure that both peers check in the same order. 3 seems a little too loose for me. I think that some sort of mechanism is going to be needed to avoid problems with races, since both peers will have different sets of candidate pairs at every point in the process. And signaling is slow enough for this to be a real problem. From ari.keranen@ericsson.com Tue Jul 9 13:52: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 C62E121F9C88 for ; Tue, 9 Jul 2013 13:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=0.883, 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 7BKrXNmwsh6F for ; Tue, 9 Jul 2013 13:52:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E65AE11E8162 for ; Tue, 9 Jul 2013 13:52:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-5f-51dc78048c90 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4E.EB.06741.4087CD15; Tue, 9 Jul 2013 22:52:20 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Tue, 9 Jul 2013 22:52:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5EAF71102AF; Tue, 9 Jul 2013 23:52:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DC9C2555C9; Tue, 9 Jul 2013 23:52:16 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 898D1550E5; Tue, 9 Jul 2013 23:52:16 +0300 (EEST) Message-ID: <51DC7811.2020303@ericsson.com> Date: Tue, 9 Jul 2013 23:52:33 +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/20130509 Thunderbird/17.0.6 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+NgFprHLMWRmVeSWpSXmKPExsUyM+JvrS5LxZ1Ag5dd5hbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgynj37yx7wQmmilX/P7A0ME5g6mLk5JAQMJFY fPMSO4QtJnHh3nq2LkYuDiGBw4wSz2Z/Z4Zw1jFKbPp5FCqzl1Hi+8lNrHCZ/j/bmEH6hQRW MEosWakIYvMKaEvcnjeJDcRmEVCR2PahjxHEZhOwl7g54TrYPlGBZIkD/e2sEPWCEidnPmEB sUUEZCT2btoMNpMZaM7sO7PAbhUWcJa4OnktG0TcVuLCnOssELa8xPa3c5ghflCTuHpuE9Q9 qhJX/71inMAoPAvJillI2mchaV/AyLyKkT03MTMnvdxwEyMwjA9u+a27g/HUOZFDjNIcLEri vJv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJwSU/bhcKAcT/Zd48Cox5vqxZctybxi OvFMq961T+cvLdJWk36td+xJXeA1N0Pvjqnc6SJT9t6xu9F+amVCzlVPwVs9q37sOhHUv3ne 8lPPp32duLshsc3xfE2G3wPW1QujkzKz9kRUmakG7Hxgwnw1zSro5FdDT+3X0bu2VwrNidEJ eRnjcV+JpTgj0VCLuag4EQABEQC3MQIAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Minutes of the MMUSIC WG June 17th virtual interim meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:52:35 -0000 Hi all, The draft minutes of the MMUSIC WG June 17th virtual interim meeting have been posted at: http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/minutes/minutes-interim-2013-mmusic-3 Please review the minutes and let us know of any comments or corrections. Thanks, Ari & Flemming (MMUSIC co-chairs) From thomas.stach@siemens-enterprise.com Tue Jul 9 14:20: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 C625111E8156 for ; Tue, 9 Jul 2013 14:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 1cZzruPPmcIK for ; Tue, 9 Jul 2013 14:20:44 -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 0521821F9D3A for ; Tue, 9 Jul 2013 14:20:43 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CD48D1EB8457; Tue, 9 Jul 2013 23:20:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 23:20:30 +0200 From: "Stach, Thomas" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCABH+3wIAAU2UAgAIHq9A= Date: Tue, 9 Jul 2013 21:20:29 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> In-Reply-To: <51DAE06C.1030203@alum.mit.edu> Accept-Language: de-AT, 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] Trickle ICE for SIP 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: Tue, 09 Jul 2013 21:20:48 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, 08 July, 2013 17:53 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >=20 > Thomas, >=20 > On 7/8/13 5:24 AM, Stach, Thomas wrote: >=20 > > [TS] Saving the half RTT is not my primary goal. When implementing > ICE we got away without requiring PRACK. > > I want to keep this property, since it allows [TS] The remainder of the sentence got lost. It should have read "... since= it allows easier introduction RTCWEB client with trickle ICE into a SIP ne= twork that never used PRACK." >=20 > I get it that you think PRACK is hard to implement. > But hard compared to *what*? I suspect that this will introduce > complexity elsewhere. [TS] With respect to this complexity I just see the 481 handling for the IN= FO.=20 Compared to all the new states that I need when I implement PRACK (which ca= n include a new offer as you know), I just have to keep the previously sent= provisional response together with the INFO request. The latter I have to = keep anyhow for potential retransmissions.=20 If I get a 481, I resent the 18x and the INFO request. BTW: Just form emphasis. This is only needed if there is a UDP hop somewher= e, in case of TCP/TLS the 18x would never be lost. >=20 > >> If the response for a request within a dialog is a 481 > >> (Call/Transaction Does Not Exist) or a 408 (Request Timeout), > the > >> UAC > >> SHOULD terminate the dialog. > > [TS] We are in the dialog establishing phase here and when the 180 > was lost we don't even have an early dialog. > > So this rule does not apply. The 481 to the INFO would rather be the > indicator for this situation. As stated above we can prescribe that the > 481 (and only the 481) is to be sent for the INFO and what happens > next, i.e. retransmit the 180. >=20 > This is part of the house of cards that I was talking about. > You seem to be saying that a special rule should be be adopted, > allowing > INFO to be sent from INVITE-UAS before it is known that the dialog has > been established. And then a special rule for processing 481 responses > to INFO in this context. [TS] Let me reject the comparison with a "house of cards". We are currently= specifying a new feature. There are no deployed implementations yet. Thus = we can exactly specify what should happen at the UAC when it receives an ou= t-of-dialog INFO because the dialog establishing unreliable 18x was lost, i= .e. to send 481.=20 On the UAS side we can also specify what to do when the INFO gets a 481. I.= e. resend the 18x and the INFO request. I consider this closer to a solid foundation than to a house of cards. Regards Thomas >=20 > >> Also, keep in mind that the 180 carries an entire SDP answer. If > INFOs > >> are competing with 180s then they may potentially need to carry that > >> too > >> (or at least the ICE parts) and it would be good if we don't have to > >> open that can of worms. > > [TS] For the trickle-ICE application of the info-package I would just > recommend sending (all) the ICE candidates. > > This eliminates the competition, you just take what you got last. >=20 > Certainly it will be simpler if all candidates are sent each time. > But I don't think that means you can just take what you got last. You > still need to check if what you got is *older* than what you already > have, and if so ignore it. >=20 > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@siemens-enterprise.com Tue Jul 9 14:21: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 17E9111E8172 for ; Tue, 9 Jul 2013 14:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 6qRGhHHL04zy for ; Tue, 9 Jul 2013 14:21:28 -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 1B9BE21F9D4E for ; Tue, 9 Jul 2013 14:21:12 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4285623F0602; Tue, 9 Jul 2013 23:21:07 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 23:21:07 +0200 From: "Stach, Thomas" To: Paul Kyzivat Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eUM0XqJDBgnkG3edAtUHILLJlUd8BAgAGKMgCAACstAIAEXPYAgABOUoCAAgJgEA== Date: Tue, 9 Jul 2013 21:21:05 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51D6F88E.5000209@alum.mit.edu> <51DAE33B.3070507@alum.mit.edu> In-Reply-To: <51DAE33B.3070507@alum.mit.edu> Accept-Language: de-AT, 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] Trickle ICE for SIP 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: Tue, 09 Jul 2013 21:21:33 -0000 Paul, > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, 08 July, 2013 18:05 > To: Stach, Thomas > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >=20 > Just responding to things that haven't already been covered. >=20 > On 7/8/13 5:44 AM, Stach, Thomas wrote: >=20 > >> Yes, why is it such an issue to require PRACK? > > [TS] I see potential for easier GW/SBC interworking with vanilla-ICE > UAs, that did not implement PRACK >=20 > I don't get it. >=20 > If you are talking about SBCs that terminate/relay media, then the leg > doing trickle-ICE is separate from the leg doing vanilla-ICE. So what > is > the issue? >=20 > And if you have a signaling-only SBC, and one leg supports trickle-ICE > while the other side supports only vanilla-ICE, then just use > vanilla-ICE e2e. You won't gain anything by an intermediary trying to > map trickle-ICE to vanilla-ICE. [TS]=20 If the trickle-ICE side uses PRACK and the vanilla ICE side does not, the i= nterworking SBC does not only have to collect the trickled candidates and s= end it on as a bunch once trickling finished. It also has to interwork PRAC= K. As you know the PRACK request can contain a new SDP offer or you could also= use UPDATE for another SDP O/A before the 200 OK to the INVITE request. Th= is is rather nasty to interwork if not impossible. >=20 > >> It is a good thing to implement for many reasons. > > [TS] There are also good reasons against PRACK. e.g. the much more > complicated state machine. >=20 > Yes, but once you have done it then it is there to use for all sorts of > things. The alternative seems to be to instead introduce a lot of new > complexity that is *only* applicable to trickle-ICE. >=20 > Thanks, > Paul From randy@qti.qualcomm.com Tue Jul 9 14:52: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 B7FCB11E8171 for ; Tue, 9 Jul 2013 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1NmM62AmSVG2 for ; Tue, 9 Jul 2013 14:52:10 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2611E8164 for ; Tue, 9 Jul 2013 14:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373406726; x=1404942726; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=YnEbtbgEtIhBd5F9dsFF/HT36nIOOw91+NgSVQfTcuU=; b=LZJDaK1y79QN0VO1qDU258MDHRUFjEwbYtn16WmDT5o9bip2M6PxR8rm y4LP4/3++Vz0eQYbRn30El9/Ou4E8EQLDKkDF5bzoGDrb/Bj49SV7a1or 5vB+Dr6P45lQqL+QU1EnkQcw/3F80HcrlGA5tp4Dyb5Nnw2HZOdaUk855 A=; X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="47185513" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Jul 2013 14:52:03 -0700 X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="502264979" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2013 14:52:03 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 14:52:02 -0700 Message-ID: In-Reply-To: References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com>, <51DA8FA6.4060705@omnitor.se>, , <51DBA497.6050400@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Tue, 9 Jul 2013 14:48:30 -0700 To: Bernard Aboba , Gunnar Hellstrom From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:52:14 -0000 At 11:56 PM -0700 7/8/13, Bernard Aboba wrote: > > >> This is very similar to the use case included of a user who can >> hear English but not speak; an audio and text stream are set up, >> both using English. The point of negotiating language is to get >> the call to a callee who can communicate with the caller (e.g., a >> PSAP and call taker who understand at least one language in common >> with the caller). The point is not to fully specify exactly how >> the media will be used; there is no need to do so and it won't >> help get the call to the right callee, but will make things much >> more complex. >> >> It is simpler and more robust to handle cases such as you describe >> and the one in the document now by negotiating the needed media as >> two-way streams. >> > [BA] I think this example points out the limitations of a call > routing approach that relies solely on language. In this case, it > is important for the "hint" to cause the call to be routed to an > endpoint that can handle text media, since otherwise the caller > will not be able to communicate. Since both the audio and text > media are set up using English in both directions, one might > conclude that the "hint" need only express the language preference > (English), but that would not be sufficient to get a satisfactory > result. What needs to be expressed in the "hint" is *both* a > preference for English and a requirement for text media support. [RG] In the case of emergency calls, policy based routing can look at media needs and with the proposal to include language in SDP, also language. So for emergency calls, there is no need for a SIP "hint." The SIP "hint" is in the current draft because at the Orlando discussion it was suggested as a way to allow non-emergency calling facilities that lack the ability to examine SDP when determining call handling. I agree that it isn't sufficient if the caller requests non-audio media. I think currently, corporate call centers usually have a dedicated number for text communications, while for audio they resort to "press 1 for , 2 for , ..." approaches. So having just language in the hint would map to current usage. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This is not a novel to be tossed aside lightly. It should be thrown with great force. --Dorothy Parker From pkyzivat@alum.mit.edu Tue Jul 9 14:52: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 A38DB11E8185 for ; Tue, 9 Jul 2013 14:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=0.332, 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 64giHNC5dqDH for ; Tue, 9 Jul 2013 14:52:47 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 548FF11E817C for ; Tue, 9 Jul 2013 14:52:37 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id yKpR1l0020bG4ec51Msayl; Tue, 09 Jul 2013 21:52:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id yMsa1l00d3ZTu2S3PMsaMQ; Tue, 09 Jul 2013 21:52:34 +0000 Message-ID: <51DC8621.9070602@alum.mit.edu> Date: Tue, 09 Jul 2013 17:52:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stach, Thomas" References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> 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=1373406754; bh=06AyjRxh1JRDI+EzrliJBKijNMzfj0HPQ43bYbV36vw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nZunLlGzBUzGH0UdEc7WUcFAT00cjNH6h1PMmZY6is9VTwdn6FF6Y7kwzxexyTS8V JljBT7lHtSHhW/AwCG7NGTdysm3FIrRSSYZMGA0ya9ft3OfdFxhquf4NNY0B4bpqQS 1uX3xA21dUKIwo7V5v9U59TAYKmonz0ZPrn2OOBScRFUDvQpXYktESBkxyStg6ejBd iDvRUsdQ0bIGW//kDCDiavMnwdwbuJI/dC/VGVeaiCftqndNn7t91wL/qUvIDmlqQS pDFHExXgZpzjp9vJbsT+KqqtmIqZHv8rItZd+0Xi9q/nCSMbTY+zaaCWfyfr59Rj25 anKBvVBGz0z5Q== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Tue, 09 Jul 2013 21:52:51 -0000 On 7/9/13 5:20 PM, Stach, Thomas wrote: > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Monday, 08 July, 2013 17:53 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >> >> Thomas, >> >> On 7/8/13 5:24 AM, Stach, Thomas wrote: >> >>> [TS] Saving the half RTT is not my primary goal. When implementing >> ICE we got away without requiring PRACK. >>> I want to keep this property, since it allows > [TS] The remainder of the sentence got lost. It should have read "... since it allows easier introduction RTCWEB client with trickle ICE into a SIP network that never used PRACK." >> >> I get it that you think PRACK is hard to implement. >> But hard compared to *what*? I suspect that this will introduce >> complexity elsewhere. > [TS] With respect to this complexity I just see the 481 handling for the INFO. > Compared to all the new states that I need when I implement PRACK (which can include a new offer as you know), I just have to keep the previously sent provisional response together with the INFO request. The latter I have to keep anyhow for potential retransmissions. > If I get a 481, I resent the 18x and the INFO request. > BTW: Just form emphasis. This is only needed if there is a UDP hop somewhere, in case of TCP/TLS the 18x would never be lost. With PRACK, the work is implementing it as it is specified. And then you can use it everywhere, not just for trickle-ICE. I'm not sure I understand your proposal for using info in the context, but I *think* you are asking for *special* handling of 481 for INFO, contrary to how specs call for it to be implemented. For one think, this would effectively be a revision to some existing specification. And maybe you only what this handling when INFO is used for trickle-ICE? Remember, introducing this will often mean using an existing implementation of INFO for this purpose. >>>> If the response for a request within a dialog is a 481 >>>> (Call/Transaction Does Not Exist) or a 408 (Request Timeout), >> the >>>> UAC >>>> SHOULD terminate the dialog. >>> [TS] We are in the dialog establishing phase here and when the 180 >> was lost we don't even have an early dialog. >>> So this rule does not apply. The 481 to the INFO would rather be the >> indicator for this situation. As stated above we can prescribe that the >> 481 (and only the 481) is to be sent for the INFO and what happens >> next, i.e. retransmit the 180. >> >> This is part of the house of cards that I was talking about. >> You seem to be saying that a special rule should be be adopted, >> allowing >> INFO to be sent from INVITE-UAS before it is known that the dialog has >> been established. And then a special rule for processing 481 responses >> to INFO in this context. > [TS] Let me reject the comparison with a "house of cards". We are currently specifying a new feature. There are no deployed implementations yet. Thus we can exactly specify what should happen at the UAC when it receives an out-of-dialog INFO because the dialog establishing unreliable 18x was lost, i.e. to send 481. > On the UAS side we can also specify what to do when the INFO gets a 481. I.e. resend the 18x and the INFO request. > I consider this closer to a solid foundation than to a house of cards. Lets first decide in you are proposing a special mechanism for use with trickle-ICE, or if you are proposing a revison (bug fix?) to INFO, or to 3261 & 5057. If you are proposing a change in how INFO works exclusively when used for trickle-ICE then I think it is a non-starter. If you are proposing a revision regarding the handling of presumed-to-be in-dialog requests from UAS to UAC before the UAS has proof that the UAC knows of the dialog, then we can talk. Thanks, Paul > Regards > Thomas > >> >>>> Also, keep in mind that the 180 carries an entire SDP answer. If >> INFOs >>>> are competing with 180s then they may potentially need to carry that >>>> too >>>> (or at least the ICE parts) and it would be good if we don't have to >>>> open that can of worms. >>> [TS] For the trickle-ICE application of the info-package I would just >> recommend sending (all) the ICE candidates. >>> This eliminates the competition, you just take what you got last. >> >> Certainly it will be simpler if all candidates are sent each time. >> But I don't think that means you can just take what you got last. You >> still need to check if what you got is *older* than what you already >> have, and if so ignore it. >> >> Thanks, >> Paul >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Jul 9 15:00: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 E754A21F9AA2 for ; Tue, 9 Jul 2013 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=0.323, 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 JiCWqeUOhEOS for ; Tue, 9 Jul 2013 15:00:11 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5E11E8193 for ; Tue, 9 Jul 2013 14:59:05 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id yMmk1l0030cZkys5AMz54x; Tue, 09 Jul 2013 21:59:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id yMz51l00F3ZTu2S3WMz5YY; Tue, 09 Jul 2013 21:59:05 +0000 Message-ID: <51DC87A8.6000301@alum.mit.edu> Date: Tue, 09 Jul 2013 17:59:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stach, Thomas" References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51D6F88E.5000209@alum.mit.edu> <51DAE33B.3070507@alum.mit.edu> 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=1373407145; bh=XZsnmzL5pjdnw4ur08iYE2o5CdvtSWEvBbwGfqKMALw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=izOKPXjxvnr8A0Msat2bmrV+mhLh9vGYP1lh98FR+GBY2GIdycuQXutwPAGXagfkE 3gog4QRlg6FvdpQbyAGMWwQItzy11KbZznX5d9+UIgW7JQcVCRGBUxS0WpCbvRCHaX POWC7h4jL6Sk7XgkqKPo8axA6AaDelCO0mGJcKwVZt3P0tnX9f3hvPR3RiQ/H93dsF xKGX3YF0cDdr7BBxxhS28uyA0xoArTHkeRWwmUYAwp1IKOyr3gopvDMyLzTi3KBexU 35GozpHBjHshShCJvzPAPrLS9Uo9wXI4g/r+RWS8JCCZmcbwSIXowCc2xzBbd02iJR k1Q5oZZEgErnQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Tue, 09 Jul 2013 22:00:36 -0000 On 7/9/13 5:21 PM, Stach, Thomas wrote: > Paul, > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, 08 July, 2013 18:05 >> To: Stach, Thomas >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >> >> Just responding to things that haven't already been covered. >> >> On 7/8/13 5:44 AM, Stach, Thomas wrote: >> >>>> Yes, why is it such an issue to require PRACK? >>> [TS] I see potential for easier GW/SBC interworking with vanilla-ICE >> UAs, that did not implement PRACK >> >> I don't get it. >> >> If you are talking about SBCs that terminate/relay media, then the leg >> doing trickle-ICE is separate from the leg doing vanilla-ICE. So what >> is >> the issue? > >> >> And if you have a signaling-only SBC, and one leg supports trickle-ICE >> while the other side supports only vanilla-ICE, then just use >> vanilla-ICE e2e. You won't gain anything by an intermediary trying to >> map trickle-ICE to vanilla-ICE. > [TS] > If the trickle-ICE side uses PRACK and the vanilla ICE side does not, the interworking SBC does not only have to collect the trickled candidates and send it on as a bunch once trickling finished. It also has to interwork PRACK. > As you know the PRACK request can contain a new SDP offer or you could also use UPDATE for another SDP O/A before the 200 OK to the INVITE request. This is rather nasty to interwork if not impossible. If trickle-ICE worked without PRACK, then the SBC *still* needs to collect up all the trickled candidates and send them when it can based on the limitations of vanilla-ICE. So the use of trickle-ICE provides no speedup compared to using vanilla-ICE e2e. Also, it sounds like trickle-ICE is requiring changes in the ordering of how candidates are tried. If one side uses trickle-ICE and the other doesn't, then ISTM that may break. So I'm still not seeing a case here when it makes sense to gateway between trickle-ICE and vanilla-ICE. There may be one, but I'm not seeing it. Thanks, Paul From randy@qti.qualcomm.com Tue Jul 9 15:01: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 3C52F21F9B38; Tue, 9 Jul 2013 15:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rZJqI+78IdPZ; Tue, 9 Jul 2013 15:01:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 782DD21F8449; Tue, 9 Jul 2013 15:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373407234; x=1404943234; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=pmFXySTM+w7wMt2mmty/HJ43gukfg1gxe6jgz9K4CIw=; b=x0WjA2LYZBmiLoqCK0XCOlEnck1Hm+qia8KZRU8awHGWb1LBHv0PPa4P KX/G3DARKP26Pt+nMdp1eEfsNhloBm5KDwHZbZfU+qtjk7odk1Ssesjke mQ9ZOQ6J2T0q+4QcTW+KnZCErO57ewNYJULEfZU3zQjfbmGhk6csIAgyQ w=; X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="61661349" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 09 Jul 2013 15:00:25 -0700 X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="502268243" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2013 15:00:14 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 15:00:12 -0700 Message-ID: In-Reply-To: <51DBB813.4060607@nteczone.com> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Tue, 9 Jul 2013 14:58:28 -0700 To: Christian Groves From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: Randall Gellens , "clue@ietf.org" , mmusic@ietf.org Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:01:04 -0000 Hi Christian, Thanks for the review and comments. At 5:13 PM +1000 7/9/13, Christian Groves wrote: > I had a look at the draft with respect to CLUE. The main difference > between the CLUE usage of language and what is being proposed is > the ability for the sender to specify sending AND receiving > preferences. The current CLUE model is that an each endpoint > Advertises what it can do and then each consumer chooses from this > list. This could still result in an asymmetric usage of language > (just negotiated differently). The draft doesn't try to accommodate asymmetric usage, since that usually can just happen without detailed technical backing. The "-send" and "-receive" attributes are there because Harald warned that we'd be violating SDP otherwise. If CLUE can allow the caller to indicate in the offer language needs for each stream, this to be taken into accounting in policy bvased routing, and the callee to respond to the offer with a language in common, then perhaps we don't need this proposal at all and can just drop it in favor of CLUE. I admit at this point I am ignorant of CLUE (yes, clueless about CLUE). > You may need to consider the case where there are multiple streams > of the same media type with different languages. e.g. an audio > conference where one stream is the main audio of the conference and > there's a second stream with a translation/s. This is the type of > thing CLUE is considering. I'm not sure how this fits in with your > work? This is a different, and more complex, scenario than what this proposal is trying to solve. This proposal is focused on simpler cases where someone places an emergency call or calls a corporate call center. Possibly this can be just a simple case of the more complex cases? > > Some other comments: > > With regards to the SIP "hint" it wasn't clear to me how this > matches the languages in "humintlang-send" and "humintlang-recv". > Is it planned that both will be supported in the header? I suppose this depends on if the "-send" and "-recv" are really needed, and if so if they should be the same. > > The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller > sets media and language) but in the final paragraph of the 7.3 it > sounds like the "hint" is only for audio? Good catch -- this will need to be sorted out. > > 7.4 Silly states - How do the language sub-tags come into play > here? For example: the endpoint might specify a language for an > audio stream which may be valid. If the endpoint also specified a > sub-tag with "script" I guess it makes it a silly state? > > Regards, Christian > > On 8/07/2013 8:40 AM, Randall Gellens wrote: >> At 4:50 PM +1100 3/25/13, Christian Groves wrote: >> >>> Hello, >>> >>> One thing that doesn't seem to be noted is an overlap with the >>> work of the CLUE WG. There has been some discussion in the CLUE >>> working group about adding attributes to captures to describe the >>> language, whether sub-titles are used, whether a stream comes >>> from an interpreter, etc. Where multiple streams are used I would >>> expect any work in this area should be aligned. >>> >>> Regards, Christian >> >> Hi Christian, >> >> Thanks for the info. Would it make sense to talk about this in >> Berlin? I agree that if there is overlap in the approaches we >> should align them. >> >> Also, I have an updated draft that was just uploaded. It is now >> named 'draft-gellens-mmusic-negotiating-human-language-00' (adding >> -mmusic and hence reverting back to -00). >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Not a shred of evidence exists in favor of the idea that life is serious. --Brendan Gill From emil@sip-communicator.org Tue Jul 9 15:41: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 4298721F9CD7 for ; Tue, 9 Jul 2013 15:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 R6V87uZabqz0 for ; Tue, 9 Jul 2013 15:41:08 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id AA2E921F9B97 for ; Tue, 9 Jul 2013 15:41:07 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so5303440wgg.10 for ; Tue, 09 Jul 2013 15:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=0MVWkRFiNvPyX53C0AgILe2WzgX7go8Rlb1mIslH/BI=; b=nvWshb+EqGYzqW35JaRKT4rsY52E1ywqMJsT40VIQfXEEqvZCeB2hOCAeA1DYaz8Az NQDdeEgIBHL9PRHscF2hXrBeSYAHFOqFad8gbBrNrIQ19+bwcUiPPBeZYutmUDNtDQ1A IymeLmGFj1oMv066W1bZbHBEQ6xoaxhwbLVicEpstuuSjPo12x4E5rbbPpYj43XV2Ikd uHzf2HF3ZqcWkOWLzLGB0bh9h/ZVGg4xIwoRBNJ1R1YbGuQ99Yke13TWl0NqiiOEeZ0j u4QWZQfppVP8myZZqh6NryOfKVLjW/xiDsUwFq4rmOsdV9VWhCKorON5d/29kf6pmqO/ Iz2w== X-Received: by 10.180.10.168 with SMTP id j8mr15436962wib.15.1373409666724; Tue, 09 Jul 2013 15:41:06 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:2403:2255:f094:fc64]) by mx.google.com with ESMTPSA id cz9sm19169405wib.3.2013.07.09.15.41.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:41:05 -0700 (PDT) Message-ID: <51DC9180.5070407@jitsi.org> Date: Wed, 10 Jul 2013 00:41:04 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stach, Thomas" References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn1SbTy7Zqph553XIshBI/bkp/e3SwKfFcG1itM7oX0t78jiClOn9KUwxrFm5Eepo+brd5s Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Tue, 09 Jul 2013 22:41:12 -0000 A few cross mail replies: On 09.07.13, 23:20, Stach, Thomas wrote: > BTW: Just form emphasis. This is only needed if there is a UDP hop > somewhere, in case of TCP/TLS the 18x would never be lost. What does this change for anyone? Clients have no way of knowing whether there would be UDP hops along the way so they would always need to be ready for this option. > [TS] As Trickle-ICE is just being specified, we are in a position to > specify this handling. While this is true, I see the following issue here: cumulative sending is only necessary for SIP/UDP (which is quite a paradox because SIP/UDP with ICE would break in a big number of cases). > [TS] As the ICE/STUN logic resides in the browser not in the JS app, > this would be a matter of the API definition to always provide all > known candidates towards the JS APP for sending. On the receiving > side the JS APP would also just have to push all received candidates > through the browser API. I find it strange that we would be imposing constraints on a new generic API because of a broken use case that only exists with one usage protocol. Especially given that the said use case (SIP+ICE over UDP) is NOT going to work anyway because of MTUs and improper IP fragmentation handling on various devices today. >>> We are indeed likely to get a 481 when sending INFOs and the 180 >>> hasn't yet made it to the remote side. However 481 might also >>> imply that our dialog is simply dead for some reason and in this >>> case 3261 says: >>> >>> >>> If the response for a request within a dialog is a 481 >>> (Call/Transaction Does Not Exist) or a 408 (Request Timeout), >>> the UAC SHOULD terminate the dialog. > > [TS] We are in the dialog establishing phase here and when the 180 > was lost we don't even have an early dialog. So this rule does not > apply. I am not sure this is true. There *is* an early dialog at the side that's sending the 180. The INFO is a second request within that same dialog and 3261 is very clear that a 481 would lead to termination of the dialog. Specifying different behaviour here would mean that many developers may need to start fighting/changing their SIP stacks. Cheers, Emil -- https://jitsi.org From gunnar.hellstrom@omnitor.se Tue Jul 9 16:23: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 EF34A21E805E for ; Tue, 9 Jul 2013 16:23: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=[AWL=0.001, 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 ScRHh2uWDfDM for ; Tue, 9 Jul 2013 16:23:32 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 7B34121E8051 for ; Tue, 9 Jul 2013 16:23:26 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 10 Jul 2013 01:23:17 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 71D923A12C for ; Wed, 10 Jul 2013 01:23:17 +0200 (CEST) Message-ID: <51DC9B66.6090302@omnitor.se> Date: Wed, 10 Jul 2013 01:23:18 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 23:23:43 -0000 On 2013-07-09 23:58, Randall Gellens wrote: > This is a different, and more complex, scenario than what this > proposal is trying to solve. This proposal is focused on simpler > cases where someone places an emergency call or calls a corporate call > center. Possibly this can be just a simple case of the more complex > cases? My view is that it is intended to also cover user-to-user cases, where preferences are compared and a relay service (or language interpreter) can be invoked to bridge language gaps. Gunnar From emil@sip-communicator.org Tue Jul 9 18:58:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121611E80F4 for ; Tue, 9 Jul 2013 18:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UeWeocTd+Fxt for ; Tue, 9 Jul 2013 18:58:31 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 063E011E80EF for ; Tue, 9 Jul 2013 18:58:30 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so5434624wes.27 for ; Tue, 09 Jul 2013 18:58:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=Q9TRfyvpn8pRtOziPfGPumCbLZgW6Y3nXi5kySZzAHI=; b=Iy4HM7LN99WxxA/tRmnwa3M3z14qQcenho1ZRsPSosdmuKbhTt47cHwPH8NnSzM1YU ddznykguogU67zStKVXW2xOPbNyEj5DUXXtMCbWbOfma5m8/yy3i2SCP2MljTDE0iKKu h5IoHFWz/G5vj4sHXLd4bi7+YuzOWyQIi3t+zGL30fG+QkY2lMZJtIIfB4nqKOPRlzvU 1iv0P3IAkH7YWfmO7i90IhErLxwbzQPbUCf/gdg3oa5PlFBU8WnykfbZyn0yAXyupv75 7LHw19tpQ7hAwYt7Q2z06qiuE85FG2H7Y5Tsl+ufSuAfWeHyyCPXbYnVfuGqA1YooWGl WKNQ== X-Received: by 10.180.90.73 with SMTP id bu9mr15804983wib.32.1373421510024; Tue, 09 Jul 2013 18:58:30 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:2403:2255:f094:fc64]) by mx.google.com with ESMTPSA id x2sm20450563wif.3.2013.07.09.18.58.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:58:29 -0700 (PDT) Message-ID: <51DCBFC2.9020006@jitsi.org> Date: Wed, 10 Jul 2013 03:58:26 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <51DC0595.4070203@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnJkwgR4VSWzs/GrUzPZX65JEUXDh0N1aIeV9eg4a6487PxOMKZxt1aH1bMgpZH066S0sbX Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE and frozen candidates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 01:58:36 -0000 Hey Martin, On 09.07.13, 21:45, Martin Thomson wrote: > On 9 July 2013 05:44, Emil Ivov wrote: >> While 1 and especially 2 may be preferable in terms of efficiency, >> personally, I am worried that getting it right in terms of spec and >> implementation is non-trivial and this may become a common reason for >> interoperability problems. Therefore, 3 does seem like the simplest way to >> go. > > You are going to want to ensure that both peers check in the same > order. What exactly do you mean by "in the same order"? Do you mean that: a) they should try and make sure that they are checking the candidate pair that is symmetric to the one their peer is testing and b) all other components for the involved foundations should be frozen? Do you have a better wording? > 3 seems a little too loose for me. It is indeed loose but I can't think of a reason why it wouldn't work even with several seconds of RTT. So, unless you are going to manually paste every new candidate into a mail and then do the the same on the remote side, you should probably be fine. Ekr, I believe you mentioned you were doing this in Firefox? How is it working? > I think that some sort of > mechanism is going to be needed to avoid problems with races, since > both peers will have different sets of candidate pairs at every point > in the process. OK. Do you mean something like 2. or do you have another mechanism in mind? Emil -- https://jitsi.org From Christian.Groves@nteczone.com Tue Jul 9 21:45: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 2C4C611E811D for ; Tue, 9 Jul 2013 21:45:29 -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 fCb7ZJZu5FGs for ; Tue, 9 Jul 2013 21:45:27 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 3610D11E80D5 for ; Tue, 9 Jul 2013 21:45:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAOvl3FF20VFL/2dsb2JhbAANTYM7wVWBKIMXAQEBBAEBATUbFQYEBgEQCw4KCRYPCQMCAQIBFTAGDQEFAgEBiBenS5IOBI9rB4N0A6xA Received: from ppp118-209-81-75.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.81.75]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Jul 2013 14:15:25 +0930 Message-ID: <51DCE6DE.2060100@nteczone.com> Date: Wed, 10 Jul 2013 14:45:18 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:45:29 -0000 Hello Randall, Please see my response below. Regards, Christian On 10/07/2013 7:58 AM, Randall Gellens wrote: > Hi Christian, > > Thanks for the review and comments. > > > At 5:13 PM +1000 7/9/13, Christian Groves wrote: > >> I had a look at the draft with respect to CLUE. The main difference >> between the CLUE usage of language and what is being proposed is the >> ability for the sender to specify sending AND receiving preferences. >> The current CLUE model is that an each endpoint Advertises what it >> can do and then each consumer chooses from this list. This could >> still result in an asymmetric usage of language (just negotiated >> differently). > > The draft doesn't try to accommodate asymmetric usage, since that > usually can just happen without detailed technical backing. The > "-send" and "-receive" attributes are there because Harald warned that > we'd be violating SDP otherwise. [CNG] By asymmetric I mean that a different language could be used in the send and receive sections. Are you saying that the draft assumes the same language in the "-send" and "-receive" attributes? > > If CLUE can allow the caller to indicate in the offer language needs > for each stream, this to be taken into accounting in policy bvased > routing, and the callee to respond to the offer with a language in > common, then perhaps we don't need this proposal at all and can just > drop it in favor of CLUE. I admit at this point I am ignorant of CLUE > (yes, clueless about CLUE). [CNG] I think you still want your proposal. Endpoints shouldn't be compelled to use CLUE to indicate a language preference. The first CLUE advertisement will most likely come after the initial SIP SDP Offer so it would be difficult to route the call based on CLUE language information. I'm still trying to understand what the relationship/mapping would be between the language specified as a SIP "hint", to the SDP "-send" and "-receive" attributes in an Initial SDP Offer to any subsequent CLUE signalling that includes a language tag. For example: If an endpoint sends an initial SIP (with 'hint' with SDP Offer with a set of languages for a single media (and indicates CLUE support). Should the endpoint when sending a CLUE Advertisement only advertise captures that contain the negotiated languages? (Seeing "the hint" is at the call level) Or, should it treat any media described by CLUE as something completely new? > > >> You may need to consider the case where there are multiple streams >> of the same media type with different languages. e.g. an audio >> conference where one stream is the main audio of the conference and >> there's a second stream with a translation/s. This is the type of >> thing CLUE is considering. I'm not sure how this fits in with your work? > > This is a different, and more complex, scenario than what this > proposal is trying to solve. This proposal is focused on simpler > cases where someone places an emergency call or calls a corporate call > center. Possibly this can be just a simple case of the more complex > cases? [CNG] I don't think this is a problem for the SDP attributes, I think the issue is more for the SIP "hint" if it is media type specific. For example if you set "LANG1" and "LANG2" against "audio" and you actually have two streams one of LANG1 and another of LANG2 and base your routing decision on this there is a chance that you route to an endpoint based on LANG2 but when the endpoint inspects the SDP it actually wants the LANG1 stream. > >> >> Some other comments: >> >> With regards to the SIP "hint" it wasn't clear to me how this >> matches the languages in "humintlang-send" and "humintlang-recv". Is >> it planned that both will be supported in the header? > > I suppose this depends on if the "-send" and "-recv" are really > needed, and if so if they should be the same. [CNG] OK I didn't understand that from the draft. > >> >> The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller >> sets media and language) but in the final paragraph of the 7.3 it >> sounds like the "hint" is only for audio? > > Good catch -- this will need to be sorted out. > >> >> 7.4 Silly states - How do the language sub-tags come into play here? >> For example: the endpoint might specify a language for an audio >> stream which may be valid. If the endpoint also specified a sub-tag >> with "script" I guess it makes it a silly state? >> >> Regards, Christian >> >> On 8/07/2013 8:40 AM, Randall Gellens wrote: >>> At 4:50 PM +1100 3/25/13, Christian Groves wrote: >>> >>>> Hello, >>>> >>>> One thing that doesn't seem to be noted is an overlap with the >>>> work of the CLUE WG. There has been some discussion in the CLUE >>>> working group about adding attributes to captures to describe the >>>> language, whether sub-titles are used, whether a stream comes from >>>> an interpreter, etc. Where multiple streams are used I would expect >>>> any work in this area should be aligned. >>>> >>>> Regards, Christian >>> >>> Hi Christian, >>> >>> Thanks for the info. Would it make sense to talk about this in >>> Berlin? I agree that if there is overlap in the approaches we >>> should align them. >>> >>> Also, I have an updated draft that was just uploaded. It is now >>> named 'draft-gellens-mmusic-negotiating-human-language-00' (adding >>> -mmusic and hence reverting back to -00). >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From Christian.Groves@nteczone.com Tue Jul 9 21:49: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 8226921F9B08 for ; Tue, 9 Jul 2013 21:49:23 -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 JvyPKequkUdA for ; Tue, 9 Jul 2013 21:49:23 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id AEF5321F9A23 for ; Tue, 9 Jul 2013 21:49:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAO7m3FF20VFL/2dsb2JhbAANTYM7wVWBKIMXAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiBenTZIPBI9yFoNeA6xA Received: from ppp118-209-81-75.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.81.75]) by ipmail04.adl6.internode.on.net with ESMTP; 10 Jul 2013 14:19:21 +0930 Message-ID: <51DCE7CB.7080205@nteczone.com> Date: Wed, 10 Jul 2013 14:49:15 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> In-Reply-To: <51DC9B66.6090302@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:49:23 -0000 I wouldn't have thought that it would be use case specific... i.e. i'd only include my language when I called an emergency service. I would think an endpoint would be configured with the information and then provide it whenever I made a call. Is that the intent? Christian On 10/07/2013 9:23 AM, Gunnar Hellstrom wrote: > On 2013-07-09 23:58, Randall Gellens wrote: >> This is a different, and more complex, scenario than what this >> proposal is trying to solve. This proposal is focused on simpler >> cases where someone places an emergency call or calls a corporate >> call center. Possibly this can be just a simple case of the more >> complex cases? > My view is that it is intended to also cover user-to-user cases, where > preferences are compared and a relay service (or language interpreter) > can be invoked to bridge language gaps. > > Gunnar > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From internet-drafts@ietf.org Wed Jul 10 02:16: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 33C9221F9F1F; Wed, 10 Jul 2013 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, 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 OAi3im8+Wklv; Wed, 10 Jul 2013 02:16:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787721F9D15; Wed, 10 Jul 2013 02:16:43 -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.51.p2 Message-ID: <20130710091643.2043.3682.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 02:16:43 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 09:16:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt Pages : 22 Date : 2013-07-10 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and session or media titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Wed Jul 10 02:21: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 2061521F9F66 for ; Wed, 10 Jul 2013 02:21:13 -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.429, 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 4040Jo7c1YEw for ; Wed, 10 Jul 2013 02:21:08 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 40C9421F9DFA for ; Wed, 10 Jul 2013 02:21:08 -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 r6A9L5ce030255 for ; Wed, 10 Jul 2013 12:21:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jul 2013 12:21:05 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.174]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0328.011; Wed, 10 Jul 2013 09:21:04 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt Thread-Index: AQHOfU43VYRgdMcXYkK/3mXAeQJinZldor4A Date: Wed, 10 Jul 2013 09:23:16 +0000 Message-ID: References: <20130710091643.2043.3682.idtracker@ietfa.amsl.com> In-Reply-To: <20130710091643.2043.3682.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+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWkPb3JY0xFuatV6kzCBSrLWTKSsnTttdHvHk18KwzhuH560MswzpGNI7LjuFiTj2rgwvP3BJUW0BfPbzrJceRqDIkAASGgX16yGem46I2Eby9x7ByoKoe0F9D0J/S2NU1pIl7zdieaFpXdkkX/O1vEMBDn/JjwcA03YVqa+puvkLs1nSxr9ccxh4eZEAKe7dq47bVr+ZoJb5F/5K9utERhLa1CVZ3dXFF8sngpTWC5XI= x-originating-ip: [10.236.35.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2013 09:21:05.0574 (UTC) FILETIME=[CDE76C60:01CE7D4E] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 09:21:13 -0000 Dear WG, We have submitted version -07 of the SDP Miscellaneous Capabilities draft. = Changes requested during the IESG review are: - Added an example where two title capabilities are offered with different = character encodings - Added a reference to RFC5939 SDP Capability Negotiation in the Introducti= on section to remind implementers how supporting and/or requiring capabilit= y extensions is done during Offer/Answer negotiation (by the "csup" and "cr= eq" option tags). On behalf of the authors, Simo https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps=20 http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-07=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -07=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 10. hein=E4kuuta 2013 12:17 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-07.t= xt 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 : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt Pages : 22 Date : 2013-07-10 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and session or media title= s ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -07 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 gavin.llewellyn@crocodilertc.net Wed Jul 10 04:50: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 3079C11E811E for ; Wed, 10 Jul 2013 04:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 56PnpEuFpki6 for ; Wed, 10 Jul 2013 04:50:53 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B930921F9D0A for ; Wed, 10 Jul 2013 04:50:52 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so5758087lab.15 for ; Wed, 10 Jul 2013 04:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yPxxZSVquzzHBYqCJ2VZTeXoQMoOPiUvTo6rcggYWL4=; b=VM0dwaOISk6euXUuPRx7tW2xMOqVXt6b8iIZTvR8gLVthZn/MohsyuW2bQbz6kptHK 98eQx5FxvJzM91PxiyALv+5b4lVl5XMYT+dO8rs2MxUlhjp5rxa87OtLcfSicEaV8jAh UHsePr4ZZBgnOiGxYnJ7lkV3ShmCdZROG/hyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yPxxZSVquzzHBYqCJ2VZTeXoQMoOPiUvTo6rcggYWL4=; b=fQj/fng7BXtzf7mb+yD/0K7Zxl9SZ7xSkZ9RLJdaE/XIwOwUbA6kBekAkSmykdyaxF 1vZ0XK9DYECzfsBQW62B5ktQRnvc7BZrMcWfOKvqrd8gn/o4oO5+4+RwwiH4kaK8bTaw Sg4N4MGABDRgyavpa95LXDN2xP/twrTDOxD3/Pgjgl+i9gjAkdXY8r6CPw7MHlPyTApT 9t2z3CTyNY+Mp5JtHaENZ3d7/BnskadTpYhpQWrjhRqopWCxjmOfha+lRHH/wR8xhKC5 waV7ODCPD1HLbtyBAdEX9SZubxl05ciRMptvL/borER3Yj2zod8jzIeHNxVtRC6m2BB0 2bVA== MIME-Version: 1.0 X-Received: by 10.152.28.162 with SMTP id c2mr14709307lah.45.1373457051326; Wed, 10 Jul 2013 04:50:51 -0700 (PDT) Received: by 10.112.127.135 with HTTP; Wed, 10 Jul 2013 04:50:51 -0700 (PDT) X-Originating-IP: [90.152.0.102] In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Wed, 10 Jul 2013 12:50:51 +0100 Message-ID: From: Gavin Llewellyn To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=089e0160b6cea8abbf04e126e33b X-Gm-Message-State: ALoCoQn4DVuSYxxYRZOCU5SWP7+D3hKENXyz6BbnjyJpyDRzlIMpApb3FqAUnIhwlldEem1pMW4b X-Mailman-Approved-At: Wed, 10 Jul 2013 05:55:44 -0700 Cc: "dispatch@ietf.org" , "mmusic@ietf.org WG" Subject: Re: [MMUSIC] [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 11:50:58 -0000 --089e0160b6cea8abbf04e126e33b Content-Type: text/plain; charset=ISO-8859-1 As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for establishment of MSRP sessions between WebRTC endpoints. The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for the next version of our draft, but we have not had time to complete it. We will likely be implementing this as a feature in our WebRTC library in the near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binary data, etc). Having said that, it would have been appreciated if the authors had contacted Peter and/or myself to discuss the existing draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forward. I cannot see the value in introducing DataChannel gateways as a means to communicate with traditional TCP-based MSRP endpoints. I believe this is better catered for by the WebSocket-based solution, as described in draft-pd-dispatch-msrp-websocket, which already has client and server implementations, and is currently in-use in a production environment. Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficult for the client application to support both transports. I would like to see a clear justification for this aspect of the draft. One minor correction: the opening paragraph of section 5.2.3 appears to reference the wrong SDP syntax for sub-protocol-specific attributes; I believe it should reference the syntax for the new "wdcsa" attribute. Regards, Gavin Llewellyn -- Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd GPG key: 0xF8F6FFF2 On 9 July 2013 20:32, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to > use DataChannel transport for MSRP. Our draft does not place restrictions > on the number of MSRP sessions that can be established within an SCTP > association and describes alternatives for using a gateway to interconnect > to existing MSRP endpoints. The SDP extensions described are applicable to > other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. > > Richard > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 08, 2013 6:31 PM > To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) > Subject: New Version Notification for > draft-marcon-msrp-over-webrtc-data-channels-00.txt > > > A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt > has been successfully submitted by Jerome Marcon and posted to the IETF > repository. > > Filename: draft-marcon-msrp-over-webrtc-data-channels > Revision: 00 > Title: MSRP over WebRTC data channels > Creation date: 2013-07-09 > Group: Individual Submission > Number of pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels-00.txt > Status: > http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels > Htmlized: > http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00 > > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. This document > specifies how the Message Session Relay Protocol (MSRP) can be > instantiated as a WebRTC data channel sub-protocol, using the SDP > offer/exchange to negotiate out-of-band the sub-protocol specific > parameters. Two network configurations are documented: a WebRTC end- > to-end configuration (connecting two MSRP over data channel > endpoints), and a gateway configuration (connecting an MSRP over data > channel endpoint with an MSRP over TCP endpoint). > > > > > The IETF Secretariat > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0160b6cea8abbf04e126e33b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a co-author of=A0draft-pd-msrp-webrtc-00, I support this new draft for= establishment of MSRP sessions between WebRTC endpoints. =A0The SDP enhanc= ements allowing re-use of the SCTP association is very much along the lines= of what we had in mind for the next version of our draft, but we have not = had time to complete it. =A0We will likely be implementing this as a featur= e in our WebRTC library in the near future, as the DataChannel implementati= ons in browsers mature (support SCTP, reliable delivery, binary data, etc).=

Having s= aid that, it would have been appreciated if the authors had contacted Peter= and/or myself to discuss the existing draft and its limitations - we would= have been happy to receive feedback and work together to find the best sol= ution going forward.

I c= annot see the value in introducing DataChannel gateways as a means to commu= nicate with traditional TCP-based MSRP endpoints. =A0I believe this is bett= er catered for by the WebSocket-based solution, as described in=A0draft-pd-dispatch-msrp-websocket, which alre= ady has client and server implementations, and is currently in-use in a pro= duction environment. =A0Given the (intentional) similarities between the We= bSocket and DataChannel APIs, it is not difficult for the client applicatio= n to support both transports. =A0I would like to see a clear justification = for this aspect of the draft.

One minor correction: the opening paragraph of section 5.= 2.3 appears to reference the wrong SDP syntax for sub-protocol-specific att= ributes; I believe it should reference the syntax for the new "= wdcsa" attribute.

Regards,
Gavin Llewellyn

--Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd=
GPG key: 0xF8F6FFF2


On 9 July 2013 20:32, Ejzak, Richard P (= Richard) <richard.ejzak@alcatel-lucent.com> w= rote:
Please note our proposed alternative to draf= t-pd-msrp-webrtc-00 for how to use DataChannel transport for MSRP. =A0Our d= raft does not place restrictions on the number of MSRP sessions that can be= established within an SCTP association and describes alternatives for usin= g a gateway to interconnect to existing MSRP endpoints. =A0The SDP extensio= ns described are applicable to other potential DataChannel sub-protocols su= ch as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-marcon-msrp-over-webrtc-data-channels
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 MSRP over WebRTC data channels
Creation date: =A0 2013-07-09
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels= -00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
=A0 =A0The Real-Time Communication in WEB-browsers (RTCWeb) working group i= s
=A0 =A0charged to provide protocols to support direct interactive rich
=A0 =A0communication using audio, video, and data between two peers' we= b-
=A0 =A0browsers. =A0For the support of data communication, the RTCWeb worki= ng
=A0 =A0group has in particular defined the concept of bi-directional data =A0 =A0channels over SCTP, where each data channel might be used to
=A0 =A0transport other protocols, called sub-protocols. =A0This document =A0 =A0specifies how the Message Session Relay Protocol (MSRP) can be
=A0 =A0instantiated as a WebRTC data channel sub-protocol, using the SDP =A0 =A0offer/exchange to negotiate out-of-band the sub-protocol specific =A0 =A0parameters. =A0Two network configurations are documented: a WebRTC e= nd-
=A0 =A0to-end configuration (connecting two MSRP over data channel
=A0 =A0endpoints), and a gateway configuration (connecting an MSRP over dat= a
=A0 =A0channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

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

--089e0160b6cea8abbf04e126e33b-- From richard.ejzak@alcatel-lucent.com Wed Jul 10 07:22: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 38F8421F99F4; Wed, 10 Jul 2013 07:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 fW+udQi9kY3M; Wed, 10 Jul 2013 07:22:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41011E8167; Wed, 10 Jul 2013 07:22:41 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6AEMc0q025991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 09:22:38 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6AEMbKv026861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 10:22:38 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 10:22:37 -0400 From: "Ejzak, Richard P (Richard)" To: Gavin Llewellyn Thread-Topic: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt Thread-Index: AQHOfWPFLqfwD9/ad0qtPZT+Eb2kHZld542g Date: Wed, 10 Jul 2013 14:22:36 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.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: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dispatch@ietf.org" , "mmusic@ietf.org WG" Subject: Re: [MMUSIC] [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:22:49 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gavin, Thanks for your support of our approach and for your comments. It's great = that you are planning an implementation along these lines. I am including mmusic on this distribution to not exclude anyone who may be= interested, but please limit the distribution to dispatch only for subsequ= ent emails in this thread. Regarding why we chose to create a new draft: Our approach was sufficiently= different from yours that we felt a separate draft was a better idea in th= e short term. We can merge when it's appropriate to do so. Even though we= have no significant difference of opinion regarding the SDP extensions nee= ded, we clearly have different views regarding the value of a DataChannel g= ateway. It would be good to hear other opinions on this matter, as you are= clearly heavily committed to your preference. Our preference for support of a DataChannel gateway model is based on the n= umerous advantages of DataChannels. Just a partial list: We have one trans= port mechanism for all cases; we don't have to offer two options or perform= fallback/retry procedures on failure of one transport option; we can easil= y multiplex all media and sub-protocols together; we can leverage the integ= rated browser handling of multiple flows of different priority; we have to = be able to interoperate with legacy tcp/tls endpoints anyway. We look forward to continuing the debate. BR, Richard From: Gavin Llewellyn [mailto:gavin.llewellyn@crocodilertc.net] Sent: Wednesday, July 10, 2013 6:51 AM To: Ejzak, Richard P (Richard) Cc: dispatch@ietf.org; mmusic@ietf.org WG Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-= over-webrtc-data-channels-00.txt As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for est= ablishment of MSRP sessions between WebRTC endpoints. The SDP enhancements= allowing re-use of the SCTP association is very much along the lines of wh= at we had in mind for the next version of our draft, but we have not had ti= me to complete it. We will likely be implementing this as a feature in our= WebRTC library in the near future, as the DataChannel implementations in b= rowsers mature (support SCTP, reliable delivery, binary data, etc). Having said that, it would have been appreciated if the authors had contact= ed Peter and/or myself to discuss the existing draft and its limitations - = we would have been happy to receive feedback and work together to find the = best solution going forward. I cannot see the value in introducing DataChannel gateways as a means to co= mmunicate with traditional TCP-based MSRP endpoints. I believe this is bet= ter catered for by the WebSocket-based solution, as described in draft-pd-d= ispatch-msrp-websocket, which already has client and server implementations= , and is currently in-use in a production environment. Given the (intentio= nal) similarities between the WebSocket and DataChannel APIs, it is not dif= ficult for the client application to support both transports. I would like= to see a clear justification for this aspect of the draft. One minor correction: the opening paragraph of section 5.2.3 appears to ref= erence the wrong SDP syntax for sub-protocol-specific attributes; I believe= it should reference the syntax for the new "wdcsa" attribute. Regards, Gavin Llewellyn -- Gavin Llewellyn Principal Design Engineer Crocodile RCS Ltd GPG key: 0xF8F6FFF2 On 9 July 2013 20:32, Ejzak, Richard P (Richard) > wrote: Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to = use DataChannel transport for MSRP. Our draft does not place restrictions = on the number of MSRP sessions that can be established within an SCTP assoc= iation and describes alternatives for using a gateway to interconnect to ex= isting MSRP endpoints. The SDP extensions described are applicable to othe= r potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, July 08, 2013 6:31 PM To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository. Filename: draft-marcon-msrp-over-webrtc-data-channels Revision: 00 Title: MSRP over WebRTC data channels Creation date: 2013-07-09 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-marcon-msrp-over= -webrtc-data-channels-00.txt Status: http://datatracker.ietf.org/doc/draft-marcon-msrp-over-web= rtc-data-channels Htmlized: http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-d= ata-channels-00 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the SDP offer/exchange to negotiate out-of-band the sub-protocol specific parameters. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF Secretariat _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gavin,

Thanks for your support o= f our approach and for your comments.  It’s great that you are p= lanning an implementation along these lines.

 <= /p>

I am including mmusic on = this distribution to not exclude anyone who may be interested, but please l= imit the distribution to dispatch only for subsequent emails in this thread.

 <= /p>

Regarding why we chose to= create a new draft: Our approach was sufficiently different from yours tha= t we felt a separate draft was a better idea in the short term.  We can merge when it’s appropriate to do so.  Even = though we have no significant difference of opinion regarding the SDP exten= sions needed, we clearly have different views regarding the value of a Data= Channel gateway.  It would be good to hear other opinions on this matter, as you are clearly heavily committed to your pref= erence.

 <= /p>

Our preference for suppor= t of a DataChannel gateway model is based on the numerous advantages of Dat= aChannels.  Just a partial list: We have one transport mechanism for all cases; we don’t have to offer two options or perform fallbac= k/retry procedures on failure of one transport option; we can easily multip= lex all media and sub-protocols together; we can leverage the integrated br= owser handling of multiple flows of different priority; we have to be able to interoperate with legacy tcp/tls endpoints= anyway.

 <= /p>

We look forward to contin= uing the debate.

 <= /p>

BR, Richard

 <= /p>

From: Gavin Ll= ewellyn [mailto:gavin.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM
To: Ejzak, Richard P (Richard)
Cc: dispatch@ietf.org; mmusic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

 

As a co-author of draft-pd-msrp-webr= tc-00, I support this new draft for establishment of MSRP sessions between = WebRTC endpoints.  The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for t= he next version of our draft, but we have not had time to complete it. &nbs= p;We will likely be implementing this as a feature in our WebRTC library in= the near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binar= y data, etc).

 

Having said that, it would have been appr= eciated if the authors had contacted Peter and/or myself to discuss the exi= sting draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forw= ard.

 

I cannot see the value in introducing Dat= aChannel gateways as a means to communicate with traditional TCP-based MSRP= endpoints.  I believe this is better catered for by the WebSocket-based solution, as described in draft-pd-dispatch-msrp-web= socket, which already has client and server implementations, and is current= ly in-use in a production environment.  Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficu= lt for the client application to support both transports.  I would lik= e to see a clear justification for this aspect of the draft.

 

One minor correction: the opening paragraph of section 5.2= .3 appears to reference the wrong SDP syntax for sub-protocol-specific attr= ibutes; I believe it should reference the syntax for the new "wdcsa" attribute.

 

Regards,

Gavin Llewellyn

 

--

Gavin Llewellyn

Principal Design Engineer

Crocodile RCS Ltd

GPG key: 0xF8F6FFF2

 

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <= ;rich= ard.ejzak@alcatel-lucent.com> wrote:

Please note our proposed alternative to draft-pd-msr= p-webrtc-00 for how to use DataChannel transport for MSRP.  Our draft = does not place restrictions on the number of MSRP sessions that can be esta= blished within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSR= P endpoints.  The SDP extensions described are applicable to other pot= ential DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename:        draft-marcon-msrp-over-webrtc-data-cha= nnels
Revision:        00
Title:           MSRP over WebRTC data channels Creation date:   2013-07-09
Group:           Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-chan= nels-00.txt
Status:          ht= tp://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized:        http://to= ols.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working g= roup is
   charged to provide protocols to support direct interactive ric= h
   communication using audio, video, and data between two peers' = web-
   browsers.  For the support of data communication, the RTC= Web working
   group has in particular defined the concept of bi-directional = data
   channels over SCTP, where each data channel might be used to    transport other protocols, called sub-protocols.  This do= cument
   specifies how the Message Session Relay Protocol (MSRP) can be=
   instantiated as a WebRTC data channel sub-protocol, using the = SDP
   offer/exchange to negotiate out-of-band the sub-protocol speci= fic
   parameters.  Two network configurations are documented: a= WebRTC end-
   to-end configuration (connecting two MSRP over data channel    endpoints), and a gateway configuration (connecting an MSRP ov= er data
   channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

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

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_-- From martin.thomson@gmail.com Wed Jul 10 09:50:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344A421F9F58 for ; Wed, 10 Jul 2013 09:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.131, 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 2qdZwHQdl0Oy for ; Wed, 10 Jul 2013 09:50:19 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC321F9F9E for ; Wed, 10 Jul 2013 09:50:19 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so6569803wib.0 for ; Wed, 10 Jul 2013 09:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tqrXuSd9iXB9N0vTorV516xPUTBOZL0y+h2bP1x2vVs=; b=R9OxCzUKIGTtdBmIGD6ceD+dtDDsS4ooFB857H0KOs3kVvrxIVCVAUIqW5jjW82tGn gfukWaB8zNZPJbKbboKh4a0RUwmt5UP3sF3Y7kV1UI5n1DSoO/P3p+mP7ELiU61YlHU9 ni+cVyLNpcbq2eWVgxuJkpwo2pFeXuSLcOjaSp83sFOxOjHNtrqyqtCRVAdGOjNnGs/c ZC0NjzMfYKAaiibb64sej7dTCmlM1vQN7+b74uso2nks714TXsPzZOLSXUpgbRHeDYGr RPCr+Aq9Vrl6T3422gFyylxN+0BIHjksdVxkpycCHn0uKIVYdgB+8GwArGsEpEmLp509 OdNA== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr18660829wjx.84.1373475018066; Wed, 10 Jul 2013 09:50:18 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 10 Jul 2013 09:50:18 -0700 (PDT) In-Reply-To: <51DCBFC2.9020006@jitsi.org> References: <51DC0595.4070203@jitsi.org> <51DCBFC2.9020006@jitsi.org> Date: Wed, 10 Jul 2013 09:50:18 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE and frozen candidates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:50:20 -0000 On 9 July 2013 18:58, Emil Ivov wrote: > OK. Do you mean something like 2. or do you have another mechanism in mind? I don't have any particular mechanism in mind, though 2 might be workable (I initially read "priority" there, which isn't quite right, I think that you mean something like "preference order", since it's the component ordering that would matter). From gunnar.hellstrom@omnitor.se Wed Jul 10 22: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 E099021F9DAF for ; Wed, 10 Jul 2013 22:35: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] 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 rMVhHjlOTPGm for ; Wed, 10 Jul 2013 22:35:00 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 53B1421F9D8B for ; Wed, 10 Jul 2013 22:34:59 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 11 Jul 2013 07:34:50 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 77C5B3A11F for ; Thu, 11 Jul 2013 07:34:50 +0200 (CEST) Message-ID: <51DE43FC.6080508@omnitor.se> Date: Thu, 11 Jul 2013 07:34:52 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> In-Reply-To: <51DCE7CB.7080205@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:35:06 -0000 On 2013-07-10 06:49, Christian Groves wrote: > I wouldn't have thought that it would be use case specific... i.e. i'd > only include my language when I called an emergency service. I would > think an endpoint would be configured with the information and then > provide it whenever I made a call. Is that the intent? > > Christian Yes, that is the intent. And for both relay service invocation and any other assisting service invocation, it is best for the user to dial the destination, and get the assisting service invoked by an indication like this in the call, rather than being forced to first call an assisting service and with them discuss who is the final destination of the call. The other party in the call may be another user, a call center, an emergency service or a conference bridge. Gunnar > > On 10/07/2013 9:23 AM, Gunnar Hellstrom wrote: >> On 2013-07-09 23:58, Randall Gellens wrote: >>> This is a different, and more complex, scenario than what this >>> proposal is trying to solve. This proposal is focused on simpler >>> cases where someone places an emergency call or calls a corporate >>> call center. Possibly this can be just a simple case of the more >>> complex cases? >> My view is that it is intended to also cover user-to-user cases, >> where preferences are compared and a relay service (or language >> interpreter) can be invoked to bridge language gaps. >> >> Gunnar >> >> >> _______________________________________________ >> 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 peter.dunkley@crocodilertc.net Wed Jul 10 07: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 E6BE521F99A5 for ; Wed, 10 Jul 2013 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 6aUFATleRsQl for ; Wed, 10 Jul 2013 07:57:43 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 382A521F9B57 for ; Wed, 10 Jul 2013 07:57:00 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so15564750iec.36 for ; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZLCeOweDxT4PiWc3mQeCxKrRW0Z8TcEQsbRTrYJxElA=; b=U6mkebSkBwPPlmhJ57Ah3U56BHB5M1eWigndUzZww75HBow+BcrpC+5O5FLcjG1aLJ sLhtDAVR+c2fM+3aGqyJOZpOEuoMqLH0NU+b4FTlF9HFyNCXxa4uH+5kE0iv+FdZD54t SMa2XL+NHoViKl0Y5raaWQdTdH2VijHYOHSDo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZLCeOweDxT4PiWc3mQeCxKrRW0Z8TcEQsbRTrYJxElA=; b=O4egs2O74Lbh96xs95/ntltT7gYXpqnMCJUH6rXNtXFDrK1O7kBFLpEugLfJZDQqHr BEiUoIS46NP6mgtLU7ibTuTbrKuI9CiP5LzGUNZhLHNP3TAU2vZOIRaaXgbvk16aGKIP dzHd1fK1vDshzGbN6X85gdNbAk2so6pLin3phI9fmj2MM3cTiFOJRX6nHl6wIdysTDS0 v9pDWS9IEocmYBgLW3aL3xv6yXITLY+Z2aE/nqSRkpX7MxECKWAOglud5UTxCtPWYR11 hIcAgMHZq78zTpLLhHTNnwq5w3KWt4U4zy3hFwTqEWA9ooo7pOG/2sOPWR+1QOFbyVcf hL3w== MIME-Version: 1.0 X-Received: by 10.50.18.5 with SMTP id s5mr12030291igd.6.1373468219635; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) Received: by 10.64.137.163 with HTTP; Wed, 10 Jul 2013 07:56:59 -0700 (PDT) X-Originating-IP: [90.152.0.102] In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Wed, 10 Jul 2013 15:56:59 +0100 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" , "mmusic@ietf.org WG" Content-Type: multipart/alternative; boundary=089e013cc1c4578b7304e1297d42 X-Gm-Message-State: ALoCoQmq0Wc3ECmq34WY9Y7hDgFU9o9lLI92+KFKn+r1TaTM+yYpycVzKyvXMh4mKFD0ztHMg4yl X-Mailman-Approved-At: Thu, 11 Jul 2013 02:37:25 -0700 Subject: Re: [MMUSIC] [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:57:49 -0000 --089e013cc1c4578b7304e1297d42 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, My preference for the WebSocket solution for client/server interaction stems simply from: 1) There are many MSRP use cases that are strictly client to/from server. WebSockets are a far simpler mechanism for these use cases, is far simpler to implement at both ends, and is arguably more efficient due to this simplicity. 2) There are many MSRP use cases that do not involve real-time media, and use of WebSockets enables these use cases to be satisfied with browsers (or other environments) that do not support WebRTC at this time (and some of these browsers/environments may never support WebRTC). I am not happy about requiring WebRTC support in a browser just for me to be able to use MSRP there. The requirements for peer-to-peer MSRP and client/server MSRP are quite different. Even when TCP/TLS is the transport these requirements are covered by two separate RFCs (which were developed and published in parallel). RFC 4976 adds additional MSRP requests and procedures that are simply not needed for peer-to-peer MSRP. I have no objection in principle to existence of a "gateway" device as you have described (although, for the reasons described above, I will continue to use WebSockets in my production system when client/server interaction is required), but to me it would make more sense to separate this function into another document that updates RFC 4976. When I started writing draft-pd-msrp-webrtc I envisaged this as simply an update to RFC 4975 to enable a new transport between MSRP peers - and I believe there is value in this simplicity. Regards, Peter On 10 July 2013 15:22, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Hi Gavin,**** > > Thanks for your support of our approach and for your comments. It=92s gr= eat > that you are planning an implementation along these lines.**** > > ** ** > > I am including mmusic on this distribution to not exclude anyone who may > be interested, but please limit the distribution to dispatch only for > subsequent emails in this thread.**** > > ** ** > > Regarding why we chose to create a new draft: Our approach was > sufficiently different from yours that we felt a separate draft was a > better idea in the short term. We can merge when it=92s appropriate to d= o > so. Even though we have no significant difference of opinion regarding t= he > SDP extensions needed, we clearly have different views regarding the valu= e > of a DataChannel gateway. It would be good to hear other opinions on thi= s > matter, as you are clearly heavily committed to your preference.**** > > ** ** > > Our preference for support of a DataChannel gateway model is based on the > numerous advantages of DataChannels. Just a partial list: We have one > transport mechanism for all cases; we don=92t have to offer two options o= r > perform fallback/retry procedures on failure of one transport option; we > can easily multiplex all media and sub-protocols together; we can leverag= e > the integrated browser handling of multiple flows of different priority; = we > have to be able to interoperate with legacy tcp/tls endpoints anyway. ***= * > > ** ** > > We look forward to continuing the debate.**** > > ** ** > > BR, Richard**** > > ** ** > > *From:* Gavin Llewellyn [mailto:gavin.llewellyn@crocodilertc.net] > *Sent:* Wednesday, July 10, 2013 6:51 AM > > *To:* Ejzak, Richard P (Richard) > *Cc:* dispatch@ietf.org; mmusic@ietf.org WG > *Subject:* Re: [dispatch] FW: New Version Notification for > draft-marcon-msrp-over-webrtc-data-channels-00.txt**** > > ** ** > > As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for > establishment of MSRP sessions between WebRTC endpoints. The SDP > enhancements allowing re-use of the SCTP association is very much along t= he > lines of what we had in mind for the next version of our draft, but we ha= ve > not had time to complete it. We will likely be implementing this as a > feature in our WebRTC library in the near future, as the DataChannel > implementations in browsers mature (support SCTP, reliable delivery, bina= ry > data, etc).**** > > ** ** > > Having said that, it would have been appreciated if the authors had > contacted Peter and/or myself to discuss the existing draft and its > limitations - we would have been happy to receive feedback and work > together to find the best solution going forward.**** > > ** ** > > I cannot see the value in introducing DataChannel gateways as a means to > communicate with traditional TCP-based MSRP endpoints. I believe this is > better catered for by the WebSocket-based solution, as described in draft= -pd-dispatch-msrp-websocket, > which already has client and server implementations, and is currently > in-use in a production environment. Given the (intentional) similarities > between the WebSocket and DataChannel APIs, it is not difficult for the > client application to support both transports. I would like to see a cle= ar > justification for this aspect of the draft.**** > > ** ** > > One minor correction: the opening paragraph of section 5.2.3 appears to > reference the wrong SDP syntax for sub-protocol-specific attributes; I > believe it should reference the syntax for the new "wdcsa" attribute.**** > > ** ** > > Regards,**** > > Gavin Llewellyn**** > > ** ** > > --**** > > Gavin Llewellyn**** > > Principal Design Engineer**** > > Crocodile RCS Ltd**** > > GPG key: 0xF8F6FFF2**** > > ** ** > > On 9 July 2013 20:32, Ejzak, Richard P (Richard) < > richard.ejzak@alcatel-lucent.com> wrote:**** > > Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how t= o > use DataChannel transport for MSRP. Our draft does not place restriction= s > on the number of MSRP sessions that can be established within an SCTP > association and describes alternatives for using a gateway to interconnec= t > to existing MSRP endpoints. The SDP extensions described are applicable = to > other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc. > > Richard > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 08, 2013 6:31 PM > To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME) > Subject: New Version Notification for > draft-marcon-msrp-over-webrtc-data-channels-00.txt > > > A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt > has been successfully submitted by Jerome Marcon and posted to the IETF > repository. > > Filename: draft-marcon-msrp-over-webrtc-data-channels > Revision: 00 > Title: MSRP over WebRTC data channels > Creation date: 2013-07-09 > Group: Individual Submission > Number of pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt > Status: > http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channe= ls > Htmlized: > http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00 > > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. This document > specifies how the Message Session Relay Protocol (MSRP) can be > instantiated as a WebRTC data channel sub-protocol, using the SDP > offer/exchange to negotiate out-of-band the sub-protocol specific > parameters. Two network configurations are documented: a WebRTC end- > to-end configuration (connecting two MSRP over data channel > endpoints), and a gateway configuration (connecting an MSRP over data > channel endpoint with an MSRP over TCP endpoint). > > > > > The IETF Secretariat > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch**** > > ** ** > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --089e013cc1c4578b7304e1297d42 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,

My preference for the WebSocket solution f= or client/server interaction stems simply from:
1) There are many MSRP = use cases that are strictly client to/from server. WebSockets are a far sim= pler mechanism for these use cases, is far simpler to implement at both end= s, and is arguably more efficient due to this simplicity.
2) There are many MSRP use cases that do not involve real-time media, = and use of WebSockets enables these use cases to be satisfied with browsers= (or other environments) that do not support WebRTC at this time (and some = of these browsers/environments may never support WebRTC). =A0I am not happy= about requiring WebRTC support in a browser just for me to be able to use = MSRP there.

The requirements for peer-to-peer MSRP and client/serve= r MSRP are quite different. =A0Even when TCP/TLS is the transport these req= uirements are covered by two separate RFCs (which were developed and publis= hed in parallel). =A0RFC 4976 adds additional MSRP requests and procedures = that are simply not needed for peer-to-peer MSRP.

I have no objection in principle to existence of a &quo= t;gateway" device as you have described (although, for the reasons des= cribed above, I will continue to use WebSockets in my production system whe= n client/server interaction is required), but to me it would make more sens= e to separate this function into another document that updates RFC 4976.

When I started writing draft-pd-msrp-webrtc I envisaged= this as simply an update to RFC 4975 to enable a new transport between MSR= P peers - and I believe there is value in this simplicity.

Regard= s,

Peter


On 10 July 20= 13 15:22, Ejzak, Richard P (Richard) <richard.ejzak@alcatel= -lucent.com> wrote:

Hi Gavin,

Thanks for your support o= f our approach and for your comments.=A0 It=92s great that you are planning= an implementation along these lines.

=A0<= /p>

I am including mmusic on = this distribution to not exclude anyone who may be interested, but please l= imit the distribution to dispatch only for subsequent emails in this thread.

=A0<= /p>

Regarding why we chose to= create a new draft: Our approach was sufficiently different from yours tha= t we felt a separate draft was a better idea in the short term.=A0 We can merge when it=92s appropriate to do so.=A0 Even though we = have no significant difference of opinion regarding the SDP extensions need= ed, we clearly have different views regarding the value of a DataChannel ga= teway.=A0 It would be good to hear other opinions on this matter, as you are clearly heavily committed to your pref= erence.

=A0<= /p>

Our preference for suppor= t of a DataChannel gateway model is based on the numerous advantages of Dat= aChannels.=A0 Just a partial list: We have one transport mechanism for all cases; we don=92t have to offer two options or perform fallback/re= try procedures on failure of one transport option; we can easily multiplex = all media and sub-protocols together; we can leverage the integrated browse= r handling of multiple flows of different priority; we have to be able to interoperate with legacy tcp/tls endpoints= anyway.

=A0<= /p>

We look forward to contin= uing the debate.

=A0<= /p>

BR, Richard=

=A0<= /p>

From: Gavin Ll= ewellyn [mailto:gavin.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM

<= br> To: Ejzak, Richard P (Richard)
Cc: dis= patch@ietf.org; mm= usic@ietf.org WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marco= n-msrp-over-webrtc-data-channels-00.txt

=A0

As a co-author of=A0draft-pd-msrp-webrtc-= 00, I support this new draft for establishment of MSRP sessions between Web= RTC endpoints. =A0The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for t= he next version of our draft, but we have not had time to complete it. =A0W= e will likely be implementing this as a feature in our WebRTC library in th= e near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binar= y data, etc).

=A0

Having said that, it would have been appr= eciated if the authors had contacted Peter and/or myself to discuss the exi= sting draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forw= ard.

=A0

I cannot see the value in introducing Dat= aChannel gateways as a means to communicate with traditional TCP-based MSRP= endpoints. =A0I believe this is better catered for by the WebSocket-based solution, as described in=A0draft-pd-dispatch-msrp-websoc= ket, which already has client and server implementations, and is currently = in-use in a production environment. =A0Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficu= lt for the client application to support both transports. =A0I would like t= o see a clear justification for this aspect of the draft.<= /u>

=A0

One minor correction: the opening paragraph of section 5.2= .3 appears to reference the wrong SDP syntax for sub-protocol-specific attr= ibutes; I believe it should reference the syntax for the new "wdcsa" attribute.

=A0

Regards,

Gavin Llewellyn

=A0

--

Gavin Llewellyn

Principal Design Engineer

Crocodile RCS Ltd

GPG key: 0xF8F6FFF2

=A0

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <= ;rich= ard.ejzak@alcatel-lucent.com> wrote:

Please note our proposed alternative to draft-pd-msr= p-webrtc-00 for how to use DataChannel transport for MSRP. =A0Our draft doe= s not place restrictions on the number of MSRP sessions that can be establi= shed within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSR= P endpoints. =A0The SDP extensions described are applicable to other potent= ial DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-ch= annels-00.txt


A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt has been successfully submitted by Jerome Marcon and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-marcon-msrp-over-webrtc-data-channels
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 MSRP over WebRTC data channels
Creation date: =A0 2013-07-09
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-chan= nels-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-marcon-msrp-over-webrtc-data-channels-00


Abstract:
=A0 =A0The Real-Time Communication in WEB-browsers (RTCWeb) working group i= s
=A0 =A0charged to provide protocols to support direct interactive rich
=A0 =A0communication using audio, video, and data between two peers' we= b-
=A0 =A0browsers. =A0For the support of data communication, the RTCWeb worki= ng
=A0 =A0group has in particular defined the concept of bi-directional data =A0 =A0channels over SCTP, where each data channel might be used to
=A0 =A0transport other protocols, called sub-protocols. =A0This document =A0 =A0specifies how the Message Session Relay Protocol (MSRP) can be
=A0 =A0instantiated as a WebRTC data channel sub-protocol, using the SDP =A0 =A0offer/exchange to negotiate out-of-band the sub-protocol specific =A0 =A0parameters. =A0Two network configurations are documented: a WebRTC e= nd-
=A0 =A0to-end configuration (connecting two MSRP over data channel
=A0 =A0endpoints), and a gateway configuration (connecting an MSRP over dat= a
=A0 =A0channel endpoint with an MSRP over TCP endpoint).




The IETF Secretariat

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

=A0


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




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--089e013cc1c4578b7304e1297d42-- From tireddy@cisco.com Thu Jul 11 05:43: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 3713011E8152 for ; Thu, 11 Jul 2013 05:43:02 -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 jgWHv+6sdCD1 for ; Thu, 11 Jul 2013 05:42: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 1DA5711E8141 for ; Thu, 11 Jul 2013 05:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1373546577; x=1374756177; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=PkfCoDvZoqwta61fOOl9mqmhf2082dFdd2c7Avj/cv8=; b=e4OyD62cgvqWnoEyMJZp3+cNNfhUhUqQVOIZ2j37N52KsADGAQ3wDN5o Jlx5GvK7ADMLlpbkCL+YS70gOqRPpUBrInkGehlWhghuvTUHKFgOO8G+b 50Y92D5gZUfE25kWwSRcg+nPq3SzyX2hI9PfiHrNrnkj9gVWBIpsa8LMW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJid3lGtJV2Y/2dsb2JhbABagwkyRwaDBr5KF28WdIIjAQEBBCMREzACDAYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEDgUIAYgGBwWldoN/jT+BJo4KMQ2CUDNsA5kDkCGDEYIo X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="scan'208";a="233526790" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2013 12:42:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6BCguax027143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jul 2013 12:42:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 07:42:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-01.txt Thread-Index: AQHOfjKbGgv5+V+lB0+HbaTG3/5LoJlfaaLA Date: Thu, 11 Jul 2013 12:42:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B976AC@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Dan Wing \(dwing\)" Subject: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:43:02 -0000 VGhpcyBkcmFmdCBwcm9wb3NlcyBIYXBweSBleWViYWxsIGV4dGVuc2lvbiBmb3IgSUNFIHRoYXQg bWFrZXMgdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgbW9yZSByZXNwb25zaXZlIHRvIGZhaWx1cmVz IG9mIGFuIGFkZHJlc3MgZmFtaWx5IGJ5IHJlb3JkZXJpbmcNCnRoZSBjYW5kaWRhdGUgcGFpcnMg c3VjaCB0aGF0IElQdjYgYW5kIElQdjQgY2FuZGlkYXRlcyBnZXQgYSBmYWlyIGNoYW5jZSBkdXJp bmcgY29ubmVjdGl2aXR5IGNoZWNrcy4gQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxj b21lLg0KDQpDaGVlcnMsDQpBdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDExLCAyMDEzIDY6MDIgUE0NClRvOiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgRGFu IFdpbmcgKGR3aW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1yZWRkeS1tbXVzaWMtaWNlLWhhcHB5LWV5ZWJhbGxzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1yZWRkeS1tbXVzaWMtaWNlLWhhcHB5LWV5ZWJhbGxzLTAxLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1yZWRk eS1tbXVzaWMtaWNlLWhhcHB5LWV5ZWJhbGxzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBIYXBw eSBFeWViYWxscyBFeHRlbnNpb24gZm9yIElDRQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMTEN Ckdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA4DQpVUkw6 ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJl ZGR5LW1tdXNpYy1pY2UtaGFwcHktZXllYmFsbHMtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktbW11c2ljLWljZS1oYXBw eS1leWViYWxscw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1yZWRkeS1tbXVzaWMtaWNlLWhhcHB5LWV5ZWJhbGxzLTAxDQpEaWZmOiAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJlZGR5LW1tdXNpYy1pY2Ut aGFwcHktZXllYmFsbHMtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmll cyByZXF1aXJlbWVudHMgZm9yIGFsZ29yaXRobXMgdGhhdCBtYWtlIElDRQ0KICAgY29ubmVjdGl2 aXR5IGNoZWNrcyBtb3JlIHJlc3BvbnNpdmUgYnkgcmVkdWNpbmcgZGVsYXlzIGluIGR1YWwtc3Rh Y2sNCiAgIGhvc3QgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3Mgd2hlbiB0aGVyZSBpcyBhIHBhdGgg ZmFpbHVyZSBmb3IgdGhlDQogICBhZGRyZXNzIGZhbWlseSBwcmVmZXJyZWQgYnkgdGhlIGFwcGxp Y2F0aW9uIG9yIGJ5IHRoZSBvcGVyYXRpbmcNCiAgIHN5c3RlbS4gIEFzIElQdjYgaXMgdXN1YWxs eSBwcmVmZXJyZWQsIHRoZSBwcm9jZWR1cmVzIGluIHRoaXMNCiAgIGRvY3VtZW50IGhlbHBzIGF2 b2lkIHVzZXItbm90aWNlYWJsZSBkZWxheXMgd2hlbiB0aGUgSVB2NiBwYXRoIGlzDQogICBicm9r ZW4gb3IgZXhjZXNzaXZlbHkgc2xvdy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From internet-drafts@ietf.org Thu Jul 11 07:01: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 5538C21F9EE1; Thu, 11 Jul 2013 07:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 MwJOqA7b+IKw; Thu, 11 Jul 2013 07:01:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E389B21F9A7A; Thu, 11 Jul 2013 07:01:07 -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.51.p2 Message-ID: <20130711140107.15801.43382.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 07:01:07 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-duplication-grouping-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:01:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Duplication Grouping Semantics in the Session Descriptio= n Protocol Author(s) : Ali Begen Yiqun Cai Heidi Ou Filename : draft-ietf-mmusic-duplication-grouping-03.txt Pages : 9 Date : 2013-07-11 Abstract: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-duplication-grouping-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu Jul 11 11:36: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 A51D221F9D9D for ; Thu, 11 Jul 2013 11:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=0.290, 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 MiR7OI5ILj8p for ; Thu, 11 Jul 2013 11:36:20 -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 D5D7F21F9D39 for ; Thu, 11 Jul 2013 11:36:19 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id z2w81l0090vyq2s5E6cJRb; Thu, 11 Jul 2013 18:36:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id z6cJ1l00q3ZTu2S3R6cJYp; Thu, 11 Jul 2013 18:36:18 +0000 Message-ID: <51DEFB22.4090802@alum.mit.edu> Date: Thu, 11 Jul 2013 14:36:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51DE43FC.6080508@omnitor.se> In-Reply-To: <51DE43FC.6080508@omnitor.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=1373567779; bh=Vm8pLnqqAhFQro5zj2xehagtAMOKFDnvOvbHOsisk5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QNe+ruI/CpxTY8iCFmBWTSwBEEwtVurvNWa13O3cRE2XpNxgzjx3GD5OQqQJZjh75 XUqL0A0ZLeqD5J1ZDXqNttWLdQ4e7Alafz9XYud9u3yIJykHSWVBoVfjGfbWqEzC0r J1AxSuTUWhyLkqwWAObECDEBgUe85zusEoHTh1PFSvZW8sf9cznd3ddV172+Dd9MbI Bn8N08xAKTpqyxo/64ukgxCsSfEO8qLomKXi4wWnGOBYc1NYq+G0AqwaRenvOiPmZ/ odeTrVD1VoELZG8Z713JFWg5kmWHqW3HJiHAG3SLkaerzsjReGgxZABsyRCz4qsywT YQPlQ797Br0RA== Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 18:36:24 -0000 On 7/11/13 1:34 AM, Gunnar Hellstrom wrote: > On 2013-07-10 06:49, Christian Groves wrote: >> I wouldn't have thought that it would be use case specific... i.e. i'd >> only include my language when I called an emergency service. I would >> think an endpoint would be configured with the information and then >> provide it whenever I made a call. Is that the intent? >> >> Christian > Yes, that is the intent. > > And for both relay service invocation and any other assisting service > invocation, it is best for the user to dial the destination, and get the > assisting service invoked by an indication like this in the call, rather > than being forced to first call an assisting service and with them > discuss who is the final destination of the call. Viewed this way, it is similar to recognizing the need for, and recruiting, a transcoder. (See RFCs 5369 & 5370.) Thanks, Paul > The other party in the call may be another user, a call center, an > emergency service or a conference bridge. > > Gunnar > >> >> On 10/07/2013 9:23 AM, Gunnar Hellstrom wrote: >>> On 2013-07-09 23:58, Randall Gellens wrote: >>>> This is a different, and more complex, scenario than what this >>>> proposal is trying to solve. This proposal is focused on simpler >>>> cases where someone places an emergency call or calls a corporate >>>> call center. Possibly this can be just a simple case of the more >>>> complex cases? >>> My view is that it is intended to also cover user-to-user cases, >>> where preferences are compared and a relay service (or language >>> interpreter) can be invoked to bridge language gaps. >>> >>> Gunnar >>> >>> >>> _______________________________________________ >>> 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 gunnar.hellstrom@omnitor.se Thu Jul 11 12:28: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 EBC6021F9E72 for ; Thu, 11 Jul 2013 12:28:07 -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 ggvqNQpgi5Ck for ; Thu, 11 Jul 2013 12:28:01 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 3D99B21F9EDC for ; Thu, 11 Jul 2013 12:28:00 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 11 Jul 2013 21:27:52 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id E688C3A160 for ; Thu, 11 Jul 2013 21:27:51 +0200 (CEST) Message-ID: <51DF0739.7040107@omnitor.se> Date: Thu, 11 Jul 2013 21:27:53 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51DE43FC.6080508@omnitor.se> <51DEFB22.4090802@alum.mit.edu> In-Reply-To: <51DEFB22.4090802@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 19:28:08 -0000 On 2013-07-11 20:36, Paul Kyzivat wrote: >> >> >> And for both relay service invocation and any other assisting service >> invocation, it is best for the user to dial the destination, and get the >> assisting service invoked by an indication like this in the call, rather >> than being forced to first call an assisting service and with them >> discuss who is the final destination of the call. > > Viewed this way, it is similar to recognizing the need for, and > recruiting, a transcoder. (See RFCs 5369 & 5370.) Yes, that is a useful model. Especially the bridge, because there you can let all three parties take part of common media when that makes sense. /Gunnar From emil@sip-communicator.org Fri Jul 12 17:15: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 F1DC811E8146 for ; Fri, 12 Jul 2013 17:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 07hhB37ZwlHP for ; Fri, 12 Jul 2013 17:15:36 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8C11E8144 for ; Fri, 12 Jul 2013 17:15:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so1221517wiv.7 for ; Fri, 12 Jul 2013 17:15:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=H/8NK5s+x241j2TOd6Cr1Tn+6JKnRPOHCPAqVb2qbNY=; b=NBJ5ZiGBWYDpv6vH5oMrPgn4rep/blz2ng9dKpRpZfjlYY3S/QrvpSCu9TvH6RNNq/ th9WA3TcptD9cNk1ceXmlXXXl6aXN3Ls4hAB7Z8UxM2cJpHjUlsm1uqa9qMleZScX03/ rLGo4+6yMXDM3PmBvRdYy6+zubOb+OB40TzflXUyXR6vU72sFSdO48AoE8VV1+lqNBfG 9KBjkoDIbhXDUCVhcJeUn8zVA3U0Sp7MjM2/UD9to27VWOaH69aV7reYALDHL+K8zz1d R7ksup6q1m3OVAMeDJjqf6K97sZ6+2aHGQvIl4idSR9FZqOQaJ3DVuCOW8bRoptcQoNB PjMQ== X-Received: by 10.180.160.144 with SMTP id xk16mr2930866wib.62.1373674534240; Fri, 12 Jul 2013 17:15:34 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:38e6:8f85:a1df:fc5b]) by mx.google.com with ESMTPSA id f8sm5863886wiv.0.2013.07.12.17.15.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 17:15:32 -0700 (PDT) Message-ID: <51E09C1E.4010701@jitsi.org> Date: Sat, 13 Jul 2013 02:15:26 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <51DC0595.4070203@jitsi.org> <51DCBFC2.9020006@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnt9i1TH/qXlWIGf2BLtGotZorKz3/6Kyu9ajB1CbiewuZ5mSfT8DhGJB3P2n0ZW0JWqQLb Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE and frozen candidates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 00:15:41 -0000 Hey Martin, all, On 10.07.13, 18:50, Martin Thomson wrote: > On 9 July 2013 18:58, Emil Ivov wrote: >> OK. Do you mean something like 2. or do you have another mechanism in mind? > > I don't have any particular mechanism in mind, though 2 might be > workable (I initially read "priority" there, which isn't quite right, > I think that you mean something like "preference order", since it's > the component ordering that would matter). Yes and the idea was that component ordering is generally the only thing that would influence "priority" within a single foundation. That said, I agree there's no reason not to say this directly. So to summarize. The algorithm would look like this: We start by unfreezing the first available pair for a foundation. Any new pairs would be: a) automatically unfrozen if they belong to a component that precedes that of an unfrozen pair. b) automatically unfrozen if other checks in that foundation already succeeded c) kept frozen and then handled by regular 5245 unfreezing if they belong to components that come after the last currently unfrozen but not yet completed check d) kept frozen if checks for unfrozen pairs in this same foundation have already failed. Obviously "d" is kind of murky. We need it in order for the freezing algorithm to have any sense but it could still lead to race conditions and premature failures. So, at least now this doesn't seem like a great way to go forward. Therefore, it seems to me that the only way to keep "freezing" is to mandate that candidates be trickled by component order. This way we would be able to pretty much reuse the vanilla ICE algorithm. Thoughts? Emil -- https://jitsi.org From randy@qti.qualcomm.com Sat Jul 13 01: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 583DF11E81A2 for ; Sat, 13 Jul 2013 01:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 0uKwIoo72Vop for ; Sat, 13 Jul 2013 01:07:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC311E819E for ; Sat, 13 Jul 2013 01:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373702865; x=1405238865; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=8MfbV4tmC0xDh29+kSiytAMTU4PCw23ZGPkZVjpzFEI=; b=iz55zdqThVzi6FmxzD8/BP88ndjU0Oe/7MuSsEF4AkCX2AI+fEmLNlBv 2A8q0OW5yOv6SfUok0T/dxV4iIxn3Iwxlp0aKYbwcNSayjKF/w5hrSWm3 y+AKS3sWtbRlZWiOtPItVyeGWH9kLL7AvvyvSpgYtenK6jGVCoC3N4xJO A=; X-IronPort-AV: E=Sophos;i="4.89,658,1367996400"; d="scan'208";a="47326688" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 13 Jul 2013 01:07:45 -0700 X-IronPort-AV: E=Sophos;i="4.89,657,1367996400"; d="scan'208";a="514026209" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Jul 2013 01:07:45 -0700 Received: from [10.121.65.51] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 13 Jul 2013 01:07:44 -0700 Message-ID: In-Reply-To: <51DCE7CB.7080205@nteczone.com> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Sat, 13 Jul 2013 01:07:40 -0700 To: Christian Groves , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 08:07:53 -0000 At 2:49 PM +1000 7/10/13, Christian Groves wrote: > I wouldn't have thought that it would be use case specific... i.e. > i'd only include my language when I called an emergency service. I > would think an endpoint would be configured with the information > and then provide it whenever I made a call. Is that the intent? I expect so, but then, I also didn't expect it to be used much in the person-to-person case since usually language is implied by context when calling an individual. I expect it to be used when a person is calling an call center (corporate or emergency). To put it another way, I expect a personal client to always set language on outbound calls, but in most cases to ignore it on inbound calls. I'd expect a corporate call center, as well as emergency call handling facilities, to pay attention. I should make this more clear in the draft. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The average man does not know what to do with his life, yet wants another one which will last forever. --Anatole France From gunnar.hellstrom@omnitor.se Sat Jul 13 11:04: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 3E0C421F9D4B for ; Sat, 13 Jul 2013 11:04:55 -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 ViPp6ooIWW2P for ; Sat, 13 Jul 2013 11:04:49 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 7187621F9D75 for ; Sat, 13 Jul 2013 11:04:44 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 13 Jul 2013 20:04:30 +0200 (CEST) Received: from [192.168.43.175] (109.58.149.81.bredband.tre.se [109.58.149.81]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 599953A10C for ; Sat, 13 Jul 2013 20:04:30 +0200 (CEST) Message-ID: <51E196B0.5080406@omnitor.se> Date: Sat, 13 Jul 2013 20:04:32 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 18:04:55 -0000 On 2013-07-13 10:07, Randall Gellens wrote: > At 2:49 PM +1000 7/10/13, Christian Groves wrote: > >> I wouldn't have thought that it would be use case specific... i.e. >> i'd only include my language when I called an emergency service. I >> would think an endpoint would be configured with the information and >> then provide it whenever I made a call. Is that the intent? > > I expect so, but then, I also didn't expect it to be used much in the > person-to-person case since usually language is implied by context > when calling an individual. I expect it to be used when a person is > calling an call center (corporate or emergency). To put it another > way, I expect a personal client to always set language on outbound > calls, but in most cases to ignore it on inbound calls. I'd expect a > corporate call center, as well as emergency call handling facilities, > to pay attention. I should make this more clear in the draft. > I expect the setting to be retrieved from a personal profile (likely but not necessarily stored in connection with other user information and account information) and used in every call. /Gunnar From rg+ietf@qualcomm.com Sun Jul 14 02:06: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 7A02C21F9AC4 for ; Sun, 14 Jul 2013 02:06:13 -0700 (PDT) X-Quarantine-ID: <15ap2qUVXgKB> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 15ap2qUVXgKB for ; Sun, 14 Jul 2013 02:06:08 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9977B21F9AAF for ; Sun, 14 Jul 2013 02:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1373792768; x=1405328768; h=message-id:x-mailer:date:to:from:subject:content-type; bh=K0BGH1nxZVrRKphH+yU/ulRL/Osvh+/JHnOy3BqJr7k=; b=JizsV33zN7WWwYKFoqpD566LCzjo4kgq7iVlzInpLolTiSH43vvmOz5m IKiRH2UgbABmSZmUm8vM6u46Nxndci0vGuPIVpNOKsyQG4GD8IaI+mp0D K/+q86xY26JOpJoOPV4NiRrY7ssNkQEXJ3eX9JgX9DAY3Ec/phCL09LK7 8=; X-IronPort-AV: E=Sophos;i="4.89,662,1367996400"; d="scan'208";a="47475015" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 14 Jul 2013 02:06:08 -0700 X-IronPort-AV: E=Sophos;i="4.89,662,1367996400"; d="scan'208";a="504608647" Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2013 02:06:08 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r6E967PW022862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 14 Jul 2013 02:06:08 -0700 X-IronPort-AV: E=Sophos;i="4.89,662,1367996400"; d="scan'208";a="479456407" Received: from unknown (HELO [10.121.65.183]) ([10.64.209.88]) by Ironmsg04-L.qualcomm.com with ESMTP; 14 Jul 2013 02:06:06 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Sun, 14 Jul 2013 02:05:57 -0700 To: mmusic@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Subject: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 09:06:13 -0000 Hi all, I've tweaked the human language draft: o Relaxed language on setting -send and -receive to same values; added text on leaving on empty to indicate asymmetric usage. o Added text that clients on behalf of end users are expected to set the attributes on outgoing calls and ignore on incoming calls while systems on behalf of call centers and PSAPs are expected to take the attributes into account when processing incoming calls. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The mind of a bigot is like the pupil of the eye. The more light you shine on it, the more it contracts. --Oliver Wendell Holmes, Jr. From internet-drafts@ietf.org Sun Jul 14 14:28:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B2321F9AE6; Sun, 14 Jul 2013 14:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 qY+RbBjxcXT2; Sun, 14 Jul 2013 14:28:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1A721F8FFA; Sun, 14 Jul 2013 14:28:36 -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.51.p2 Message-ID: <20130714212836.15303.98856.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 14:28:36 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-04.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: Sun, 14 Jul 2013 21:28:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass' At= tribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-04.txt Pages : 28 Date : 2013-07-14 Abstract: This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-traffic-class-for-sdp-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmpolk@cisco.com Sun Jul 14 14:43: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 4918F21F93DB for ; Sun, 14 Jul 2013 14:43:01 -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 JAEu2sLJVk6l for ; Sun, 14 Jul 2013 14:42:56 -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 CB47E21F9BE5 for ; Sun, 14 Jul 2013 14:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1471; q=dns/txt; s=iport; t=1373838176; x=1375047776; h=message-id:date:to:from:subject:cc:mime-version; bh=xWTrjRbi0WsPsMyg1GgdQznJOY4ZhhHMmihtLxF0RWQ=; b=YSe5BGNGa2Q2a+b8k8TV2DQlz+pBhMSehuyjthhE/ciB4ywYt0QTGltw KNJiBvQBdKjUGGcMssVGLQ5E8IJogNYoydKWHiWWz1mAHSXx32B2LsIp6 7ivxrkIrB8X4/Ye7B1bQ0ScZNxuv1HhI55vM7jDI5ExDSH6nWb9KY0qRi 8=; X-IronPort-AV: E=Sophos;i="4.89,665,1367971200"; d="scan'208";a="234711882" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jul 2013 21:42:56 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6ELgu58005670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jul 2013 21:42:56 GMT Message-Id: <201307142142.r6ELgu58005670@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Jul 2013 16:42:55 -0500 To: mmusic From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "Subha Dhesikan \(sdhesika\)" Subject: [MMUSIC] Updated the draft-ietf-mmusic-traffic-class-for-sdp draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 21:43:01 -0000 MMUSIC I have updated the trafficclass label attribute draft per the WG's feedback out of the Orlando meeting. I don't believe there is anything controversial remaining in this draft in its present state, and I consider the draft done - barring additional feedback. James ++++++++++ A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass' Attribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-04.txt Pages : 28 Date : 2013-07-14 Abstract: This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-traffic-class-for-sdp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gunnar.hellstrom@omnitor.se Sun Jul 14 15:15:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A430621F9BD8 for ; Sun, 14 Jul 2013 15:15:26 -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 jUDyjd8Xte9T for ; Sun, 14 Jul 2013 15:15:20 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 50DC121F9C32 for ; Sun, 14 Jul 2013 15:15:10 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 15 Jul 2013 00:14:31 +0200 (CEST) Received: from [192.168.43.175] (109.58.145.97.bredband.tre.se [109.58.145.97]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id E30663A188 for ; Mon, 15 Jul 2013 00:14:30 +0200 (CEST) Message-ID: <51E322C9.4040002@omnitor.se> Date: Mon, 15 Jul 2013 00:14:33 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060203030902050504080103" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 22:15:26 -0000 This is a multi-part message in MIME format. --------------060203030902050504080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Randall, Yes, version 01 is a step forward. Comments: 1. In 7.1 you now say: When placing an emergency call, and in any other case where the language cannot be assumed from context, each media stream in an offer SHOULD specify one or both 'humintlang-send' and 'humintlang- recv' attributes (to avoid ambiguity). This might be a good advice. But to what extent SHOULD it be followed? Some media might be included in SDP without the user having any interest of using it for language communication. Video may be included without the person really preferring it for spoken language understanding enhancement but just for pleasure or seeing the scene of the other user. Do you mean that such cases should also be specified with humintlang but with empty attributes? As a clear indication that the user is not interested in using that medium for language transfer. That could make sense. That is different from not providing any humintlang at all, that should be understood as undefined language preferences. But there are media streams specified by SDP where a language preference specification does not make sense. There are many application and message media specifications that are not used for any human language communication. I think for example that there are media specifications for camera control. Is the SHOULD a sufficient weakening of the requirement, so that the reader can skip using humintlang for media where it does not make sense? If not, expand "each media stream" to: "each media stream in which human language communication might occur". 2. You have also introduced this paragraph in 7.1: " Clients acting on behalf of end users are expected to set one or both 'humintlang-send' and 'humintlang-recv' attributes on each media stream in an offer when placing an outgoing session but ignore the attributes when receiving incoming calls. Systems acting on behalf of call centers and PSAPs are expected to take into account the values when processing inbound calls. " What is the thought behind this? I see the humintlang specification equally valuable in outgoing as incoming calls, and for end-users as well as call-centers and PSAPs. If a user gets an incoming call, with humintlang specifications, it can compare with its own profile and decide to invoke a relay service or interpreter servicde to cover some differences in language preferences, or just prepare for what media, modalities and languages to use in the call.. I do not see the background for this paragraph, and think it will be better to delete it. 3. Absolute preference is still needed. I described earlier the need for an absolute preference indication. But I did not provide any coding proposal. I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there. Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality and a "-" a non-preferred, but possible language and modality. ( needs to be checked against syntax of language tags.) Regards Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-07-14 11:05, Randall Gellens wrote: > Hi all, > > I've tweaked the human language draft: > > o Relaxed language on setting -send and -receive to same values; > added text on leaving on empty to indicate asymmetric usage. > > o Added text that clients on behalf of end users are expected to set > the attributes on outgoing calls and ignore on incoming calls > while systems on behalf of call centers and PSAPs are expected to > take the attributes into account when processing incoming calls. > --------------060203030902050504080103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Randall,

Yes, version 01 is a step forward.


Comments:
1. In 7.1 you now say:
When placing an emergency call, and in any other case where the
   language cannot be assumed from context, each media stream in an
   offer SHOULD specify one or both 'humintlang-send' and 'humintlang-
   recv' attributes (to avoid ambiguity).

This might be a good advice. But to what extent SHOULD it be followed?

Some media might be included in SDP without the user having any interest of using it for language communication.
Video may be included without the person really preferring it for spoken language understanding enhancement but just for pleasure or seeing the scene of the other user.

Do you mean that such cases should also be specified with humintlang but with empty attributes?
As a clear indication that the user is not interested in using that medium for language transfer.
That could make sense. That is different from not providing any humintlang at all, that should be understood as undefined language preferences.


But there are media streams specified by SDP where a language preference specification does not make sense. There are many application and message media specifications that are not used for any human language communication. I think for example that there are media specifications for camera control.
Is the SHOULD a sufficient weakening of the requirement, so that the reader can skip using humintlang for media where it does not make sense?
If not, expand "each media stream"  to: "each media stream in which human language communication might occur".



2. You have also introduced this paragraph in 7.1:
"
Clients acting on behalf of end users are expected to set one or both
   'humintlang-send' and 'humintlang-recv' attributes on each media
   stream in an offer when placing an outgoing session but ignore the
   attributes when receiving incoming calls.  Systems acting on behalf
   of call centers and PSAPs are expected to take into account the
   values when processing inbound calls.
"

What is the thought behind this?

I see the humintlang specification equally valuable in outgoing as incoming calls, and for end-users as well as call-centers and PSAPs.
If a user gets an incoming call, with humintlang specifications, it can compare with its own profile and decide to invoke a 
relay service or interpreter servicde to cover some differences in language preferences, or just prepare for what media, modalities and 
languages to use in the call..
I do not see the background for this paragraph, and think it will be better to delete it.


3. Absolute preference is still needed.
I described earlier the need for an absolute preference indication. But I did not provide any coding proposal.
I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there.
Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality 
and a "-" a non-preferred, but possible language and modality.
 
( needs to be checked against syntax of language tags.)

 
Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-14 11:05, Randall Gellens wrote:
Hi all,

I've tweaked the human language draft:

   o  Relaxed language on setting -send and -receive to same values;
      added text on leaving on empty to indicate asymmetric usage.

   o  Added text that clients on behalf of end users are expected to set
      the attributes on outgoing calls and ignore on incoming calls
      while systems on behalf of call centers and PSAPs are expected to
      take the attributes into account when processing incoming calls.


--------------060203030902050504080103-- From Christian.Groves@nteczone.com Sun Jul 14 19:11: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 51CC221F99A8 for ; Sun, 14 Jul 2013 19:11: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] 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 DMieOacAf4oP for ; Sun, 14 Jul 2013 19:11:44 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 7445621F85E6 for ; Sun, 14 Jul 2013 19:11:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoCAKRZ41F20S8S/2dsb2JhbAANTYM6whUEBAGBIoMXAQEBAQMBAQE1GxsKEQsYCQwKDwkDAgECARUwEwYCAQGIGKNjkU0Ej2sKDINiA6xN Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 11:41:33 +0930 Message-ID: <51E35A53.5030502@nteczone.com> Date: Mon, 15 Jul 2013 12:11:31 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> In-Reply-To: <51E196B0.5080406@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:11:45 -0000 Hello Randall and Gunnar, I think Randall's clarification would be good to have in the draft. I think that when a caller support the language it is sent for every call. Whether the language is used by a receiver depends on the receiver's local capability. Regards, Christian On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: > On 2013-07-13 10:07, Randall Gellens wrote: >> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >> >>> I wouldn't have thought that it would be use case specific... i.e. >>> i'd only include my language when I called an emergency service. I >>> would think an endpoint would be configured with the information and >>> then provide it whenever I made a call. Is that the intent? >> >> I expect so, but then, I also didn't expect it to be used much in the >> person-to-person case since usually language is implied by context >> when calling an individual. I expect it to be used when a person is >> calling an call center (corporate or emergency). To put it another >> way, I expect a personal client to always set language on outbound >> calls, but in most cases to ignore it on inbound calls. I'd expect a >> corporate call center, as well as emergency call handling facilities, >> to pay attention. I should make this more clear in the draft. >> > I expect the setting to be retrieved from a personal profile (likely > but not necessarily stored in connection with other user information > and account information) and used in every call. > > /Gunnar > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From Christian.Groves@nteczone.com Sun Jul 14 19:20: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 2E46A21F9CD5 for ; Sun, 14 Jul 2013 19:20: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=[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 aEhDdmfjTkWS for ; Sun, 14 Jul 2013 19:20:57 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB221F99AC for ; Sun, 14 Jul 2013 19:20:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALJb41F20S8S/2dsb2JhbAANTcJognCBIoMQBwEBAQEDOBslEQsYCQwKDwkDAgECAUUTCAEBhUWmOZFRj2sKDINiA6xN Received: from ppp118-209-47-18.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.47.18]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jul 2013 11:50:50 +0930 Message-ID: <51E35C7F.7030101@nteczone.com> Date: Mon, 15 Jul 2013 12:20:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E322C9.4040002@omnitor.se> In-Reply-To: <51E322C9.4040002@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:20:58 -0000 Hello Randall, Please see my comment below. ..snip.. On 15/07/2013 8:14 AM, Gunnar Hellstrom wrote: > ... > > 2. You have also introduced this paragraph in 7.1: > " > Clients acting on behalf of end users are expected to set one or both > 'humintlang-send' and 'humintlang-recv' attributes on each media > stream in an offer when placing an outgoing session but ignore the > attributes when receiving incoming calls. Systems acting on behalf > of call centers and PSAPs are expected to take into account the > values when processing inbound calls. > " > > What is the thought behind this? > > I see the humintlang specification equally valuable in outgoing as incoming calls, and for end-users as well as call-centers and PSAPs. > If a user gets an incoming call, with humintlang specifications, it can compare with its own profile and decide to invoke a > relay service or interpreter servicde to cover some differences in language preferences, or just prepare for what media, modalities and > languages to use in the call.. > I do not see the background for this paragraph, and think it will be better to delete it. > > > [CNG] I guess this is a question of scope. I would think that the draft would just describe the syntax and procedures of this new language tag in a generic manner. The application level behaviour of call centres and PSAPs would be defined elsewhere? Regards, Christian From internet-drafts@ietf.org Sun Jul 14 21:42: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 B122721F9B5D; Sun, 14 Jul 2013 21:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 hiTxNkQJ9E6w; Sun, 14 Jul 2013 21:42:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 279C321F9AFD; Sun, 14 Jul 2013 21:42:52 -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.51.p2 Message-ID: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 21:42:52 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 04:42:53 -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 : Offer/Answer Considerations for G723 Annex A and G729 An= nex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt Pages : 8 Date : 2013-07-14 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mperumal@cisco.com Sun Jul 14 21:51: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 5700821F92C0 for ; Sun, 14 Jul 2013 21:51:11 -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 VKuE+ElFUAnM for ; Sun, 14 Jul 2013 21:51:05 -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 A303021F9C6E for ; Sun, 14 Jul 2013 21:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2015; q=dns/txt; s=iport; t=1373863865; x=1375073465; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LNs1SCoRtLvgaZxnLCUUS5cJxqvM4LdY5ZgPy5LgzHM=; b=FmC9tWhkpYAp/wh0xROhA2RuK5zeVJWOVyMe1ed+nx51GiULF0tJNbik rdrkrgRbPGdFL6pfKNFdgRFDAquevTnUitQXwHdegziLFZVcn1A6ZlCsB wjjTuAfL4K9iP+m1n198du8UrtNZDdapDBGiJU7xeBqeswNYM6WFqU1fq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAGB+41GtJV2Z/2dsb2JhbABagwY0SQbBT4EOFnSCIwEBAQEDAQEBNzQXBAIBCBEEAQELFAkHJwsUBwEBBQMCBBMIAYgHBwW1QY8zMwUGgwVtA5kFiwGFI4MSgig X-IronPort-AV: E=Sophos;i="4.89,667,1367971200"; d="scan'208";a="234776584" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Jul 2013 04:50:56 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6F4otxF027233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 04:50:55 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sun, 14 Jul 2013 23:50:54 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Thread-Index: AQHOgRXQT5KmjKB2G0moEz4zq2KWR5llKatw Date: Mon, 15 Jul 2013 04:50:53 +0000 Message-ID: References: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> In-Reply-To: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 04:51:11 -0000 This updated version addresses all comments received during WGLC. - Muthu, Partha -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 10:13 AM To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.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 : Offer/Answer Considerations for G723 Annex A and G729 An= nex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt Pages : 8 Date : 2013-07-14 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From fandreas@cisco.com Sun Jul 14 22:29: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 65FD521F9D5C for ; Sun, 14 Jul 2013 22:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.354 X-Spam-Level: X-Spam-Status: No, score=-9.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=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 AtswTfJLaaIj for ; Sun, 14 Jul 2013 22:29:06 -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 B971A21F9C4F for ; Sun, 14 Jul 2013 22:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5662; q=dns/txt; s=iport; t=1373866146; x=1375075746; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0chS8ckt9qbuvlk/66c+wVnHMqqynQeMbf6gORNM0uE=; b=A3gVweK8z/gw+kIFBbtXNZrcbb8hf+YGyD95a6xTgo1df/TqL4aYmjul EXa8ArgaKDi6/dJIq0j9odjQcYneZ/s53LDYeeKPN0HZ/18kGXhuMI6q0 bPs6lmiRjmCvhgP8N7nV0RcIZVzv4EpizwwKWAwvCQoTnNkkgD9RJiY/S A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAjAGmI41GtJXG8/2dsb2JhbABaJoJgNIkypGoClACBDhZ0giMBAQEBA3gBEAsYCRYPCQMCAQIBRQYNAQcBAYgMDLUtj2QHg3gDl1yBKZAkgVmBVSA X-IronPort-AV: E=Sophos;i="4.89,667,1367971200"; d="scan'208,217";a="234801370" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 05:28:57 +0000 Received: from Flemmings-MacBook-Pro.local (rtp-vpn4-549.cisco.com [10.82.210.37]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6F5SuKJ011191; Mon, 15 Jul 2013 05:28:57 GMT Message-ID: <51E3475B.7040803@cisco.com> Date: Sun, 14 Jul 2013 20:50:35 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Suhas Nandakumar References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090708050004090607080703" Cc: mmusic WG Subject: Re: [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: Mon, 15 Jul 2013 05:29:11 -0000 This is a multi-part message in MIME format. --------------090708050004090607080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Section 5.20 (RFC 3407), refers to the following attributes with their category shown in brackets (note: changed "csdc" to "cdsc"): a=sqn (NORMAL) a=cdsc (TBD) a=cpar (TBD) a=cparmin (TBD) a=cparmax (TBD) I agree with the "sqn" category of NORMAL. For the rest of them, the challenge we have is that they are essentially what we could call "encapsulating" attributes, i.e. they simply encode attributes or other parameters. This leads to a problem that may apply to other attributes as well: Currently, the mux mechanism seeems to only distinguish attributes at the attribute name level, however there are attributes where you have the same attribute-name appear many times, but further parameters in the attribute distinguish these (and as per the above, this distinction may in turn lead to different categories). Also note, that these attributes to not actually negotiate use of their encapsulated values; a separate signaling mechanism, e.g. O/A exchange, would be needed for this (as noted in RFC 3407, Section 2). For "cdsc", I'd be inclined to put it in category "NORMAL", but for the rest of them, I'm not sure any of the current categories match, since it really depends on what was encapsulated in them (note that both bandwith and attributes can be encapsulated in them). Thanks -- Flemming On 4/26/13 5:24 PM, Suhas Nandakumar wrote: > 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 --------------090708050004090607080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 5.20 (RFC 3407), refers to the following attributes with their category shown in brackets (note: changed "csdc" to "cdsc"):

a=sqn (NORMAL)
a=cdsc (TBD)
a=cpar (TBD)
a=cparmin (TBD)
a=cparmax (TBD)

I agree with the "sqn" category of NORMAL.

For the rest of them, the challenge we have is that they are essentially what we could call "encapsulating" attributes, i.e. they simply encode attributes or other parameters. This leads to a problem that may apply to other attributes as well: Currently, the mux mechanism seeems to only distinguish attributes at the attribute name level, however there are attributes where you have the same attribute-name appear many times, but further parameters in the attribute distinguish these (and as per the above, this distinction may in turn lead to different categories). Also note, that these attributes to not actually negotiate use of their encapsulated values; a separate signaling mechanism, e.g. O/A exchange,  would be needed for this (as noted in RFC 3407, Section 2).

For "cdsc", I'd be inclined to put it in category "NORMAL", but for the rest of them, I'm not sure any of the current categories match, since it really depends on what was encapsulated in them (note that both bandwith and attributes can be encapsulated in them).

Thanks

-- Flemming


On 4/26/13 5:24 PM, Suhas Nandakumar wrote:
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:


Thanks in Advance

Regards
Suhas Nandakumar

--------------090708050004090607080703-- From fandreas@cisco.com Sun Jul 14 22:29: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 B34E221F9C4F for ; Sun, 14 Jul 2013 22:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.654 X-Spam-Level: X-Spam-Status: No, score=-9.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 fXCob0OhY+Fe for ; Sun, 14 Jul 2013 22:29:07 -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 16B3121F9ABB for ; Sun, 14 Jul 2013 22:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7066; q=dns/txt; s=iport; t=1373866147; x=1375075747; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2Y6g+Nbf4v84/jAbiY+xLZ/mtBP+5A7NHoICVge4HE0=; b=W7cv0Qz5Xlmw9R0Q54IgU7AfBIdruOk/kIgegHWinwSUXxWeldPwP94i DXLp/oNbE8pRtoJxwYXt3LAc1+dOQu+4PG0szCIrmT0VhE4oTqVJ/A4AT BZv1Na3ZjRWjIETiT0zlr28Wsim981RFVW4lWBypu1s2d74MuaLL+HRe6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAjAGmI41GtJXHB/2dsb2JhbABaJoJgNIkypGoClACBDhZ0giMBAQEBA3gBEAsYCRYPCQMCAQIBRQYNAQcBAYgMDLUtj2QHg3gDl1yBKZAkgVmBVSA X-IronPort-AV: E=Sophos;i="4.89,667,1367971200"; d="scan'208,217";a="234801388" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 05:29:02 +0000 Received: from Flemmings-MacBook-Pro.local (rtp-vpn4-549.cisco.com [10.82.210.37]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6F5Swb3016247; Mon, 15 Jul 2013 05:29:00 GMT Message-ID: <51E34C6A.5020704@cisco.com> Date: Sun, 14 Jul 2013 21:12:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Suhas Nandakumar References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020306050508010102050601" Cc: mmusic WG Subject: Re: [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: Mon, 15 Jul 2013 05:29:11 -0000 This is a multi-part message in MIME format. --------------020306050508010102050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Section 5.28 defines the following attributes with the category shown in brackets: a=pcfg (SPECIAL) a=acfg (SPECIAL) a=csup (SPECIAL) a=creq (SPECIAL) a=acap (SPECIAL) a=tcap (IDENTICAL) I think the definition of "SPECIAL" needs to be changed and maybe we need two versions of it: A "SPECIAL" for existing attributes, in which case the mux-attributes draft will have to define the handling that is needed, and a "SPECIAL NEW", which would essentially impose a new requirement on all new SDP attribute definitions to have one of the mux-attribute categories assigned to them, and if it's "SPECIAL NEW", then define the handling with muxing. Moving on to the categories suggested above: On the "tcap" one, it's debatable whether they need to be "IDENTICAL" since they are purely capabilities and as such not being used at this point in time; the "pcfg" atttribute is what would instantiate their use. Also, repeating the comment from the RFC 3407 attributes, we have an example of an attribute where there can be multiple different values (on purpose) and they are all equally valid. In this case, the negotiation process would end up picking one of them, and what you probably want for mux-attributes is the negotiation process to pick the same one for all the multiplexed m-lines; this seems well suited for a "SPECIAL" description (there are probably several other nuances to be covered). Similar considerations apply for "acap". For the "csup" and "creq" ones, I don't think there is anything "SPECIAL". They each list one or more option tags supported or required for capability negotiation to be used, and I believe they can just continue to do so when doing multi-plexing. In other words, I think "NORMAL" would be right for these. For "acfg" and "pcfg" I agree that further description on how they would be used with multiplexing would be needed (need to drive consistent negotiation across the multi-plexed m-lines). Thanks -- Flemming On 4/26/13 5:31 PM, Suhas Nandakumar wrote: > 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 --------------020306050508010102050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 5.28 defines the following attributes with the category shown in brackets:

a=pcfg (SPECIAL)
a=acfg (SPECIAL)
a=csup (SPECIAL)
a=creq (SPECIAL)
a=acap (SPECIAL)
a=tcap (IDENTICAL)

I think the definition of "SPECIAL" needs to be changed and maybe we need two versions of it: A "SPECIAL" for existing attributes, in which case the mux-attributes draft will have to define the handling that is needed, and a "SPECIAL NEW", which would essentially impose a new requirement on all new SDP attribute definitions to have one of the mux-attribute categories assigned to them, and if it's "SPECIAL NEW", then define the handling with muxing.

Moving on to the categories suggested above:

On the "tcap" one, it's debatable whether they need to be "IDENTICAL" since they are purely capabilities and as such not being used at this point in time; the "pcfg" atttribute is what would instantiate their use. Also, repeating the comment from the RFC 3407 attributes, we have an example of an attribute where there can be multiple different values (on purpose) and they are all equally valid. In this case, the negotiation process would end up picking one of them, and what you probably want for mux-attributes is the negotiation process to pick the same one for all the multiplexed m-lines; this seems well suited for a "SPECIAL" description (there are probably several other nuances to be covered). Similar considerations apply for "acap".

For the "csup" and "creq" ones, I don't think there is anything "SPECIAL". They each list one or more option tags supported or required for capability negotiation to be used, and I believe they can just continue to do so when doing multi-plexing. In other words, I think "NORMAL" would be right for these.

For "acfg" and "pcfg" I agree that further description on how they would be used with multiplexing would be needed (need to drive consistent negotiation across the multi-plexed m-lines).

Thanks

-- Flemming



On 4/26/13 5:31 PM, Suhas Nandakumar wrote:
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:


Thanks in Advance

Regards
Suhas Nandakumar

--------------020306050508010102050601-- From suhasietf@gmail.com Sun Jul 14 22:58: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 4F29021F9C0C for ; Sun, 14 Jul 2013 22:58:20 -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 tg-7NA1iSgUx for ; Sun, 14 Jul 2013 22:58:19 -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 B501B21F9C15 for ; Sun, 14 Jul 2013 22:58:18 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so9696718wes.35 for ; Sun, 14 Jul 2013 22:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ZR1o4BZm+jveIEL8qwsBKOoDP0nH5K1F1hvfMDPwn4=; b=S5UncEUwPDCpzrpbjcyZuQqOL8lwnHOEmkbA6Ud5ev0/S85pguSr9XcLy3WPXKNgDj 0XuyBYvRJXoTi6hPlUPMepsLjm/hlW+KrnXQb7Twyt9zguMQiwK/kzaFFpSLmTA63dMk AKeVTuC706IyV/zSrJaXAJLC+wShrnznlEqo99MQHOxy4Me6T2B2UwIXXabXWoPoUvFS M5pjNIuYO0zIjpyAw+BdBnWFw9Wz9TfcBYc04Kqcmcp18pXUcWfi7Tjy5LeJjKo8vHQl 0Eai2jHbwWmZNOkvWrskVBwzTSpFHeNlnYzpBjxkDVijacDVIbQX1FETT8iAK/vyKgKt Zd1w== MIME-Version: 1.0 X-Received: by 10.180.107.163 with SMTP id hd3mr7807029wib.13.1373867897814; Sun, 14 Jul 2013 22:58:17 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Sun, 14 Jul 2013 22:58:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Jul 2013 22:58:17 -0700 Message-ID: From: Suhas Nandakumar To: fandreas@cisco.com Content-Type: multipart/alternative; boundary=e89a8f6474fd04847604e1868caa Cc: mmusic WG Subject: Re: [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: Mon, 15 Jul 2013 05:58:20 -0000 --e89a8f6474fd04847604e1868caa Content-Type: text/plain; charset=ISO-8859-1 Thanks Flemming for the review inputs. I was wondering does assigning SPECIAL to encapsulating attributes and updating the Notes section to reflect that one should look into the categorization of encapsulated attribute for assessing the behavior Please let me know if this is the right way to go. Cheers Suhas On Fri, Apr 26, 2013 at 2:24 PM, Suhas Nandakumar wrote: > 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 > --e89a8f6474fd04847604e1868caa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Flemming for the review inputs.=A0

I was wonderin= g does assigning SPECIAL to encapsulating attributes and updating the Notes= section to reflect that one should look into the categorization of encapsu= lated attribute for assessing the behavior

Please let me know if this is the right way to go.

Cheers
Suhas

On Fri, Apr 26, 2013 at 2:24 PM, Suhas Nandakumar <suh= asietf@gmail.com> wrote:
Hello Flemming
=A0=A0
This is a request for reviewing the following sections
= =A0
5.20

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

--e89a8f6474fd04847604e1868caa-- From gunnar.hellstrom@omnitor.se Sun Jul 14 23:40: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 5F18121F9C78 for ; Sun, 14 Jul 2013 23:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Gq9WH55FV+jB for ; Sun, 14 Jul 2013 23:40:32 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 6B52821F9C0C for ; Sun, 14 Jul 2013 23:40:30 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 15 Jul 2013 08:40:20 +0200 (CEST) Received: from [192.168.43.175] (109.58.145.97.bredband.tre.se [109.58.145.97]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 94C0A3A032 for ; Mon, 15 Jul 2013 08:40:20 +0200 (CEST) Message-ID: <51E39957.3080004@omnitor.se> Date: Mon, 15 Jul 2013 08:40:23 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> In-Reply-To: <51E35A53.5030502@nteczone.com> Content-Type: multipart/alternative; boundary="------------070009030701040206060904" Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 06:40:37 -0000 This is a multi-part message in MIME format. --------------070009030701040206060904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I suggest to add a couple of use cases. 4.x. Deaf French sign language user calling another deaf French sign language user. Someone who mainly uses French sign language (FSL) places a call. The call offers a video stream listing FSL in both directions with highest preference and also real-time text stream on low preference level for French in both directions. Audio is also included but without language indications. The call destination turns out to be another user of FSL with the same media and language settings. The called client can find that the language preferences match, so the same language indications are sent in the SDP answer, and the call can be connected without connection of any relay service. The users can sign directly with each other in the video streams, and occasionally use the real-time text streams for data that need exact spelling or noted. 4.y. Spoken Japanese user calling a Spanish speaking person. Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call. The call offers audio streams using Japanese in both directions on high preference level, video with spoken Japanese with no specific preference and both message-wise and real-time text in Japanese in both directions. This user is customer of an on-line interpreting service. The service adds its interpreting language capabilities to the SDP on lower level than the originator, and conveys the call to the destination. The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible languages even if not highest preference, so that call is answered with indication of spoken Spanish at high priority level and Spanish text messaging in both directions at low priority level. The on-line interpreting service detects that their translation between Japanese and Spanish is needed to make the call work, so they allocate an interpreter to the call, and answers the call with an indication of Japanese towards the caller. Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the appropriate languages in the text message connections. The users can communicate in their own languages supported by the interpreter. ------------------------------- More might be needed to clarify some more of the endless possible variations and benefit. ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-07-15 04:11, Christian Groves wrote: > Hello Randall and Gunnar, > > I think Randall's clarification would be good to have in the draft. I > think that when a caller support the language it is sent for every > call. Whether the language is used by a receiver depends on the > receiver's local capability. > > > Regards, Christian > > > On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: >> On 2013-07-13 10:07, Randall Gellens wrote: >>> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >>> >>>> I wouldn't have thought that it would be use case specific... i.e. >>>> i'd only include my language when I called an emergency service. I >>>> would think an endpoint would be configured with the information >>>> and then provide it whenever I made a call. Is that the intent? >>> >>> I expect so, but then, I also didn't expect it to be used much in >>> the person-to-person case since usually language is implied by >>> context when calling an individual. I expect it to be used when a >>> person is calling an call center (corporate or emergency). To put >>> it another way, I expect a personal client to always set language on >>> outbound calls, but in most cases to ignore it on inbound calls. >>> I'd expect a corporate call center, as well as emergency call >>> handling facilities, to pay attention. I should make this more >>> clear in the draft. >>> >> I expect the setting to be retrieved from a personal profile (likely >> but not necessarily stored in connection with other user information >> and account information) and used in every call. >> >> /Gunnar >> _______________________________________________ >> 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 --------------070009030701040206060904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I suggest to add a couple of use cases.


4.x.  Deaf French sign language user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a call.  
The call offers a video stream listing FSL in both directions with highest preference and also 
real-time text stream on low preference level for French in both directions. 
Audio is also included but without language indications.
The call destination turns out to be another user of FSL with the same media and language settings.
The called client can find that the language preferences match, so the same language indications are 
sent in the SDP answer, and the call can be connected without connection of any relay service.
The users can sign directly with each other in the video streams, and occasionally use the real-time
text streams for data that need exact spelling or noted.


4.y.  Spoken Japanese user calling a Spanish speaking person.

Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call.  
The call offers audio streams using Japanese in both directions on high preference level, video 
with spoken Japanese with no specific preference and both message-wise and real-time text in 
Japanese in both directions.
This user is customer of an on-line interpreting service. The service adds its interpreting 
language capabilities to the SDP on lower level than the originator, and conveys the call to the destination.
The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible 
languages even if not highest preference, so that call is answered with indication of spoken Spanish at high 
priority level and Spanish text messaging in both directions at low priority level.
The on-line interpreting service detects that their translation between Japanese and Spanish is needed to
make the call work, so they allocate an interpreter to the call, and answers the call with an indication 
of Japanese towards the caller.
Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the 
appropriate languages in the text message connections.
The users can communicate in their own languages supported by the interpreter.


-------------------------------
More might be needed to clarify some more of the endless possible variations and benefit.

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-15 04:11, Christian Groves wrote:
Hello Randall and Gunnar,

I think Randall's clarification would be good to have in the draft. I think that when a caller support the language it is sent for every call. Whether the language is used by a receiver depends on the receiver's local capability.


Regards, Christian


On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote:
On 2013-07-13 10:07, Randall Gellens wrote:
At 2:49 PM +1000 7/10/13, Christian Groves wrote:

 I wouldn't have thought that it would be use case specific... i.e. i'd only include my language when I called an emergency service. I would think an endpoint would be configured with the information and then provide it whenever I made a call. Is that the intent?

I expect so, but then, I also didn't expect it to be used much in the person-to-person case since usually language is implied by context when calling an individual.  I expect it to be used when a person is calling an call center (corporate or emergency).  To put it another way, I expect a personal client to always set language on outbound calls, but in most cases to ignore it on inbound calls.  I'd expect a corporate call center, as well as emergency call handling facilities, to pay attention.  I should make this more clear in the draft.

I expect the setting to be retrieved from a personal profile (likely but not necessarily stored in connection with other user information and account information) and used in every call.

/Gunnar
_______________________________________________
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

--------------070009030701040206060904-- From ranjit.avasarala@nsn.com Mon Jul 15 00: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 BE61821F9E1F for ; Mon, 15 Jul 2013 00:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixYEBZWxWwUm for ; Mon, 15 Jul 2013 00:09:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 79DB121F9C19 for ; Mon, 15 Jul 2013 00:09:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6F78uWY002434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jul 2013 09:08:57 +0200 Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6F77m3i001971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 09:08:56 +0200 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 15:08:04 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" , "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Thread-Index: AQHOgRXQT5KmjKB2G0moEz4zq2KWR5llKatwgAAmFwA= Date: Mon, 15 Jul 2013 07:08:04 +0000 Message-ID: References: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2846 X-purgate-ID: 151667::1373872137-000017BA-E332EF01/0-0/0-0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:09:06 -0000 Hi Muthu I have following comments 1. RFC 4856 defines "annexa" and "annexb" as optional parameters. So I agre= e there could be misinpterpretations. 2. The proposed draft should make these parameters as mandatory, otherwise = the implementations would continue to ignore the parameters. 3. Update RFC 4856 moving "annexa" and "annexb" parameters from "optional" = to "required". Regards Ranjit -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Muthu Arul Mozhi Perumal (mperumal) Sent: Monday, July 15, 2013 10:21 AM To: mmusic@ietf.org Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt This updated version addresses all comments received during WGLC. - Muthu, Partha -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 10:13 AM To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.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 : Offer/Answer Considerations for G723 Annex A and G729 An= nex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt Pages : 8 Date : 2013-07-14 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From aurelien.sollaud@orange.com Mon Jul 15 02:19: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 0F15421F9655 for ; Mon, 15 Jul 2013 02:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 ReYGav-zY2B1 for ; Mon, 15 Jul 2013 02:19: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 43D3821F9AF5 for ; Mon, 15 Jul 2013 02:18:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6B7912DC1E9; Mon, 15 Jul 2013 11:18:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 43D2327C2E0; Mon, 15 Jul 2013 11:18:21 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 11:18:20 +0200 From: To: "Avasarala, Ranjit (NSN - IN/Bangalore)" , "ext Muthu Arul Mozhi Perumal (mperumal)" , "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Thread-Index: AQHOgRb1pNrY1Q7kE0mjd9CB5jpAHpllMGQAgABEw6A= Date: Mon, 15 Jul 2013 09:18:19 +0000 Message-ID: <25194_1373879901_51E3BE5D_25194_316_3_719DF432C01EA6418EBA5185063A16610D5F80@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] 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.7.1.45418 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:19:13 -0000 Hi A lot of media subtypes have optional parameters, and as long as a default = value is defined, there is no issue. The problem here is not that annexa/annexb parameters are optional, but tha= t the offer/answer procedure was not defined for these media subtypes. -----Message d'origine----- De=A0: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part = de Avasarala, Ranjit (NSN - IN/Bangalore) Envoy=E9=A0: lundi 15 juillet 2013 09:08 =C0=A0: ext Muthu Arul Mozhi Perumal (mperumal); mmusic@ietf.org Objet=A0: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Hi Muthu I have following comments 1. RFC 4856 defines "annexa" and "annexb" as optional parameters. So I agre= e there could be misinpterpretations. 2. The proposed draft should make these parameters as mandatory, otherwise = the implementations would continue to ignore the parameters. 3. Update RFC 4856 moving "annexa" and "annexb" parameters from "optional" = to "required". Regards Ranjit -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Muthu Arul Mozhi Perumal (mperumal) Sent: Monday, July 15, 2013 10:21 AM To: mmusic@ietf.org Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt This updated version addresses all comments received during WGLC. - Muthu, Partha -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 10:13 AM To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.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 : Offer/Answer Considerations for G723 Annex A and G729 An= nex B Author(s) : Muthu Arul Mozhi Perumal Parthasarathi Ravindran Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt Pages : 8 Date : 2013-07-14 Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From mperumal@cisco.com Mon Jul 15 07:29: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 7EAF911E8141 for ; Mon, 15 Jul 2013 07:29:07 -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_63=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 z4hLwyKtRj53 for ; Mon, 15 Jul 2013 07:29:03 -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 F22EE11E8132 for ; Mon, 15 Jul 2013 07:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5792; q=dns/txt; s=iport; t=1373898523; x=1375108123; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Fm5ggf3kPUowD4LFMAtL228loJul9/utSPv8IbU3puw=; b=VlSLm6UPwkOzK7ozbM78jcRdiZT2eq0vx4JP/QtTrLi7lclPl3uuS3nM ZEDgiBoc3SRRmr4s8nwV80hLjyqZEAUVBLFgPbPcdEkMB8wKt0A513L0A G+iKyKzpukIwyf4SuAws6vApWxcOgGNN2YepARruRDWXIdLqMAWxZ6uYb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFQG5FGtJXG+/2dsb2JhbABagwY0SQbBUoEQFnSCIwEBAQQBAQFrFwQCAQgRBAEBCx0HJwsUCQgCBAESCAGIBwcFtWSOIoERMwUGgwVtA4hvkBaLAYUjgxKBcTc X-IronPort-AV: E=Sophos;i="4.89,669,1367971200"; d="scan'208";a="234930481" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2013 14:28:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6FESg2U025256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 14:28:42 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 09:28:42 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "aurelien.sollaud@orange.com" , "Avasarala, Ranjit (NSN - IN/Bangalore)" , "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Thread-Index: AQHOgRb1T5KmjKB2G0moEz4zq2KWR5llMGQAgABEw6CAAFHowA== Date: Mon, 15 Jul 2013 14:28:41 +0000 Message-ID: References: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> <25194_1373879901_51E3BE5D_25194_316_3_719DF432C01EA6418EBA5185063A16610D5F80@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <25194_1373879901_51E3BE5D_25194_316_3_719DF432C01EA6418EBA5185063A16610D5F80@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.232] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:29:07 -0000 Agree with Aurelien. In addition, the draft explicitly specifies the behavi= or for the default case: When the offer or answer has G723 and the annexa parameter is absent, the offerer or answerer knows that it has implied the default "annexa=3Dyes". This is because the annexa attribute is part of the original registration of audio/G723 [RFC4856]. All implementations that support G723 understand the annexa attribute. Hence, this case MUST be considered as if the offer or answer has G723 with annexa=3Dyes. This I think should suffice to make sure implementations don't ignore it. S= o, making these optional parameters mandatory optional isn't needed (and pr= obably isn't right). Muthu |-----Original Message----- |From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] |Sent: Monday, July 15, 2013 2:48 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore); Muthu Arul Mozhi Perumal (mper= umal); mmusic@ietf.org |Subject: RE: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |Hi | |A lot of media subtypes have optional parameters, and as long as a default= value is defined, there is |no issue. |The problem here is not that annexa/annexb parameters are optional, but th= at the offer/answer |procedure was not defined for these media subtypes. | |-----Message d'origine----- |De=A0: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part= de Avasarala, Ranjit (NSN - |IN/Bangalore) |Envoy=E9=A0: lundi 15 juillet 2013 09:08 |=C0=A0: ext Muthu Arul Mozhi Perumal (mperumal); mmusic@ietf.org |Objet=A0: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |Hi Muthu | |I have following comments |1. RFC 4856 defines "annexa" and "annexb" as optional parameters. So I agr= ee there could be |misinpterpretations. |2. The proposed draft should make these parameters as mandatory, otherwise= the implementations would |continue to ignore the parameters. |3. Update RFC 4856 moving "annexa" and "annexb" parameters from "optional"= to "required". | |Regards |Ranjit | | | |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f ext Muthu Arul Mozhi |Perumal (mperumal) |Sent: Monday, July 15, 2013 10:21 AM |To: mmusic@ietf.org |Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |This updated version addresses all comments received during WGLC. | |- Muthu, Partha | |-----Original Message----- |From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= On Behalf Of internet- |drafts@ietf.org |Sent: Monday, July 15, 2013 10:13 AM |To: i-d-announce@ietf.org |Cc: mmusic@ietf.org |Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. | This draft is a work item of the Multiparty Multimedia Session Control Wo= rking Group of the IETF. | | Title : Offer/Answer Considerations for G723 Annex A and G729 A= nnex B | Author(s) : Muthu Arul Mozhi Perumal | Parthasarathi Ravindran | Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt | Pages : 8 | Date : 2013-07-14 | |Abstract: | RFC4856 describes the annexa parameter for G723 and the annexb | parameter for G729, G729D and G729E. However, the specification does | not describe the offerer and answerer behavior when the value of the | annexa or annexb parameter does not match in the Session Description | protocol(SDP) offer and answer. This document provides the offer/ | answer considerations for these parameters and updates RFC4856. | |The IETF datatracker status page for this draft is: |https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 | |There's also a htmlized version available at: |http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 | |A diff from the previous version is available at: |http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 | |Internet-Drafts are also available by anonymous FTP at: |ftp://ftp.ietf.org/internet-drafts/ | |_______________________________________________ |I-D-Announce mailing list |I-D-Announce@ietf.org |https://www.ietf.org/mailman/listinfo/i-d-announce |Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.i= etf.org/ietf/1shadow- |sites.txt |_______________________________________________ |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 | |__________________________________________________________________________= ____________________________ |___________________ | |Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et |ne doivent donc |pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, |veuillez le signaler |a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant |susceptibles d'alteration, |Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. | |This message and its attachments may contain confidential or privileged in= formation that may be |protected by law; |they should not be distributed, used or copied without authorisation. |If you have received this email in error, please notify the sender and del= ete this message and its |attachments. |As emails may be altered, Orange is not liable for messages that have been= modified, changed or |falsified. |Thank you. From suhasietf@gmail.com Mon Jul 15 08: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 C20C511E8169 for ; Mon, 15 Jul 2013 08:40: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, 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 e0rA5tqh-9AL for ; Mon, 15 Jul 2013 08:40:50 -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 38F7111E8147 for ; Mon, 15 Jul 2013 08:40:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so3070426wiw.4 for ; Mon, 15 Jul 2013 08:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PGI6V272mXtid/MTXVRkiSsNoj0AuHijc073mgv8AMk=; b=jBOma8mWAcym5roRPZYt8mOfc7N9ahd0dL1Ko/hFJoNeGshiGSMjQCxIssXS3TFX4a 1rqsUUJw2RLB/0t4LPrj7I7/oJoSJROS2SuHfMnU8qefoaGfYxRRW7hivv+SwSb9lX+T vj1lxcgZI+5wyfY1NGR04rfg7t3L0Hnrk5Ul4Jm5AXjv1L2IOPeOZDLpWo5pnG8v3rjy GE8PqxK/FWWvPXaqo+uXcp3uAe5VJznfP/W+xPBtzVsR92BuT5d3Aj3rmh83U3iWv381 Ey94fu5LxKVyg4B/aS3G3QgEbha+qKwhXP/AQJa/QDsqg4mluUwwZIBuAptifjAyhwKL j3VA== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr32979904wjc.30.1373902847235; Mon, 15 Jul 2013 08:40:47 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 08:40:47 -0700 (PDT) Date: Mon, 15 Jul 2013 08:40:47 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=089e0122e9c62a5a2a04e18eafda Subject: [MMUSIC] FW: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:40:50 -0000 --089e0122e9c62a5a2a04e18eafda Content-Type: text/plain; charset=ISO-8859-1 Hello All An updated version of the SDP Attributes Mux draft has been submitted with reviews for close to 50% of the attributes completed. Thanks every one for their valuable inputs. We are half-way there :) Cheers Suhas Nandakumar A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-03.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-mmusic-sdp-mux-attributes Revision: 03 Title: A Framework for SDP Attributes when Multiplexing Creation date: 2013-07-15 Group: Individual Submission Number of pages: 56 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-03.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-mmusic-sdp-mux-attributes-03 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. --089e0122e9c62a5a2a04e18eafda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All

=A0 =A0An updated version of the SD= P Attributes Mux draft has been submitted with reviews for close to 50% of = the attributes completed. Thanks every one for their valuable inputs. We ar= e half-way there :)


Cheers
Suhas Nandakumar
<= div>
A new version of I-D, draft-nandakumar-mmusic-sdp-mux-at= tributes-03.txt
has been successfully submitted by Suhas Nandakum= ar and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0dra= ft-nandakumar-mmusic-sdp-mux-attributes
Revision: =A0 =A0 =A0 =A0= 03
Title: =A0 =A0 =A0 =A0 =A0 A Framework for SDP Attributes when= Multiplexing
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individu= al Submission
Number of pages: 56
Abstract:
=A0 =A0The Session Description Protocol (SDP) provides mechanisms to
=A0 =A0describe attributes of multimedia sessions and of individua= l media
=A0 =A0streams (e.g., Real-time Transport Protocol (RTP) = sessions) within a
=A0 =A0multimedia session. =A0In the RTCWeb WG, there is a need to use= a
=A0 =A0single 5-tuple for sending and receiving media associat= ed with
=A0 =A0multiple media descriptions ("m=3D" line= s). =A0Such a requirement has
=A0 =A0raised concerns over the semantic implications of the SDP attri= butes
=A0 =A0associated with the RTP Sessions multiplexed over a = single transport
=A0 =A0layer flow.

=A0 = =A0The scope of this specification is to provide a framework for
=A0 =A0analyzing the multiplexing characteristics of SDP attributes. = =A0The
=A0 =A0specification also categorizes existing attributes = based on the
=A0 =A0framework described herein.
--089e0122e9c62a5a2a04e18eafda-- From internet-drafts@ietf.org Mon Jul 15 09:48: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 9F4D321E80F3; Mon, 15 Jul 2013 09:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 v4yS3nyVUNb3; Mon, 15 Jul 2013 09:48:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3877D21E80E4; Mon, 15 Jul 2013 09:48:14 -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.51.p2 Message-ID: <20130715164814.31618.21174.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:48:14 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:48:14 -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 : Using Interactive Connectivity Establishment (ICE) with = Session Description Protocol (SDP) offer/answer and Session Initiation Prot= ocol (SIP) Author(s) : Marc Petit-Huguenin Ari Keranen Filename : draft-ietf-mmusic-ice-sip-sdp-00.txt Pages : 40 Date : 2013-07-15 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 09:48: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 177FC21E80F9; Mon, 15 Jul 2013 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 6I5Zw0i2gBkV; Mon, 15 Jul 2013 09:48:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F01D21E80F4; Mon, 15 Jul 2013 09:48:25 -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.51.p2 Message-ID: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:48:25 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:48:30 -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 : Interactive Connectivity Establishment (ICE): A Protocol= for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Author(s) : Ari Keranen Jonathan Rosenberg Filename : draft-ietf-mmusic-rfc5245bis-00.txt Pages : 89 Date : 2013-07-15 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fandreas@cisco.com Mon Jul 15 09:56: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 19BF621F9FFC for ; Mon, 15 Jul 2013 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rfPWo6j5erSA for ; Mon, 15 Jul 2013 09:56:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 370B011E811B for ; Mon, 15 Jul 2013 09:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6037; q=dns/txt; s=iport; t=1373907327; x=1375116927; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=l3VaRGZ3z3GzAflBUvSG19GSkmvLqcrDiIy5WmEgLlI=; b=aD8fecloIE36PL8UBjYEYjwZNrumGY0JpYd5nSYVAz2GkngP/y4cMP7h lXmJ+Ki4IVZFiNe6impYRdZ58AyUtuG4Ru+I2X9ZQQEOdL4MgBw0xJbjY Xe7EJf6oY+XLso6MbTkrVyUd+ei3TAQlHwM2+4uHOKY0kIYWBmFQPfJkW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgGAMAo5FGrRDoH/2dsb2JhbABagwY0iTKkbZQCgRMWdIIjAQEBBAEBAWsKARALGAkWCAcJAwIBAgEPBh8RBg0BBQIBAYd6Aw4NrH4NiF6MeoJqB4N4A5VzgWmBKYp+hSaBWYFVIA X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208,217";a="86135229" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Jul 2013 16:55:24 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.8.18]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6FGtNdG001170; Mon, 15 Jul 2013 16:55:23 GMT Message-ID: <51E4297B.3040000@cisco.com> Date: Mon, 15 Jul 2013 12:55:23 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Suhas Nandakumar References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010108020503050807040708" Cc: mmusic WG Subject: Re: [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: Mon, 15 Jul 2013 16:56:15 -0000 This is a multi-part message in MIME format. --------------010108020503050807040708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd lean towards a new category for these kinds of attributes. -- Flemming On 7/15/13 1:58 AM, Suhas Nandakumar wrote: > Thanks Flemming for the review inputs. > > I was wondering does assigning SPECIAL to encapsulating attributes and > updating the Notes section to reflect that one should look into the > categorization of encapsulated attribute for assessing the behavior > > Please let me know if this is the right way to go. > > Cheers > Suhas > > On Fri, Apr 26, 2013 at 2:24 PM, Suhas Nandakumar > wrote: > > 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 > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------010108020503050807040708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd lean towards a new category for these kinds of attributes.

-- Flemming


On 7/15/13 1:58 AM, Suhas Nandakumar wrote:
Thanks Flemming for the review inputs. 

I was wondering does assigning SPECIAL to encapsulating attributes and updating the Notes section to reflect that one should look into the categorization of encapsulated attribute for assessing the behavior

Please let me know if this is the right way to go.

Cheers
Suhas

On Fri, Apr 26, 2013 at 2:24 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
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:


Thanks in Advance

Regards
Suhas Nandakumar



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

--------------010108020503050807040708-- From suhasietf@gmail.com Mon Jul 15 10:18:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848EF21E8117; Mon, 15 Jul 2013 10:18:28 -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 ASGiqPhzepiM; Mon, 15 Jul 2013 10:18:27 -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 49BDF21E8106; Mon, 15 Jul 2013 10:18:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so3156686wiw.5 for ; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FzsSFcHGHcH6qb5qhhbfkBc565YDfEH38x7wjsK0o2g=; b=QtrqWF4W8ST/smdFWXSFAmbmSwTwPbB3LasHxcAcWpd9krmVbdKaTCuSWE+Bjh9sxP lCqN+1oE3vnUeuGi8Bvc3dVd74USkqiYqQXRE+qQFX3nd9zyXvi5gKd0qDbcppleLdVs /OMJykcgh6LcmF8zlgQ4/WejgcVDfIA3JLz/hHtYEaEi09v50daecA4F/D5vM4gytBm8 SAzfnsWukKFH7dKRLJCSFwBDFkUDlGrGBSfp0jQKazqJUHO7XkBfd5TJtiGZ0fa+/+wl WLPWiv7mXZpk2Xq290R6CgDOQL0hTHL/7iiLm3Hcrm/KR5e3Lg9hPIVVcff3PJOtQ/XQ 07CQ== MIME-Version: 1.0 X-Received: by 10.194.179.33 with SMTP id dd1mr32143166wjc.51.1373908706411; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) Date: Mon, 15 Jul 2013 10:18:26 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f806648e504e1900c34 Subject: [MMUSIC] New Draft: draft-nandakumar-mmusic-rtcweb-grouping-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:18:28 -0000 --089e013d0f806648e504e1900c34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All A new draft has been submitted to describe Simulcast streams within SDP based on RFC5576 ssrc-grouping semantics. Please have a read and let me know your thoughts Cheers Suhas A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-00.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-mmusic-rtcweb-grouping Revision: 00 Title: SSRC Group Based Simulcast Signaling Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping= -00.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 Abstract: In some applications it may be necessary to send multiple media encodings corresponding to a media source with in independent RTP media streams. This is called Simulcast. This document discusses a framework for describing simulcast media streams in SDP and also defines semantics to express relationship amongst them. The semantics defined in this document are to be used with the source specific grouping framework defined in the [RFC5576] --089e013d0f806648e504e1900c34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All<= /div>

<= /div>
=A0 =A0A new= draft has been submitted to describe Simulcast streams within SDP based on= RFC5576 ssrc-grouping semantics.

=
Please have a rea= d and let me know your thoughts

Chee= rs
Su= has
<= span style=3D"font-family:monospace;font-size:16px">
A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
has been successfully submitted b= y Suhas Nandakumar and posted to the
IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0 draft-nandakumar-mmusic-rtcweb-groupin= g
Revision:=A0=A0=A0=A0= =A0=A0=A0 00
Title:=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 SSRC Group Based Simulcast Signaling
Creation date:=A0=A0 2= 013-07-15
Group:=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Individual Submission
Number of pages: 8
URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-gr= ouping-00.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-gr= ouping
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00<= /a>


Abstract:
=A0=A0 In some applicatio= ns it may be necessary to send multiple media
=A0=A0 encodings corre= sponding to a media source with in independent RTP
=A0=A0 media streams.=A0 This is called Simulcast.=A0 This docum= ent discusses a
=A0=A0 framework for d= escribing simulcast media streams in SDP and also
=A0=A0 defines semantics to express relationship amongst them.=A0= The
=A0=A0 semantics defin= ed in this document are to be used with the source
=A0=A0 specific grouping framework defined in the [RFC5576] --089e013d0f806648e504e1900c34-- From ari.keranen@ericsson.com Mon Jul 15 10:48: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 6296311E8179 for ; Mon, 15 Jul 2013 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.667 X-Spam-Level: X-Spam-Status: No, score=-4.667 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 c8bWBGuY3w+E for ; Mon, 15 Jul 2013 10:48:05 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE411E812B for ; Mon, 15 Jul 2013 10:48:04 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-be-51e435d332b5 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CC.85.05990.3D534E15; Mon, 15 Jul 2013 19:48:03 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Mon, 15 Jul 2013 19:48:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0175B11021C for ; Mon, 15 Jul 2013 20:48:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 45419556D0 for ; Mon, 15 Jul 2013 20:47:59 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DFC025540B for ; Mon, 15 Jul 2013 20:47:58 +0300 (EEST) Message-ID: <51E435D7.1030102@ericsson.com> Date: Mon, 15 Jul 2013 20:48:07 +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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> In-Reply-To: <20130715164825.3591.54186.idtracker@ietfa.amsl.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+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvre5l0yeBBlePKVhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVteTmUvWCtY0dgzjaWB8QpvFyMnh4SAicSV3deZIWwxiQv3 1rN1MXJxCAkcZpR48vwZO4SznlGi/8xuFpAqIYHLjBL/pwhCJI4wSnQfPMYC4WxhlDh7ZDXY LF4BbYl7Dw4zgtgsAqoSvw/fYwKx2QTsJW5OuA40loNDVCBZ4uURI4hyQYmTM5+ALRAREJV4 dHERK4gtLOAq8fHgW0aIxQ4Syy/MZwexOQUcJRasvQa2ilnAVuLCnOssELa8xPa3c6DeUZO4 em4TM0SvqsTVf68YJzCKzEKybhaS9llI2hcwMq9iZM9NzMxJLzfaxAgM5YNbfqvuYLxzTuQQ ozQHi5I472a9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJvmsPqrhpp9TjsV/G3L3Zb0 hANFc/ek/S2sFPbYtsW6g++J1ekqSXubm3vmnbbRZ4k5wGSdfeLZUuEVubsyee+8UAk952EW 6rXWdl9KwbbmG79STqt3bru+wmGhuO3tE9N9/0Vr3G9S9jzLsMj7XcPDjFUC12qWXK3TTu+8 8slK3SZ5u7/VciWW4oxEQy3mouJEAK0uBh0zAgAA Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:48:10 -0000 Folks, We've submitted the ICE drafts as WG documents, as agreed at the previous meeting. They also address the issues that were discussed during the meeting and/or on the list: - clarified the use of short term credentials in connectivity checks - not using deprecated IPv6 addresses or loop back addresses for candidates - pairing IPv6 link-locals only with link-locals (wrt ULAs still more thinking and discussion is needed) - ICE options for both session and media level (draft-ietf-mmusic-ice-sip-sdp-00) Cheers, Ari On 7/15/13 7:48 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols > Author(s) : Ari Keranen > Jonathan Rosenberg > Filename : draft-ietf-mmusic-rfc5245bis-00.txt > Pages : 89 > Date : 2013-07-15 > > Abstract: > This document describes a protocol for Network Address Translator > (NAT) traversal for UDP-based multimedia sessions established with > the offer/answer model. This protocol is called Interactive > Connectivity Establishment (ICE). ICE makes use of the Session > Traversal Utilities for NAT (STUN) protocol and its extension, > Traversal Using Relay NAT (TURN). ICE can be used by any protocol > utilizing the offer/answer model, such as the Session Initiation > Protocol (SIP). > > This document obsoletes RFC 5245. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-00 > > > 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 emcho@sip-communicator.org Mon Jul 15 11:05: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 48E4F11E81CD for ; Mon, 15 Jul 2013 11:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 MFjvW1Y+FPyN for ; Mon, 15 Jul 2013 11:05:03 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id F2CCE11E818A for ; Mon, 15 Jul 2013 11:04:57 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so3191872wiv.15 for ; Mon, 15 Jul 2013 11:04:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=xjEhsd25qaYO5Qdz2ejcGmh0dWQUfqL8bQsjCmECMk0=; b=NfVV9nRUZLUbKxrOiO9eLAfIx3OLooJ+P8KiOqVn4EyDhlP0S81foThHT4EM8pO4Kq 25hrai83vnK3fPCQCNzPx8YUDShRWN6gMSMe8MU9WWRfWvk3IbuybqF3u0CJmzGbrvgV 3DgEUb6IOri46GbHTFy0LMGIaKcALQlbQT01Gkj2mDHELQGwBrPLr9B/ewcs8t1bcOPJ W1K0z7Sb6EpIEhBf81W0T3dqY5UbT6Qn7tFW4lomzuGjV65iaYf9mFDHygOG4RYAq/yw 9qkqsZb5y5K1dsL1grFAermj4brPXjWxUZXafQbskgsp5BCo7czTYGb2RkN8liC5NP7c PUkQ== X-Received: by 10.194.179.33 with SMTP id dd1mr32260035wjc.51.1373911496652; Mon, 15 Jul 2013 11:04:56 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [2607:f8b0:400c:c01::22a]) by mx.google.com with ESMTPSA id r8sm22564754wiz.5.2013.07.15.11.04.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 11:04:56 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so10144300vea.1 for ; Mon, 15 Jul 2013 11:04:54 -0700 (PDT) X-Received: by 10.58.108.8 with SMTP id hg8mr29010564veb.6.1373911494340; Mon, 15 Jul 2013 11:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.45.71 with HTTP; Mon, 15 Jul 2013 11:04:34 -0700 (PDT) In-Reply-To: <51E435D7.1030102@ericsson.com> References: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> <51E435D7.1030102@ericsson.com> From: Emil Ivov Date: Mon, 15 Jul 2013 20:04:34 +0200 Message-ID: To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkWlCw1vbsxYTwPKs2EOoJ8Pd7CB8swOg2R08XwvJBT0BjL02sQz2Yb2Gzz2x6SND7DAj1e Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:05:08 -0000 Very minor comment: On Mon, Jul 15, 2013 at 7:48 PM, Ari Ker=E4nen w= rote: > Folks, > > We've submitted the ICE drafts as WG documents, as agreed at the previous > meeting. They also address the issues that were discussed during the meet= ing > and/or on the list: > - clarified the use of short term credentials in connectivity checks > - not using deprecated IPv6 addresses or loop back addresses for candidat= es Wouldn't it make sense to allow pairing loopback addresses with other loopback addresses? The main use case that comes to mind is debug sessions where both the transmitter and the receiver are on the same host? Emil > - pairing IPv6 link-locals only with link-locals (wrt ULAs still more > thinking and discussion is needed) > - ICE options for both session and media level > (draft-ietf-mmusic-ice-sip-sdp-00) > > > Cheers, > Ari > > > On 7/15/13 7:48 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multiparty Multimedia Session Control >> Working Group of the IETF. >> >> Title : Interactive Connectivity Establishment (ICE): = A >> Protocol for Network Address Translator (NAT) Traversal for Offer/Answer >> Protocols >> Author(s) : Ari Keranen >> Jonathan Rosenberg >> Filename : draft-ietf-mmusic-rfc5245bis-00.txt >> Pages : 89 >> Date : 2013-07-15 >> >> Abstract: >> This document describes a protocol for Network Address Translator >> (NAT) traversal for UDP-based multimedia sessions established with >> the offer/answer model. This protocol is called Interactive >> Connectivity Establishment (ICE). ICE makes use of the Session >> Traversal Utilities for NAT (STUN) protocol and its extension, >> Traversal Using Relay NAT (TURN). ICE can be used by any protocol >> utilizing the offer/answer model, such as the Session Initiation >> Protocol (SIP). >> >> This document obsoletes RFC 5245. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-00 >> >> >> 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 >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 https://jitsi.org FAX: +33.1.77.62.47.31 From suhasietf@gmail.com Mon Jul 15 11:34: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 3549121F8529; Mon, 15 Jul 2013 11:34:49 -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 YTj40v21ItiB; Mon, 15 Jul 2013 11:34:48 -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 D30BD11E8153; Mon, 15 Jul 2013 11:34:47 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so3237299wiv.1 for ; Mon, 15 Jul 2013 11:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FNrt7v4qeL0HFFrF8RVaB0F2sOaIRHrSAa0ZL+1jufg=; b=MG4665NqlLtarxNFxLrCjZABlNVa8al+8neGZf8/hNbHC5WpAPXgpQWxc0KtvgJVsX a0EqhyPPLLsyystCUcpkWfrFEL1zypjRJRL7GC7z8ynQ7+Wk84fWtHrDD6j+L6kjd17a 0E5aREwp0237BqnNAy1gic+uwKUAfipJmC/KiVCvL7r/Yr0en/VINM8F/GBLwRD9ol8t +EhSrQ9rDzi8YRDGF25UiKMyoviydNfr9UTiiNsDnHvL69ApOPQoyAOaeYvGhsGvl8iQ 9PrQcBySdMy7D2awdqHbvzuNgzFIUx2PCu7rtRFHgldRhO+Eu59TaR/cjJuBXMyY3Z35 6MQA== MIME-Version: 1.0 X-Received: by 10.194.109.104 with SMTP id hr8mr32505089wjb.32.1373913286915; Mon, 15 Jul 2013 11:34:46 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 11:34:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 11:34:46 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bf10aea6b3ecd04e1911dd1 Subject: Re: [MMUSIC] New Draft: draft-nandakumar-mmusic-rtcweb-grouping-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:34:49 -0000 --047d7bf10aea6b3ecd04e1911dd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The links in my earlier email seems to have mail.cisco.com redirects and hence I am including the direct links for the same below Filename: draft-nandakumar-mmusic-rtcweb-grouping Revision: 00 Title: SSRC Group Based Simulcast Signaling Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping= -00.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 Sorry for the inconvenience Cheers Suhas PS: Thanks Martin and Ethan for catching this. On Mon, Jul 15, 2013 at 10:18 AM, Suhas Nandakumar wro= te: > Hello All > > A new draft has been submitted to describe Simulcast streams within SD= P > based on RFC5576 ssrc-grouping semantics. > > Please have a read and let me know your thoughts > > Cheers > Suhas > > A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-00.txt > has been successfully submitted by Suhas Nandakumar and posted to the > IETF repository. > > Filename: draft-nandakumar-mmusic-rtcweb-grouping > Revision: 00 > Title: SSRC Group Based Simulcast Signaling > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-groupi= ng-00.txt > Status: > http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping > Htmlized: > http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 > > > Abstract: > In some applications it may be necessary to send multiple media > encodings corresponding to a media source with in independent RTP > media streams. This is called Simulcast. This document discusses a > framework for describing simulcast media streams in SDP and also > defines semantics to express relationship amongst them. The > semantics defined in this document are to be used with the source > specific grouping framework defined in the [RFC5576] --047d7bf10aea6b3ecd04e1911dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


The links in my earlier email seems to have <= a href=3D"http://mail.cisco.com" target=3D"_blank">mail.cisco.com redir= ects and hence I am including the direct links for the same below

<= /div>
Filename: =A0 =A0 =A0 =A0draft-= nandakumar-mmusic-rtcweb-grou= ping
Revision: =A0 =A0 =A0 =A0 00<= br style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px= ;background-color:rgb(255,255,255)"> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0SS= RC Group Based Simulcast Signaling
Creation date: =A0=A02013-07-15
Group: =A0 =A0 =A0 =A0 =A0 =A0Indivi= dual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0=A0h= ttp://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatrack= er.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.or= g/html/draft-nandakumar-mmusic-rtcweb-grouping-00

Sorry for the inconvenience

Ch= eers
Suhas
PS: Thanks Martin and Ethan for catching this.


On Mon, Jul 15, 2013 at= 10:18 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
Hello All

=A0 = =A0A new draft has been submitted to describe Simulcast streams within SDP = based on RFC5576 ssrc-grouping semantics.

=
Please have a rea= d and let me know your thoughts

Chee= rs
Su= has
<= span style=3D"font-family:monospace;font-size:16px">
A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
has been successfully submitted b= y Suhas Nandakumar and posted to the
IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0 draft-nandakumar-mmusic-rtcweb-groupin= g
Revision:=A0=A0=A0=A0= =A0=A0=A0 00
Title:=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 SSRC Group Based Simulcast Signaling
Creation date:=A0=A0 2= 013-07-15
Group:=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Individual Submission
Number of pages: 8
URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-gr= ouping-00.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-= grouping
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00<= /a>


Abstract:
=A0=A0 In some applicatio= ns it may be necessary to send multiple media
=A0=A0 encodings corre= sponding to a media source with in independent RTP
=A0=A0 media streams.=A0 This is called Simulcast.=A0 This docum= ent discusses a
=A0=A0 framework for d= escribing simulcast media streams in SDP and also
=A0=A0 defines semantics to express relationship amongst them.=A0= The
=A0=A0 semantics defin= ed in this document are to be used with the source
=A0=A0 specific grouping framework defined in the [RFC5576]

--047d7bf10aea6b3ecd04e1911dd1-- From emil@sip-communicator.org Mon Jul 15 11:44: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 CA71611E81D5 for ; Mon, 15 Jul 2013 11:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 pixczeLqA0aN for ; Mon, 15 Jul 2013 11:44:32 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99E3F11E81C6 for ; Mon, 15 Jul 2013 11:44:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so10335695wgh.11 for ; Mon, 15 Jul 2013 11:44:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=bYYAQEan3v8mMEPLtzcnujtf0ZzDoG7JcqxFc8ZAPnM=; b=j8O8x1Te5K6T1guefJtltfGLD1cffOY3dg+83HlZHTp1VwQrmBNaiWnYw8EFgLSZPr p3qAMoLIIrviH9iXIlpqcnLjXDRifRTg34fwDR7SMRZ1xdXx2heCLnCO7Ws2a9t29avd 04V7pdzG4cf1zBNSQMDbD6rVbZ/w3Wl0GA5b5QZ9/2qlpM4DvbmyY7b0kPpsxrPM616I fnbkLM/8a7nYVLfSnXg4RwFODWVXPasW9Pns5badtyVwsPQ3AyNFLZPC2oGY7JXow3G6 4YjbcLlqkswrT5CfMCZgQdjh6brQUcxMfnIBBiXwx69TIywUIfe0INo5ViUKiAn+M2Y5 vT9A== X-Received: by 10.180.211.202 with SMTP id ne10mr9821134wic.39.1373913871656; Mon, 15 Jul 2013 11:44:31 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:e93c:c304:3a17:5f90]) by mx.google.com with ESMTPSA id h8sm22810694wie.1.2013.07.15.11.44.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 11:44:30 -0700 (PDT) Message-ID: <51E4430C.6020608@jitsi.org> Date: Mon, 15 Jul 2013 20:44:28 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: MMUSIC IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkBwXf4moqltS0Adj1XI3v14YLB/VOvGAKJV/hXspyNUzbOXsQVKvupQZ40i7UHGtZP8noy Subject: [MMUSIC] Semantics of an "m=" line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:44:36 -0000 Hey all, Just submitted a new draft that should server as a basis for discussion on "m=" line semantics in offer answer: http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00 The goal of the draft is to discuss the use of "m=" lines by Offer/Answer according to their original design in SDP: as envelopes for RTP sessions with any number of SSRCs. In many ways, this new document describes the basis of "No Plan" but in a generic way, not related to WebRTC. Feedback is welcome and hopefully we will be able to also discuss this in Berlin. Cheers, Emil -- https://jitsi.org From adam@nostrum.com Mon Jul 15 12:05: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 EAC6711E823B; Mon, 15 Jul 2013 12:05:34 -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, 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 SvLWPgGQpNgt; Mon, 15 Jul 2013 12:05:33 -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 AD0B221E810A; Mon, 15 Jul 2013 12:04:47 -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 r6FJ4k1N035254 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:04:46 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E447C8.1000701@nostrum.com> Date: Mon, 15 Jul 2013 14:04:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "mmusic@ietf.org" List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:05:35 -0000 [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward. Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points. I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to. Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions. Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting. Document link: http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt /a From internet-drafts@ietf.org Mon Jul 15 12:12:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2F11E81E2; Mon, 15 Jul 2013 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ezylqGS8ZKvw; Mon, 15 Jul 2013 12:12:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF5421F9D33; Mon, 15 Jul 2013 12:12:33 -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.51.p2 Message-ID: <20130715191233.8818.65454.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:12:33 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:12:40 -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 : Latching: Hosted NAT Traversal (HNT) for Media in Real-T= ime Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-03.txt Pages : 14 Date : 2013-07-15 Abstract: This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-latching-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Mon Jul 15 13:01: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 4591711E8238 for ; Mon, 15 Jul 2013 13:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[AWL=0.247, 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 2IwcqjosmIce for ; Mon, 15 Jul 2013 13:01:36 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4854D11E822E for ; Mon, 15 Jul 2013 13:01:34 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0bn91m0030bG4ec51k1aNx; Mon, 15 Jul 2013 20:01:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 0k1Z1m01V3ZTu2S3Pk1aFz; Mon, 15 Jul 2013 20:01:34 +0000 Message-ID: <51E4551D.8030902@alum.mit.edu> Date: Mon, 15 Jul 2013 16:01:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E4430C.6020608@jitsi.org> In-Reply-To: <51E4430C.6020608@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=1373918494; bh=8hEa70iQNnN35rNIeh0+e4fdlfWqKJiufCUN3mndb9o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ch94i/0bavHGTCfNhRKEEIUd0zc6wiFzZgoNJ0N/Yz50F0qU7karHyN2lS7WpvCEF xHEYq4oppvU8rqsxUeil93XjzIr20rL6rVNa3iA9HaNI4e/k6wBfwaC9+8WhNajR6K rwa0fZq6iKarX+X8Y2W1Ikn2HkzvnAefOSo5w320tjasHZ5utb7zPr7bmW75C/E5fb 41MZQg+XMVgtGs7yX4aBLjL3eD/qWsfqCEwj+Ve9EHiPRYJUFj+JRLmMMH94ah8iVh UTahxWUl7dIIpxExkLwGQbxEoMeHIFUtGfohn8A3fFTY94T7KrKR6ZyStNlNwEM93w QSonx4yrUPkGA== Subject: Re: [MMUSIC] Semantics of an "m=" line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:01:43 -0000 Emil, This is a useful draft. It makes some good point. I have some comments/questions: Section 1: o the addition or removal of simulcast or layered streams must be possible without the need for Offer/Answer exchanges beyond the initial declaration of such capabilities for either direction. ISTM that simulcast needs more discussion - it is nuanced. E.g. the following are all things one might like to say about simulcast: - I am sending the same thing in multiple formats. You can pick the one(s) you want to receive. (Especially for broadcast/multicast) - I am preparted to send the same thing in multiple formats. You can pick the one(s) you want me to send. - I want to receive a single source in multiple formats. Certainly there is need for the simulcast indication in SDP for the multicast case. And probably in some of the others. But I am not convinced it is always necessary for simulcast to be indicated in SDP. In some cases, there may be no need for the receiver to know that two streams it is receiving happen to be simulcasts on one another. And in other cases it will already know by some means. (Which is your point.) Also Section 1: o application specific signalling should be used to cover most semantics following call establishment, such as adding, removing or identifying SSRCs; I think this is the controversial point. In *some* cases, where the semantics are complex and dynamic, this makes sense. But there are no doubt many cases that are relatively simple, where its much more convenient to do something in SDP than it is to define a new application channel to negotiate this. Section 4: Demuxing and Identifying Streams The demux based solely on PT is fine if bundling is only used to combine m-lines with different media types. In that case there will be at most one bundled m-line per top level mime type. And this satisfies my requirement that it always be possible to map a packet to an m-line. But if bundling is used for any other reason, then the number of likely m-lines goes up, and the acceptability of unique PTs goes down. Then the discussion changes. I don't think the description of what must be done is quite right. You don't quite say what a depacketizing/decoding/processing chain *is*. Do you intend this as a *type* of chain, or an *instance* of a chain? I think it has to be *instance*. E.g. there may be two VP8 chains, with all the same settings, but processing different flows. Simplistically, you might say that the *type* of chain can be determined by the PT, and the *instance* of that chain can be determined by the SSRC. But typically such chains would be assigned based on where they are intended to be rendered. (Equal number of chains and renderers.) So when a new SSRC is received, and there is no matching chain, then either it must be dropped, or else some existing chain must be reconfigured to process this SSRC. This may need to happen without any additional out of band info to help. How do you imagine this being done? (In simple cases this might be done by *policy*. But I don't know if that is enough.) Is it your position that if this can't be done by policy then there must be some application-specific signaling mechanism to do it? Thanks, Paul On 7/15/13 2:44 PM, Emil Ivov wrote: > Hey all, > > Just submitted a new draft that should server as a basis for discussion > on "m=" line semantics in offer answer: > > http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00 > > The goal of the draft is to discuss the use of "m=" lines by > Offer/Answer according to their original design in SDP: as envelopes for > RTP sessions with any number of SSRCs. > > In many ways, this new document describes the basis of "No Plan" but in > a generic way, not related to WebRTC. > > Feedback is welcome and hopefully we will be able to also discuss this > in Berlin. > > Cheers, > Emil From roman@telurix.com Mon Jul 15 13:46: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 28ACD11E81E3 for ; Mon, 15 Jul 2013 13:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ln1+9XUgEDdX for ; Mon, 15 Jul 2013 13:46:52 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id D519921E8098 for ; Mon, 15 Jul 2013 13:46:51 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3353814wiw.7 for ; Mon, 15 Jul 2013 13:46:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Nu6irSOQ633pmmbx5PyxkS15gdwYi6tHZWiokBOvuPc=; b=FWhoHiaVVQMJc3s0Pd7N2VSOctYz6EHgl21n0/33g6YMg6EzGAp0Bmilj4yaRsc42J aucJX8Mgg2Yvo5Lu1GM4YUGuyjBCriuG1J3UyUCTZN/f4YvrgKSrmiesD9tj54AHPzrX D7BgeBTF4tBx1bNKqrpH3vdVxbFVLF9pUTwMt3AccYc8AO7rOM0+3ciDXE38loi1o4Tj aqSwpe8UBr/bnrZqYYJh3UrYNVgnMddVnukgSv4u5wFHxp+wtW1bCoGzc9EbMRH8agdh rYqQEPFUaWK+Z5TAlsi9LXZxDSccmIaa3KE3HBl9XDRm5JTd1dg8F9cdYYO8NrgQEH9/ FjTQ== X-Received: by 10.194.121.132 with SMTP id lk4mr33187479wjb.25.1373921210963; Mon, 15 Jul 2013 13:46:50 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [2a00:1450:400c:c05::22b]) by mx.google.com with ESMTPSA id fs8sm23465175wib.0.2013.07.15.13.46.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 13:46:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so3366021wib.4 for ; Mon, 15 Jul 2013 13:46:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.12.133 with SMTP id eq5mr33161468wjd.27.1373921209616; Mon, 15 Jul 2013 13:46:49 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 15 Jul 2013 13:46:49 -0700 (PDT) In-Reply-To: <51E447C8.1000701@nostrum.com> References: <51E447C8.1000701@nostrum.com> Date: Mon, 15 Jul 2013 16:46:49 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=047d7bb04c90a6134504e192f53c X-Gm-Message-State: ALoCoQkD1kUpT/ikYvJ75rkWVmD9qoPnx3FkiinB7XQjVOfEb5WHQD9mzjxIDt6P2RPHArQb+zKI Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:46:57 -0000 --047d7bb04c90a6134504e192f53c Content-Type: text/plain; charset=ISO-8859-1 Quick nit on the draft: In initial examples with "group:BUNDLE S1 S2 S3" mid attributes should be "a=mid:S1", "a=mid:S2", and "a=mid:S3", not "a=mid:1", "a=mid:2", "a=mid:3" _____________ Roman Shpount --047d7bb04c90a6134504e192f53c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quick nit on the draft: In initial examples with "group:BUNDLE S1 S2 S3" mid attributes should be "= ;a=3Dmid:S1", "a=3Dmid:S2", and "a=3Dmid:S3", not "= ;a=3Dmid:1", "a=3Dmid:2", "a=3Dmid:3"
_____________
Roman Shpount


--047d7bb04c90a6134504e192f53c-- From suhasietf@gmail.com Mon Jul 15 13:50: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 98FA511E824F; Mon, 15 Jul 2013 13:50:19 -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=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Fjvf25hrbgol; Mon, 15 Jul 2013 13:50:19 -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 720DA11E824E; Mon, 15 Jul 2013 13:50:18 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so2993099wgg.0 for ; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pSNS3tVJiCGcTfDq8cL1T9sumNGOrMIEEpFe+Sl/Ohs=; b=lp64MAERCYoj/rcscTAXWwYOeGCGIjnrAFobrWkw5vXvtX6sTNbO4Mi2zkO0SHM4Dd ykfWdNx52+jXcRZCLRUGrLwm/M3cnyHz5Kg+vaHoj1O38WHJvf8QAkyFUOydEttu5QwM +w58lOIvzwZEpBzETKBdBHZ+wRwlSLlKz1QSaBqVvaU/b6JVKLM3V1l1vDfV0xF+KsDY J4VidebOkhLglGseCpEdrYHqS8qqoDqhydLCDttfGV16H5jIAfioG3jalN0RAxPAmBQa ttsXXnUMIUUJ4RS+mV/ynX6a9vyjwcwujrUPagT7yBq1dNapYPNdD2SrKUnEiYFSRch6 lTcQ== MIME-Version: 1.0 X-Received: by 10.194.179.33 with SMTP id dd1mr32674769wjc.51.1373921417583; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) In-Reply-To: <37D91FC30D69DE43B61E5EEADD959F1807D30FC1@xmb-aln-x12.cisco.com> References: <20130713232132.21090.66576.idtracker@ietfa.amsl.com> <37D91FC30D69DE43B61E5EEADD959F1807D30FC1@xmb-aln-x12.cisco.com> Date: Mon, 15 Jul 2013 13:50:17 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f800b62fb04e19302da Subject: [MMUSIC] New Version Notification for draft-nandakumar-rtcweb-sdp-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: Mon, 15 Jul 2013 20:50:19 -0000 --089e013d0f800b62fb04e19302da Content-Type: text/plain; charset=ISO-8859-1 Hello All An updated version of the draft showcasing SDP examples for the most common WebRTC use-cases has be submitted. I would recommend PDF version since that shows embedded images. Please let us know your thoughts. Cheers Suhas Filename: draft-nandakumar-rtcweb-sdp Revision: 02 Title: SDP for the WebRTC Creation date: 2013-07-12 Group: Individual Submission Number of pages: 64 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-02.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-sdp Htmlized: http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-rtcweb-sdp-02 Abstract: The Web Real-Time Communication (WebRTC) [WEBRTC] working group is charged to provide protocol support for direct interactive rich communication using audio,video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiataion happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264]. This document serves a introductory purpose in describing the role of SDP for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but aims to align closest to the evolving standards. The IETF Secretariat --089e013d0f800b62fb04e19302da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All

=A0 An updated version of the draft showcasing= SDP examples for the most common WebRTC use-cases has be submitted.
<= div>

Please let us know your thoughts.

<= div>Cheers
Suhas

Filename: =A0 = =A0 =A0 =A0draft-nandakumar-rtcweb-sdp
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 SDP for the WebRTC
Creation date: =A0 2013-07-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 64
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-nandakumar-rtcweb-sdp-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-nandakumar-rtcweb-sdp
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-nand= akumar-rtcweb-sdp-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdi= ff?url2=3Ddraft-nandakumar-rtcweb-sdp-02

Abstract:
=A0 =A0The Web Real-Time Communication (WebRTC) [WEBRTC] working group is =A0 =A0charged to provide protocol support for direct interactive rich
=A0 =A0communication using audio,video and data between two peers' web<= br> =A0 =A0browsers. =A0With in the WebRTC framework, Session Description proto= col
=A0 =A0(SDP) [RFC4566] is used for negotiating session capabilities between=
=A0 =A0the peers. =A0Such a negotiataion happens based on the SDP Offer/Ans= wer
=A0 =A0exchange mechanism described in the RFC 3264 [RFC3264].

=A0 =A0This document serves a introductory purpose in describing the role o= f
=A0 =A0SDP for the most common WebRTC use-cases.

=A0 =A0This SDP examples provided in this document is still a work in
=A0 =A0progress, but aims to align closest to the evolving standards.




The IETF Secretariat


--089e013d0f800b62fb04e19302da-- From iesg-secretary@ietf.org Mon Jul 15 15:15: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 494E611E8261; Mon, 15 Jul 2013 15:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, 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 Ai-Pnq0+ktEs; Mon, 15 Jul 2013 15:15:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C483421E8184; Mon, 15 Jul 2013 15:15:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715221528.14629.39369.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:15:28 -0700 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)' to Proposed Standard (draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:15:43 -0000 The IESG has approved the following document: - 'Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)' (draft-ietf-mmusic-sdp-miscellaneous-caps-07.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps/ *Technical Summary* SDP has been extended with a capability negotiation mechanism based on SDP Offer/Answer, which allows endpoints to negotiate transport protocols, attributes as well additional media-related capabilities. This document extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this document provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media) in SDP. *Working Group Summary* The document was adopted as a WG item in March 2012 and is an external and long-standing dependency for 3GPP. The mechanisms in the document are fairly straightforward and did not receive a lot of discussion in the WG subsequently, and a WGLC was issued on the -02 version of the draft in October 2012. There were no major comments received but a chair review let to minor updates in the document resulting in the -04 version in March 2013. At this point, several people noted lack of clarity wrt potential overlap with ICE (RFC 5245) resulting in a somewhat controversial debate on the mailing list about what the WG had agreed to work on and timeliness of feedback on documents that had already been through WGLC. See threads in http://www.ietf.org/mail-archive/web/mmusic/current/msg10471.html http://www.ietf.org/mail-archive/web/mmusic/current/msg10573.html The chairs and document authors have subsequently worked to address the concerns. While there has been limited explicit feedback on the current wording, we have requested feedback several times, and lastly in http://www.ietf.org/mail-archive/web/mmusic/current/msg10962.html which resulted in no further comments received. Consequently, we believe all concerns have been addressed at this point. *Document Quality* There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. Earlier versions of the draft have been reviewed by a couple of WG participants and the document shepherd has reviewed the last several versions in detail. As noted above, the connection data capability part of the document has received detailed feedback more recently as well. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel* Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo From ari.keranen@ericsson.com Tue Jul 16 00:08: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 10D9721F85E8 for ; Tue, 16 Jul 2013 00:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 6eCbZOVlK6eO for ; Tue, 16 Jul 2013 00:07:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4059221F9C46 for ; Tue, 16 Jul 2013 00:07:45 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-70-51e4f13fcdf1 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 27.0E.19388.F31F4E15; Tue, 16 Jul 2013 09:07:43 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.19) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Tue, 16 Jul 2013 09:07: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 7856E1102AF; Tue, 16 Jul 2013 10:07:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AABAC555E2; Tue, 16 Jul 2013 10:07:39 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1A18B55145; Tue, 16 Jul 2013 10:07:39 +0300 (EEST) Message-ID: <51E4F146.7030003@ericsson.com> Date: Tue, 16 Jul 2013 10:07:50 +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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> <51E435D7.1030102@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+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvra79xyeBBhsnWVqs2TmBxWLq8scs DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK+NYb27BFfaK5Zs+sjYw9rJ1MXJySAiYSPxc e4wRwhaTuHBvPVCci0NI4DCjxOS+y4wQznpGielXnrJCOHsZJVp/v2SCcNYxStzdvogFwpnH KHHz1112kGG8AtoSTztfsILYLAKqEqdn/2MCsdkE7CVuTrgOVMPBISqQLPHyiBFEuaDEyZlP WEBsEQF5ie62RWDlzAIyEjPONoLZwgKuEh8PvoU6aSmjxMVnB8EO5xQIlGg/tYgdosFW4sKc 6ywQtrxE89bZzBDPqUlcPbcJzBYCuufqv1eMExhFZyHZPQtJ+ywk7QsYmVcxsucmZuakl5tv YgSG/cEtvw12MG66L3aIUZqDRUmcd7PemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJpP GZtFnrJOFJbdUv3n9ZOXywN/N10L3zWlI/iSL+Pnqy1i+VlSLhoyC6Is+sutNZ6nNU2e9VhA PkpcP7p2v8AEycuqnxiumpy2n1NWs8SC6/279QserhXdsH+2SZSjhpDa9Q8Nh0Ulf3X/+9sT fObAoftKGx2e5PUe4J1+bOVKvZU+QuuZ7ZRYijMSDbWYi4oTAQJ4MHdJAgAA Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 07:08:04 -0000 Hi Emil, On 7/15/13 9:04 PM, Emil Ivov wrote: > On Mon, Jul 15, 2013 at 7:48 PM, Ari Keränen wrote: >> We've submitted the ICE drafts as WG documents, as agreed at the previous >> meeting. They also address the issues that were discussed during the meeting >> and/or on the list: >> - clarified the use of short term credentials in connectivity checks >> - not using deprecated IPv6 addresses or loop back addresses for candidates > > Wouldn't it make sense to allow pairing loopback addresses with other > loopback addresses? The main use case that comes to mind is debug > sessions where both the transmitter and the receiver are on the same > host? Even on the same host debugging you should be able to use any IP address of the host for that purpose. That said, of course if you *only* have the loopback interface, then this might be useful. Perhaps it should be made "SHOULD NOT" strength? Cheers, Ari (as individual) From emil@sip-communicator.org Tue Jul 16 03: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 36C4521F9371 for ; Tue, 16 Jul 2013 03:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 kY1IztGS+OOn for ; Tue, 16 Jul 2013 03:35:36 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6844B11E80AE for ; Tue, 16 Jul 2013 03:35:35 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so480415wib.12 for ; Tue, 16 Jul 2013 03:35:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=e7VOFndWmDsaUQ7i03X+TWz0rybf3udMKTXHskuMKuc=; b=YHjJmX2VOV1jHI4O1AXelhH40Aa93+WGElUhu5KoTURYdCP017/tnAKbn4/dQ/FsAk AgjviV5843h1yDAF2Z8yWb7G86HTkgohMMS2XXoJq41aDGQ3ZTAUrxSvf2b1bs9dv/qU JEAghO52kh1Fy99ClwfucJghl+1IPx/MVQaSeXy11ieDDsfI3yf5qZsXL+rcFGDdXFSV Tb9Oqlp98dZ2oXh61g9KlPK92/spfL8/mRucH4MyS9oruVrUUPXrflFOHUXm8QWHCqsq vsa5lFzVVPCH+cXMHMRFsfqmQHAj49BOTrQEIliC7vO+UitnSVZtzCc128boxx30S8Jd 8slw== X-Received: by 10.180.90.240 with SMTP id bz16mr654351wib.24.1373970934424; Tue, 16 Jul 2013 03:35:34 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f8c9:ce4e:4a54:3740]) by mx.google.com with ESMTPSA id fs8sm26843498wib.0.2013.07.16.03.35.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 03:35:33 -0700 (PDT) Message-ID: <51E521F3.6040808@jitsi.org> Date: Tue, 16 Jul 2013 12:35:31 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> <51E435D7.1030102@ericsson.com> <51E4F146.7030003@ericsson.com> In-Reply-To: <51E4F146.7030003@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlllft+qy4mAxce944JvahmJLFZbyUTpDBSEcaCvKEH965w01ZbiRUFdIgpYp1E4w2BbjZ8 Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:35:40 -0000 On 16.07.13, 09:07, Ari Ker=E4nen wrote: > Hi Emil, > > On 7/15/13 9:04 PM, Emil Ivov wrote: >> On Mon, Jul 15, 2013 at 7:48 PM, Ari Ker=E4nen wrote: >>> We've submitted the ICE drafts as WG documents, as agreed at the prev= ious >>> meeting. They also address the issues that were discussed during the = meeting >>> and/or on the list: >>> - clarified the use of short term credentials in connectivity checks >>> - not using deprecated IPv6 addresses or loop back addresses for cand= idates >> >> Wouldn't it make sense to allow pairing loopback addresses with other >> loopback addresses? The main use case that comes to mind is debug >> sessions where both the transmitter and the receiver are on the same >> host? > > Even on the same host debugging you should be able to use any IP addres= s > of the host for that purpose. That said, of course if you *only* have > the loopback interface, then this might be useful. That's the case I was referring to. Someone made a comment in Orlando=20 about how loopback addresses had helped them debug a WebRTC app while in = the plane. > Perhaps it should be made "SHOULD NOT" strength? I think "MAY choose not to pair" would work even better. It's mostly an=20 implementation choice and choosing one way or the other doesn't=20 profoundly break things. Emil --=20 https://jitsi.org From ari.keranen@ericsson.com Tue Jul 16 04: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 2F91311E81C6 for ; Tue, 16 Jul 2013 04:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.681 X-Spam-Level: X-Spam-Status: No, score=-4.681 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 INQF37wDj9rc for ; Tue, 16 Jul 2013 04:25:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA511E80BA for ; Tue, 16 Jul 2013 04:25:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-d1-51e52db7728d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E0.EE.06741.7BD25E15; Tue, 16 Jul 2013 13:25:43 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Tue, 16 Jul 2013 13:25: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 4345611021C; Tue, 16 Jul 2013 14:25:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 818B6555E2; Tue, 16 Jul 2013 14:25:39 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A7F155145; Tue, 16 Jul 2013 14:25:39 +0300 (EEST) Message-ID: <51E52DB6.6050307@ericsson.com> Date: Tue, 16 Jul 2013 14:25:42 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <20130715164825.3591.54186.idtracker@ietfa.amsl.com> <51E435D7.1030102@ericsson.com> <51E4F146.7030003@ericsson.com> <51E521F3.6040808@jitsi.org> In-Reply-To: <51E521F3.6040808@jitsi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre523aeBBl0rjC3W7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlTHt9D/mglkCFX+2HmZqYPzI08XIwSEhYCLx rNehi5ETyBSTuHBvPVsXIxeHkMBhRolpC1oZIZz1jBKHfv6DcvYyStxp/c8O4axjlGhc8YwV wlnBKPFgzxoWkGG8AtoSx2Y/YgSxWQRUJT71fGUGsdkE7CVuTrjODmKLCiRLnP/QzgxRLyhx cuYTsF4RAXmJ7rZFTCA2s4CMxIyzjWC2sICrxMeDb6HOeMQosX9HP1iCU0BT4s+CRkaIBluJ C3Ous0DY8hLNW2czQ3ynJnH13CYwWwjooKv/XjFOYBSdhWT3LCTts5C0L2BkXsXInpuYmZNe briJERj4B7f81t3BeOqcyCFGaQ4WJXHeTXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw Tp0o26Wm+cjI6JDwSsXMmpIizs2e1S9sWAxeVb3sD9NyCs+Ycf2H9fXUTUKN86Ya9Zx51i1+ WPub4yRHx/spKQ362yYpyRYvD586P1n7e2HC+gQFtpsLPy92vyywcEW+/tqu38+XPl6ZWN9r MCE5ytUz/YOGlpd3va+YafuJvmDjI5wbHz1XYinOSDTUYi4qTgQAebKbxkoCAAA= Cc: mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:25:55 -0000 On 7/16/13 1:35 PM, Emil Ivov wrote: > On 16.07.13, 09:07, Ari Keränen wrote: >> Hi Emil, >> >> On 7/15/13 9:04 PM, Emil Ivov wrote: >>> On Mon, Jul 15, 2013 at 7:48 PM, Ari Keränen >>> wrote: >>>> We've submitted the ICE drafts as WG documents, as agreed at the >>>> previous >>>> meeting. They also address the issues that were discussed during the >>>> meeting >>>> and/or on the list: >>>> - clarified the use of short term credentials in connectivity checks >>>> - not using deprecated IPv6 addresses or loop back addresses for >>>> candidates >>> >>> Wouldn't it make sense to allow pairing loopback addresses with other >>> loopback addresses? The main use case that comes to mind is debug >>> sessions where both the transmitter and the receiver are on the same >>> host? >> >> Even on the same host debugging you should be able to use any IP address >> of the host for that purpose. That said, of course if you *only* have >> the loopback interface, then this might be useful. > > That's the case I was referring to. Someone made a comment in Orlando > about how loopback addresses had helped them debug a WebRTC app while in > the plane. I wonder how common use case that's gonna be :) >> Perhaps it should be made "SHOULD NOT" strength? > > I think "MAY choose not to pair" would work even better. It's mostly an > implementation choice and choosing one way or the other doesn't > profoundly break things. While it doesn't profoundly break things, it may cause significant delay and hence I think it's a bad idea. If the default behavior would end up having the loopback address in the offers/answers and pairing it with all other candidates ("since it's only MAY strength - I don't need to implement that check"), that would generate a whole bunch of high-priority pairs that are almost 100% sure to fail. Moreover, both endpoints should do the same wrt pairing to keep the checks in sync, so IMHO it should be fairly strong do or don't (hence at least SHOULD). Cheers, Ari From keith.drage@alcatel-lucent.com Tue Jul 16 07:58: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 4D55521F9B8C; Tue, 16 Jul 2013 07:58:33 -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=[AWL=0.000, 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 HsNPlcex7ima; Tue, 16 Jul 2013 07:58:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14CA21F84D1; Tue, 16 Jul 2013 07:58:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEwPhL020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:58:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEwP2U023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:58:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:58:25 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrA Date: Tue, 16 Jul 2013 14:58:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [MMUSIC] FW: Taxonomy X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:58:33 -0000 Extensive cross-post do not reply to this email. For information. We do expect participation input from all the listed worki= ng groups (and possibly more). Keith -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: 16 July 2013 15:53 To: avtext@ietf.org Subject: [avtext] Taxonomy (As AVTEXT WG cochair) The latest version of the RTP taxonomy draft has been submitted. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by DISPATCH, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant meeting time discussing the contents= in the AVTEXT meeting in Berlin, so please start raising your issues on th= e AVTEXT list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From ron.even.tlv@gmail.com Tue Jul 16 13:30: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 B864921F9EC2 for ; Tue, 16 Jul 2013 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 skknqzrlpt1d for ; Tue, 16 Jul 2013 13:30:29 -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 DEE4021F9E98 for ; Tue, 16 Jul 2013 13:30:27 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so1155570wib.14 for ; Tue, 16 Jul 2013 13:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=4Cd2xRRoBWArS0Kpa9V7txbyU0q1yay2dZbe8JNHF2c=; b=gEct7TGUVr1IdOsVNPokeiCNGle+hSuFLjhXqTs9/0KSqmmakwkIYlxppzxPw+WaFL zdjx/4KsaXU4Hf6VjzqpWYF456ehlFpxz7VpGS/riOltQVXNpCZhYDXK0sI8xPmOiC1X 3NdZ2p5xDwJuhZTJS4CmlVOOI7+VKCQgGdx6gNb7s1CDJLlIjyeeGjzlkXhHHProkoW6 ANBzBmvEQc2H9ar4hbIVfzj9RZSfK8zd9oBpRaN5a4HBf+8nr4SUwgXaguR47aaq4LbT F4wGNZbQLkc01e7U5BCQy6vWRwo3nmDLuurEOBaVZq3ujOMPAgj0XAyVctxJsFBuHZTO JYMA== X-Received: by 10.194.9.101 with SMTP id y5mr2457441wja.86.1374006626755; Tue, 16 Jul 2013 13:30:26 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id r8sm4963085wiy.8.2013.07.16.13.30.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 13:30:26 -0700 (PDT) From: "Roni Even" To: References: <51E447C8.1000701@nostrum.com> In-Reply-To: <51E447C8.1000701@nostrum.com> Date: Tue, 16 Jul 2013 23:28:37 +0300 Message-ID: <009001ce8263$0ed498b0$2c7dca10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGN3Ok6C3zH+O6O1w6NRgFPJ+xPXJnpBllA Content-Language: en-us Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:30:31 -0000 Adam, For correlation when the SSRC is not known in the SDP look at http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the option to use SDES and not only RTP header extension. BTW: there are other cases when the SSRC is not known using SDP before the RTP stream arrives like when an MCU switch the video. Note that SDES is distributed to the session when the source joins the RTP session which can be long before the RTP media is sent to a specific receiver in the group. Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: 15 July, 2013 10:05 PM > To: mmusic@ietf.org > Cc: rtcweb@ietf.org > Subject: [MMUSIC] Unified Plan for SDP Handling > > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] > > After significant work, Justin, Martin and I have managed to produce a > compromise plan that provides a high degree of interoperability with existing > devices (and future non-WebRTC devices) while not being excessively > onerous for WebRTC implementations or applications that use them. It's > been a tricky balancing act, but I think we've found a good mix between the > two that can form a solid basis for the working group to move forward. > > Rather than summarize the key points of the document in this email, I direct > interested parties to section 2 of the document, which summarizes the key > aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's actually > been a lot more work put into coming up with a unified draft than I originally > anticipated, and the production of this document took at least two weeks > longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done in > this area, and not a specification in itself. The intention is that its contents are > used as the basis for work in several other drafts -- some new, some not -- > that form the corpus of work necessary for RTCWEB (and potentially CLUE) to > move forward. Except in rare cases, the document does not attempt to > explicitly call out venues or documents for such work, as we (or, at the very > least, I) anticipate guidance from the various working group chairs to assist in > such decisions. > > Comments prior to Berlin would be very helpful, although this will clearly be a > point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Tue Jul 16 13:39: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 7585F21E8086 for ; Tue, 16 Jul 2013 13:39:02 -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, 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 u01zdJ3z5GKV for ; Tue, 16 Jul 2013 13:39:02 -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 E7CD221E8083 for ; Tue, 16 Jul 2013 13:39:01 -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 r6GKcugP009040 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 15:38:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E5AF5A.9050405@nostrum.com> Date: Tue, 16 Jul 2013 15:38:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <51E447C8.1000701@nostrum.com> <009001ce8263$0ed498b0$2c7dca10$@gmail.com> In-Reply-To: <009001ce8263$0ed498b0$2c7dca10$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:39:02 -0000 On 7/16/13 15:28, Roni Even wrote: > Adam, > For correlation when the SSRC is not known in the SDP look at > http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the > option to use SDES and not only RTP header extension. Roni: Thanks for the pointer. That's an interesting approach; however, for RTCWEB at least, need a solution that also works with DTLS-SRTP. /a From ron.even.tlv@gmail.com Tue Jul 16 14:50: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 8D47721E804E for ; Tue, 16 Jul 2013 14:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454, 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 FAjna+XNrJzN for ; Tue, 16 Jul 2013 14:50:41 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4485321F9EF5 for ; Tue, 16 Jul 2013 14:50:40 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so1128264wes.29 for ; Tue, 16 Jul 2013 14:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=JEMDXk9nXfuLJDymuc55k+yrFjbo+1PaKst0uHxuoMw=; b=MkVoMgE1Qv/czArbeaUQthoLSCu8BmGCk/cGrnpD9dQmWQ8gUY71a/pJEuMPON4O49 aLGmFb1ribJM0lpA4y9ipDW/szbmZvzngcSAl7B1zUPRmRleAIER+bKxkkF6stRaV2wn L8YEyKVeO/nrwAkXhaMNpbJHzez/96A0QIq+0VHIPZf6PDEIwLaG/bCcxynHBJgQWFtN AKZ6lZgtURoOLSiJcb8IkbZ/u1/oQxtX9CZ2JjXXC6uwSCAmzIBzOnuYB86Zni0t96Ch 10P1XnYF9VqyFhGsRbNxJV5yvVIwlh2zReC3hugUNBU+ezdxvNCI34CV9dyPWppSYb9H bqqA== X-Received: by 10.180.211.171 with SMTP id nd11mr2583921wic.17.1374011439308; Tue, 16 Jul 2013 14:50:39 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id w4sm5368116wia.9.2013.07.16.14.50.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 14:50:38 -0700 (PDT) From: "Roni Even" To: Date: Wed, 17 Jul 2013 00:48:50 +0300 Message-ID: <00ad01ce826e$43666300$ca332900$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6CYx6M/xNphIHVS72QN5b1PBDNDA== Content-Language: en-us Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:50:42 -0000 Hi, Some comments. In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why do you want more than one SSRC for m-line but allow only one at a time, is this for the simulcast case? Others which are not on section 2 1. The document talks about the case when there are multiple participants each sending multiple streams as mentioned in section 1.1.1 and the receiver may want to select among all these sources as discussed in section 1.1.2. The document focus on the point to point case and does not address the issue of how all the m-lines from all participants are distributes and how a late joiner gets all this information. 2. In the examples using the ssrc attribute note that according to RFC 5576 section 4.1 you must provide for each SSRC the CNAME attribute 3. The simulcast example and description allows the case of sending one of the resolutions at a time but in simulcast the source may be able to send multiple resolutions at the same time. To further complicate this case the offer can support three resolutions but can only send any two at a time which the receiver can select. How do you signal this, my view is with the maxsendssrc attribute. 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an integer) used for correlation;" I think that it must be a byte string or token not integer Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: 15 July, 2013 10:05 PM > To: mmusic@ietf.org > Cc: rtcweb@ietf.org > Subject: [MMUSIC] Unified Plan for SDP Handling > > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] > > After significant work, Justin, Martin and I have managed to produce a > compromise plan that provides a high degree of interoperability with existing > devices (and future non-WebRTC devices) while not being excessively > onerous for WebRTC implementations or applications that use them. It's > been a tricky balancing act, but I think we've found a good mix between the > two that can form a solid basis for the working group to move forward. > > Rather than summarize the key points of the document in this email, I direct > interested parties to section 2 of the document, which summarizes the key > aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's actually > been a lot more work put into coming up with a unified draft than I originally > anticipated, and the production of this document took at least two weeks > longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done in > this area, and not a specification in itself. The intention is that its contents are > used as the basis for work in several other drafts -- some new, some not -- > that form the corpus of work necessary for RTCWEB (and potentially CLUE) to > move forward. Except in rare cases, the document does not attempt to > explicitly call out venues or documents for such work, as we (or, at the very > least, I) anticipate guidance from the various working group chairs to assist in > such decisions. > > Comments prior to Berlin would be very helpful, although this will clearly be a > point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Tue Jul 16 14:52: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 1B0D411E80FC for ; Tue, 16 Jul 2013 14:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ0Dl1TON6Tq for ; Tue, 16 Jul 2013 14:52:15 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id D06D921F9E5C for ; Tue, 16 Jul 2013 14:52:05 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so1110541wev.2 for ; Tue, 16 Jul 2013 14:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=Fd5W8hyDcxHI4kqQ6K4W+jGao5E0ueF5k07B4t3Yukw=; b=c3zEzETb4L6LBhA3250YqMlPFM6UzO0VSnvkqBWh2dlAlXq57ijslcj1yOynOrRv9p rptDnbqq4t1Z98DJh9TEeJRXU4lVWMT5+sgymO/3lBM6zmyoSHQwVEyJuBAWt7t9+n59 x9qxhNh5B564ZVPTGUBtEp2fZKRxMAVPqmt5zBUxcumnbgtYMHGBvRH8+lNnBnVen+fY LzKteakEw/JVG+jrU+9eioEDt/2t5tzRAnkktc3yiMU2N4XY0oEE2eUZ+o+/y/7r9/AK Avdo7yEdwiRmmHRpAhu9+gRF+fuwoXBQgClJYr1Io2FR6H3OE9Qb/nZLDZd8MMl4KDyO YW6w== X-Received: by 10.180.78.137 with SMTP id b9mr13688889wix.16.1374011524863; Tue, 16 Jul 2013 14:52:04 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id nb12sm30776931wic.7.2013.07.16.14.52.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 14:52:03 -0700 (PDT) Message-ID: <51E5C081.9010005@jitsi.org> Date: Tue, 16 Jul 2013 23:52:01 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51E4430C.6020608@jitsi.org> <51E4551D.8030902@alum.mit.edu> In-Reply-To: <51E4551D.8030902@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl46QRVT3pE6xt0G5Ia9RH/vPeOzDAilKwR88MfY43j5hCtZGjmfGq3YA9KwefZcv2fmMd4 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Semantics of an "m=" line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:52:20 -0000 Hey Paul, On 15.07.13, 22:01, Paul Kyzivat wrote: > Emil, > > This is a useful draft. It makes some good point. I have some > comments/questions: > > Section 1: > > o the addition or removal of simulcast or layered streams must be > possible without the need for Offer/Answer exchanges beyond the > initial declaration of such capabilities for either direction. > > ISTM that simulcast needs more discussion - it is nuanced. Completely agreed. > E.g. the > following are all things one might like to say about simulcast: > - I am sending the same thing in multiple formats. You can pick > the one(s) you want to receive. (Especially for broadcast/multicast) > > - I am preparted to send the same thing in multiple formats. > You can pick the one(s) you want me to send. > > - I want to receive a single source in multiple formats. > > Certainly there is need for the simulcast indication in SDP for the > multicast case. And probably in some of the others. But I am not > convinced it is always necessary for simulcast to be indicated in SDP. > In some cases, there may be no need for the receiver to know that two > streams it is receiving happen to be simulcasts on one another. And in > other cases it will already know by some means. (Which is your point.) Yes. > Also Section 1: > > o application specific signalling should be used to cover most > semantics following call establishment, such as adding, removing > or identifying SSRCs; > > I think this is the controversial point. In *some* cases, where the > semantics are complex and dynamic, this makes sense. But there are no > doubt many cases that are relatively simple, where its much more > convenient to do something in SDP than it is to define a new application > channel to negotiate this. I agree and the draft doesn't try to argue against this. I suppose in these cases SDP can be viewed as *the* application specific signalling. When doing this however, it would make sense to have a fallback strategy. That is, unless I know that the remote party supports these stream control semantics, I most not rely on them and I stick to the basic offer/answer exchange. That's what we generally do with new Offer/Answer features, right? > Section 4: Demuxing and Identifying Streams > > The demux based solely on PT is fine if bundling is only used to combine > m-lines with different media types. In that case there will be at most > one bundled m-line per top level mime type. And this satisfies my > requirement that it always be possible to map a packet to an m-line. > > But if bundling is used for any other reason, then the number of likely > m-lines goes up, and the acceptability of unique PTs goes down. Then the > discussion changes. I agree, with the same comment as above: you should only use multiple "m=" lines for the same media type if you know that your peer would understand what this means. If not then you stick to one "m=" line per type and add an option indicating you support a multi-line mechanism. This multi-line mechanism, like for example Plan A (a.k.a. "unified plan"), will then define demux procedures that work with it. Does this make sense? > I don't think the description of what must be done is quite right. You > don't quite say what a depacketizing/decoding/processing chain *is*. Do > you intend this as a *type* of chain, or an *instance* of a chain? I am not sure I understand how you define type and instance. Do you get one chain type per media type? If so, then I meant type. > I > think it has to be *instance*. E.g. there may be two VP8 chains, with > all the same settings, but processing different flows. Simplistically, > you might say that the *type* of chain can be determined by the PT, and > the *instance* of that chain can be determined by the SSRC. Yes agreed. The point of the draft is that you use PT to find a chain type. You can then use whatever you want (e.g. SSRC) to map to a specific instance. That part does not need to happen in SDP though. > But typically such chains would be assigned based on where they are > intended to be rendered. (Equal number of chains and renderers.) So when > a new SSRC is received, and there is no matching chain, then either it > must be dropped, or else some existing chain must be reconfigured to > process this SSRC. This may need to happen without any additional out of > band info to help. How do you imagine this being done? (In simple cases > this might be done by *policy*. But I don't know if that is enough.) Is > it your position that if this can't be done by policy then there must be > some application-specific signaling mechanism to do it? Yes exactly. Note in this case application-specific does not have to mean SIP or XMPP. It can also be RTP header extensions, a semi-dynamic policy downloadable over http or even SDP (although, as Roni mentioned, you can have the same problem there). Emil > > Thanks, > Paul > > On 7/15/13 2:44 PM, Emil Ivov wrote: >> Hey all, >> >> Just submitted a new draft that should server as a basis for discussion >> on "m=" line semantics in offer answer: >> >> http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00 >> >> The goal of the draft is to discuss the use of "m=" lines by >> Offer/Answer according to their original design in SDP: as envelopes for >> RTP sessions with any number of SSRCs. >> >> In many ways, this new document describes the basis of "No Plan" but in >> a generic way, not related to WebRTC. >> >> Feedback is welcome and hopefully we will be able to also discuss this >> in Berlin. >> >> Cheers, >> Emil > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From jonathan@vidyo.com Tue Jul 16 15:05: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 2C48121F9FE4 for ; Tue, 16 Jul 2013 15:05:51 -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 f+6DlEYznIdd for ; Tue, 16 Jul 2013 15:05:47 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1D21F9ED4 for ; Tue, 16 Jul 2013 15:05:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D43A47AB48C; Tue, 16 Jul 2013 18:05:36 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 432817AB441; Tue, 16 Jul 2013 18:05:36 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 16 Jul 2013 18:03:39 -0400 From: Jonathan Lennox To: Adam Roach Date: Tue, 16 Jul 2013 18:05:38 -0400 Thread-Topic: [MMUSIC] Unified Plan for SDP Handling Thread-Index: Ac6CcEr+ZUecbb5ASLywAYKTd1LmBQ== Message-ID: References: <51E447C8.1000701@nostrum.com> <009001ce8263$0ed498b0$2c7dca10$@gmail.com> <51E5AF5A.9050405@nostrum.com> In-Reply-To: <51E5AF5A.9050405@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:05:51 -0000 On Jul 16, 2013, at 4:38 PM, Adam Roach wrote: > On 7/16/13 15:28, Roni Even wrote: >> Adam, >> For correlation when the SSRC is not known in the SDP look at >> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and t= he >> option to use SDES and not only RTP header extension. >=20 > Roni: >=20 > Thanks for the pointer. That's an interesting approach; however, for=20 > RTCWEB at least, need a solution that also works with DTLS-SRTP. Acronym collision: This uses RTCP Source Description packets, not SDP Secur= ity Descriptions. I think the (related) app-id approach described in http://tools.ietf.org/ht= ml/draft-even-mmusic-application-token-00.txt will also be of interest. -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Tue Jul 16 15:12: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 75B9921F90C3 for ; Tue, 16 Jul 2013 15:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.402, 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 C8D6XZuFrAEA for ; Tue, 16 Jul 2013 15:12:31 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AE72021F9048 for ; Tue, 16 Jul 2013 15:12:30 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so1128077wes.17 for ; Tue, 16 Jul 2013 15:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hs0jgwT1FAYUJ33LD7dc6UflSXhVTQrE5Ih+xDnV7lM=; b=dWPLH26qmh++tz1GUM4sqz6COYhm1jqqzGYmYyD+yzvla8PEHY08yhe/Ddm27Nf+5q VjWOj4F5CuIMuysoIpfimplp3KPYFyD1lovvwuo0E9lEFs9hgNNQLSkAoXiiafJeRmkb XuCNMtnJW6dQ9UBtpvmE7wl2Loc4ROvN1og39gLgACIoe7XkCU7N9jDXR4XvhQwAovaR E0rhCrnKCosUY3OsZ1/X4i4oYnJhd9VY02QH56LhM0eHMOgilp65PkICHeDtQywGdijx AK/Xpyle1UmuFP8z1OAE0b9DnmOLqObB5gw/UDQ4D1yqmspHiuvnCeemBF+vgtJGAokW NhWg== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr2719730wjx.84.1374012749743; Tue, 16 Jul 2013 15:12:29 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 16 Jul 2013 15:12:29 -0700 (PDT) In-Reply-To: <00ad01ce826e$43666300$ca332900$@gmail.com> References: <00ad01ce826e$43666300$ca332900$@gmail.com> Date: Tue, 16 Jul 2013 15:12:29 -0700 Message-ID: From: Martin Thomson To: Roni Even Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:12:31 -0000 Hi Roni, On 16 July 2013 14:48, Roni Even wrote: > Hi, > Some comments. > In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why > do you want more than one SSRC for m-line but allow only one at a time, is > this for the simulcast case? The text includes "Absent any other signaled extension, [...]" for exactly that reason. The plan is to include a specific extension for simulcast, layering and FEC that would avoid this specific problem. > Others which are not on section 2 > > 1. The document talks about the case when there are multiple participants > each sending multiple streams as mentioned in section 1.1.1 and the receiver > may want to select among all these sources as discussed in section 1.1.2. > The document focus on the point to point case and does not address the issue > of how all the m-lines from all participants are distributes and how a late > joiner gets all this information. The assumption is that there is always a point-to-point leg that is being negotiated. That doesn't remove the need to combine information from a multi-party session into a single description. > 3. The simulcast example and description allows the case of sending one of > the resolutions at a time but in simulcast the source may be able to send > multiple resolutions at the same time. To further complicate this case the > offer can support three resolutions but can only send any two at a time > which the receiver can select. How do you signal this, my view is with the > maxsendssrc attribute. (Full disclosure, I didn't keep track of the changes in this area effectively, my views may differ from Adam and Justin on this point.) The combination of FID grouping and the newly defined SIMULCAST grouping might provide enough information. In that way, I can suggest that I don't want to see both A and C at the same time, even though A+B or B+C might be OK. I'd rather not rely on maxsendssrc, which is based on a very different set assumption on the meaning of an m-line to what this document describes. > 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an > integer) used for correlation;" I think that it must be a byte string or > token not integer There have been serious concerns raised regarding size of packets, even though the header extension is not sent on many packets. While it's true that a 16-bit identifier is restrictive, but you'll need to motivate a size increase a little better than that. From adam@nostrum.com Tue Jul 16 15:25: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 17B8521F9EC2 for ; Tue, 16 Jul 2013 15:25:50 -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, 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 Z15c-75lRHba for ; Tue, 16 Jul 2013 15:25:49 -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 61A9E21F9E46 for ; Tue, 16 Jul 2013 15:25:49 -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 r6GMPi1K020665 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 17:25:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E5C863.7000101@nostrum.com> Date: Tue, 16 Jul 2013 17:25:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <00ad01ce826e$43666300$ca332900$@gmail.com> In-Reply-To: <00ad01ce826e$43666300$ca332900$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:25:50 -0000 On 7/16/13 16:48, Roni Even wrote: > Hi, > Some comments. > In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why > do you want more than one SSRC for m-line but allow only one at a time, is > this for the simulcast case? No, simulcast is signaled explicitly (I will point out and emphasize the phrase "absent any other signaled extension"). This is "default behavior" is intended to accommodate MCUs that perform packet switching for RTP (and similar architectures that require different timing and/or sequence number spaces on a single stream). > Others which are not on section 2 > > 1. The document talks about the case when there are multiple participants > each sending multiple streams as mentioned in section 1.1.1 and the receiver > may want to select among all these sources as discussed in section 1.1.2. > The document focus on the point to point case and does not address the issue > of how all the m-lines from all participants are distributes and how a late > joiner gets all this information. The intention is that these changes to the session be explicitly described via SDP. > 2. In the examples using the ssrc attribute note that according to RFC 5576 > section 4.1 you must provide for each SSRC the CNAME attribute I think we had that in some early examples, but they were later removed. I agree that the text in 5576 requires its presence, and see no reason not to add it to the examples. > 3. The simulcast example and description allows the case of sending one of > the resolutions at a time but in simulcast the source may be able to send > multiple resolutions at the same time. The intention is definitely that sending multiple resolutions in parallel would be facilitated. Do you see any specific text prohibiting doing so, or is this fallout from your misunderstanding of section 2 bullet 2? > 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an > integer) used for correlation;" I think that it must be a byte string or > token not integer Do you have some rationale for your assertion? The goal here is to limit expansion of the RTP packets as much as possible. Given that there is a natural limit of 65536 streams in a single RTP session, 16 bits for a correlator seems sufficient. /a From adam@nostrum.com Tue Jul 16 15:36: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 0AD8A21F9DFB for ; Tue, 16 Jul 2013 15:36:15 -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, 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 NxBmlIDxKUKJ for ; Tue, 16 Jul 2013 15:36:14 -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 8812021F9DF0 for ; Tue, 16 Jul 2013 15:36:14 -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 r6GMaBbL021790 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 17:36:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E5CAD5.3040506@nostrum.com> Date: Tue, 16 Jul 2013 17:36:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> In-Reply-To: <51E5C863.7000101@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:36:15 -0000 On 7/16/13 17:25, Adam Roach wrote: > The goal here is to limit expansion of the RTP packets as much as > possible. Given that there is a natural limit of 65536 streams in a > single RTP session, 16 bits for a correlator seems sufficient. Gack. I had crosswired some bytefield lengths in my brain here. SSRCs are 32 bits, not 16. I'm game for increasing the size to 32 bits for the correlator if we really think we need more than 64k streams in a session -- but I'm going to ask for some justification if someone makes that argument. /a From jonathan@vidyo.com Tue Jul 16 15:46: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 A972E21F9EA3 for ; Tue, 16 Jul 2013 15:46: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=[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 3r+POE5t7-2y for ; Tue, 16 Jul 2013 15:46:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC621F9702 for ; Tue, 16 Jul 2013 15:46:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EB2E65570FC for ; Tue, 16 Jul 2013 18:46:31 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 692C95570FF for ; Tue, 16 Jul 2013 18:46:31 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 16 Jul 2013 18:45:32 -0400 From: Jonathan Lennox To: Martin Thomson Date: Tue, 16 Jul 2013 18:46:29 -0400 Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - multiple media sources Thread-Index: Ac6CdgAlmrZlUVszQ1Skr7TG/9AmFQ== Message-ID: References: <00ad01ce826e$43666300$ca332900$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:46:37 -0000 On Jul 16, 2013, at 6:12 PM, Martin Thomson wrot= e: >> 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an >> integer) used for correlation;" I think that it must be a byte string or >> token not integer >=20 > There have been serious concerns raised regarding size of packets, > even though the header extension is not sent on many packets. While > it's true that a 16-bit identifier is restrictive, but you'll need to > motivate a size increase a little better than that. Have you read http://tools.ietf.org/html/draft-even-mmusic-application-toke= n-00.txt ? This is a more fleshed-out version of the same idea, as I under= stand the idea in Unified, written to be agnostic between Plans A / B / No = Plan. The important difference the version of the idea presented in application-t= oken, and the version in Unified is, I think, to the fact that once you hav= e the correlator (app-id) signaled in SDP, you no longer *need* the SSRC to= also be signaled -- the correlation can be done entirely based on the app-= id, if you so desire. This gives you a lot more flexibility, with less nee= d for a fresh offer-answer when something changes. In app-id, we chose to use a token, rather than an integer, for this field.= One important reason for this is that it's useful to be able to send this= identifier in RTCP SDES[*] packets, so you can pre-announce correlations b= efore sending media; however, SDES fields are defined by RFC 3550 as UTF-8 = strings. (There are also some RTP architectural-cleanliness reasons for ha= ving the primary location for the correlator be in RTCP, with the header ex= tension being a rapid-convergence optimization.)=20 [*note: RTCP "SDES" (Source Description) packets are entirely unrelated to = SDP "SDES" (Security Description) SRTP key exchange; this is an unfortunate= acronym collision.] Both RFC 5285 header extensions and RTCP SDES fields are length-delimited, = so making the app identifiers be variable-length has no intrinsic packet ov= erhead cost. A sender is always free to choose short identifiers. (Probab= ly the spec should make short identifiers RECOMMENDED.) It adds a bit of i= mplementation complexity, but it doesn't seem like very much compared with = all the rest of an RTP pipeline. -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Tue Jul 16 15:57: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 D298B21F854E for ; Tue, 16 Jul 2013 15:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.388, 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 0Kt+83G4W2AX for ; Tue, 16 Jul 2013 15:57:35 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF221F8475 for ; Tue, 16 Jul 2013 15:57:34 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so1154824wes.4 for ; Tue, 16 Jul 2013 15:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/ENJKGpUKL8eNHf1B3ymKFdZGSov3J3ZnnJwepih5mA=; b=Vr4dYuQ99CAEqd0MlmdzjT5N3SB/l3W2i2NxeCVVAh48vEzc7Ge5b9eYfEUTENlIDd 982Mc8+CMzhxWi9O+i9ajFrRmNeLcIzvOV6KUOvHuMM2WL9umoCLf1V9+g/qDAtNNSjO RX/TkSTUQs1X5lKxDOCHVwaVnOViOsJ9sun9E3akr7stNj+BlrnLKlcXo+r270LsbNEi E6pbeyM0i9khIZV8F6pzjnyM/stTvTuba71kcuD9RRQw12WhNzoogFMWfboyqp8moGSC 8UE/I3RDzJwrVXaauH/pPmvqyJU2brx2370QbCsDuRK93XxsxY/z2mRLBxEKOZgoLSJu viXQ== MIME-Version: 1.0 X-Received: by 10.180.75.144 with SMTP id c16mr13959648wiw.1.1374015450107; Tue, 16 Jul 2013 15:57:30 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 16 Jul 2013 15:57:30 -0700 (PDT) In-Reply-To: References: <00ad01ce826e$43666300$ca332900$@gmail.com> Date: Tue, 16 Jul 2013 15:57:30 -0700 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:57:36 -0000 On 16 July 2013 15:46, Jonathan Lennox wrote: > Have you read http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt ? This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan. I have read that draft. I don't see any major problems with it. That is, aside from some serious ugliness when it comes to no-plan to the extent that I don't believe it to be practical (if I've understood the intent). My current leaning is toward a (small) number if the unified plan is chosen, simply because so much else depends on the existence of signaling; a no-plan-style approach would provide greater motivation for having all the bits present. That said, I don't have enough information yet to be able to make the header extension size vs. need for signaling trade-off. From bernard_aboba@hotmail.com Tue Jul 16 16:21: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 D821221F9D71 for ; Tue, 16 Jul 2013 16:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, 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 s69LXUxNVkvL for ; Tue, 16 Jul 2013 16:21:47 -0700 (PDT) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5821F9E28 for ; Tue, 16 Jul 2013 16:21:46 -0700 (PDT) Received: from BLU401-EAS2 ([65.55.111.72]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 16:21:46 -0700 X-TMN: [+pc7vRCC7QcYknPEK1YGTLacQzCSxO2h4IOb7HuV7Mw=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Tue, 16 Jul 2013 16:21:43 -0700 From: Bernard Aboba To: Jonathan Lennox MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 16 Jul 2013 23:21:46.0115 (UTC) FILETIME=[3D49AD30:01CE827B] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 23:21:52 -0000 The app-id idea is useful for multiple reasons. One reason similar RTP ext= ensions are used today is to avoid having to parse the payload to figure ou= t what the stream is (e.g. looking for parameter sets or SEI NAL units). I= t is cleaner to solve this in as generic rather than a codec-specific way. = I see no conflict with no-plan=3B in fact=2C I believe no plan suggested a= n RTP extension=2C no? Jonathan Lennox wrote: On Jul 16=2C 2013=2C at 4:38 PM=2C Adam Roach wrote: > On 7/16/13 15:28=2C Roni Even wrote: >> Adam=2C >> For correlation when the SSRC is not known in the SDP look at >> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and t= he >> option to use SDES and not only RTP header extension. > > Roni: > > Thanks for the pointer. That's an interesting approach=3B however=2C for > RTCWEB at least=2C need a solution that also works with DTLS-SRTP. Acronym collision: This uses RTCP Source Description packets=2C not SDP Sec= urity Descriptions. I think the (related) app-id approach described in http://tools.ietf.org/ht= ml/draft-even-mmusic-application-token-00.txt will also be of interest. -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Tue Jul 16 16:24: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 4EF5921F9A8E for ; Tue, 16 Jul 2013 16:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hBzX5w-Dz6a for ; Tue, 16 Jul 2013 16:24:44 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE221F9A1D for ; Tue, 16 Jul 2013 16:24:43 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so4744718wiv.13 for ; Tue, 16 Jul 2013 16:24:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=pOLi4QwWcIxiYfQeaT+PfpfdANwphYEJvc9CJywdags=; b=P80Eg3X7nV0ybKiAch/S/FFnQRJw4TQE0eFj7dciuhFr5JLjpwkEgju83ZVuZ8WTMt Mzav6w3RenO/5xYdPtTLhlO2akxxRKD8I36PQByo3odeUkMT0WbdgyJQwOfY3BIVBsin uWyWcRXduJmbH/EAJPDuyNLrQIsztpmxr7FY74+zKGhxtm3nYTjsrRU7VrfcNuJvp0ap 8E7cLzbuGvo8cO+9MbHXOBL/alJJplHwxAdNYoOvphrYshzQ74x/842mcq/9lU2t09Zx 7EOIbTK0FGGtgfWQWx0CfgetJTfArZoIdKe+o1MCsRl4ArVz579akWFVkTj427SiqXfB CfsA== X-Received: by 10.194.8.163 with SMTP id s3mr2947488wja.41.1374017082583; Tue, 16 Jul 2013 16:24:42 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id fd3sm31154550wic.10.2013.07.16.16.24.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 16:24:41 -0700 (PDT) Message-ID: <51E5D637.7010007@jitsi.org> Date: Wed, 17 Jul 2013 01:24:39 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnpXiz7rDbGmOjgDFKsomOIkMBCMa/hfGU+NNV0bQa8MBjfvaMXroxs9eeTKzxGRAlc4v3J Cc: Jonathan Lennox , mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 23:24:48 -0000 On 17.07.13, 01:21, Bernard Aboba wrote: > The app-id idea is useful for multiple reasons. One reason similar > RTP extensions are used today is to avoid having to parse the payload > to figure out what the stream is (e.g. looking for parameter sets or > SEI NAL units). It is cleaner to solve this in as generic rather > than a codec-specific way. I see no conflict with no-plan; +1 > in fact, I believe no plan suggested an RTP extension, no? It did indeed. Emil > Jonathan Lennox wrote: > > > On Jul 16, 2013, at 4:38 PM, Adam Roach wrote: > >> On 7/16/13 15:28, Roni Even wrote: >>> Adam, For correlation when the SSRC is not known in the SDP look >>> at >>> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt >>> and the option to use SDES and not only RTP header extension. >> >> Roni: >> >> Thanks for the pointer. That's an interesting approach; however, >> for RTCWEB at least, need a solution that also works with >> DTLS-SRTP. > > > Acronym collision: This uses RTCP Source Description packets, not SDP > Security Descriptions. > > I think the (related) app-id approach described in > http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt > will also be of interest. > > -- 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 > -- https://jitsi.org From bernard_aboba@hotmail.com Tue Jul 16 16:29: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 0524E21F9D12 for ; Tue, 16 Jul 2013 16:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 iMthKX78IbRR for ; Tue, 16 Jul 2013 16:29:26 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by ietfa.amsl.com (Postfix) with ESMTP id 86BB621F9D02 for ; Tue, 16 Jul 2013 16:29:26 -0700 (PDT) Received: from BLU401-EAS46 ([65.55.111.73]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 16:29:26 -0700 X-TMN: [POv85qtoIDk7LyQQ0/LFxtQzdEIndsh53Z7c5b6OGmY=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Tue, 16 Jul 2013 16:29:22 -0700 From: Bernard Aboba To: Roni Even MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 16 Jul 2013 23:29:26.0300 (UTC) FILETIME=[4F9455C0:01CE827C] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 23:29:32 -0000 Yes=2C it is annoying when new docs attempt to redefine behavior in existin= g deployed RFCs. RFC 5576 has multiple implementations today=2C and none o= f them have a one-at-a-time restriction. The problem with max-send-ssrc is that it conflates ssrcs with streams. If = you have layering or simulcast you need to have something like max-streams = and max-sources. max-send-ssrc is confusing. Roni Even wrote: Hi=2C Some comments. In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why do you want more than one SSRC for m-line but allow only one at a time=2C i= s this for the simulcast case? Others which are not on section 2 1. The document talks about the case when there are multiple participants each sending multiple streams as mentioned in section 1.1.1 and the receive= r may want to select among all these sources as discussed in section 1.1.2. The document focus on the point to point case and does not address the issu= e of how all the m-lines from all participants are distributes and how a late joiner gets all this information. 2. In the examples using the ssrc attribute note that according to RFC 5576 section 4.1 you must provide for each SSRC the CNAME attribute 3. The simulcast example and description allows the case of sending one of the resolutions at a time but in simulcast the source may be able to send multiple resolutions at the same time. To further complicate this case the offer can support three resolutions but can only send any two at a time which the receiver can select. How do you signal this=2C my view is with th= e maxsendssrc attribute. 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an integer) used for correlation=3B" I think that it must be a byte string or token not integer Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: 15 July=2C 2013 10:05 PM > To: mmusic@ietf.org > Cc: rtcweb@ietf.org > Subject: [MMUSIC] Unified Plan for SDP Handling > > [Cross-posting to RTCWEB=3B follow-ups to MMUSIC=2C please] > > After significant work=2C Justin=2C Martin and I have managed to produce = a > compromise plan that provides a high degree of interoperability with existing > devices (and future non-WebRTC devices) while not being excessively > onerous for WebRTC implementations or applications that use them. It's > been a tricky balancing act=2C but I think we've found a good mix between the > two that can form a solid basis for the working group to move forward. > > Rather than summarize the key points of the document in this email=2C I direct > interested parties to section 2 of the document=2C which summarizes the k= ey > aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's actually > been a lot more work put into coming up with a unified draft than I originally > anticipated=2C and the production of this document took at least two week= s > longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done in > this area=2C and not a specification in itself. The intention is that its contents are > used as the basis for work in several other drafts -- some new=2C some no= t -- > that form the corpus of work necessary for RTCWEB (and potentially CLUE) to > move forward. Except in rare cases=2C the document does not attempt to > explicitly call out venues or documents for such work=2C as we (or=2C at = the very > least=2C I) anticipate guidance from the various working group chairs to assist in > such decisions. > > Comments prior to Berlin would be very helpful=2C although this will clea= rly be a > point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Tue Jul 16 16:43: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 44E3721F9D1E for ; Tue, 16 Jul 2013 16:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 Sc5eyccdj5ZR for ; Tue, 16 Jul 2013 16:43:42 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfa.amsl.com (Postfix) with ESMTP id 719CE21F9C7B for ; Tue, 16 Jul 2013 16:43:42 -0700 (PDT) Received: from BLU402-EAS280 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 16:43:41 -0700 X-TMN: [3Xw0WbruEAmN0RCBpNInCTjD7thHRdKn8rWrWada1io=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Tue, 16 Jul 2013 16:43:34 -0700 From: Bernard Aboba To: Roni Even MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 16 Jul 2013 23:43:41.0204 (UTC) FILETIME=[4D245540:01CE827E] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 23:43:54 -0000 IMHO=2C correlation needs to be supported in an RTP extension as well as RT= CP SDES=2C regardless of the SDP discussion. In WebRTC we shouldn't be wedd= ed to SDP signalling and even if we are=2C the dynamism implied by simulcas= t and layered coding can't be accommodated in signalling. Roni Even wrote: Adam=2C For correlation when the SSRC is not known in the SDP look at http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the option to use SDES and not only RTP header extension. BTW: there are other cases when the SSRC is not known using SDP before the RTP stream arrives like when an MCU switch the video. Note that SDES is distributed to the session when the source joins the RTP session which can be long before the RTP media is sent to a specific receiver in the group. Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: 15 July=2C 2013 10:05 PM > To: mmusic@ietf.org > Cc: rtcweb@ietf.org > Subject: [MMUSIC] Unified Plan for SDP Handling > > [Cross-posting to RTCWEB=3B follow-ups to MMUSIC=2C please] > > After significant work=2C Justin=2C Martin and I have managed to produce = a > compromise plan that provides a high degree of interoperability with existing > devices (and future non-WebRTC devices) while not being excessively > onerous for WebRTC implementations or applications that use them. It's > been a tricky balancing act=2C but I think we've found a good mix between the > two that can form a solid basis for the working group to move forward. > > Rather than summarize the key points of the document in this email=2C I direct > interested parties to section 2 of the document=2C which summarizes the k= ey > aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's actually > been a lot more work put into coming up with a unified draft than I originally > anticipated=2C and the production of this document took at least two week= s > longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done in > this area=2C and not a specification in itself. The intention is that its contents are > used as the basis for work in several other drafts -- some new=2C some no= t -- > that form the corpus of work necessary for RTCWEB (and potentially CLUE) to > move forward. Except in rare cases=2C the document does not attempt to > explicitly call out venues or documents for such work=2C as we (or=2C at = the very > least=2C I) anticipate guidance from the various working group chairs to assist in > such decisions. > > Comments prior to Berlin would be very helpful=2C although this will clea= rly be a > point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Tue Jul 16 21:13:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E5821F9B2A for ; Tue, 16 Jul 2013 21:13:04 -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 cceNGkQ2zfw7 for ; Tue, 16 Jul 2013 21:13:03 -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 6D72921F8C0C for ; Tue, 16 Jul 2013 21:13:03 -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 r6H4CtYk056826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 23:12:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E619C2.7080208@nostrum.com> Date: Tue, 16 Jul 2013 23:12:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070802000300070903020003" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:13:04 -0000 This is a multi-part message in MIME format. --------------070802000300070903020003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/16/13 18:29, Bernard Aboba wrote: > Yes, it is annoying when new docs attempt to redefine behavior in existing deployed RFCs. And it's annoying when people try to comment on a proposal based solely on the mailing list discussion as opposed to reading the document in question. Let's set the mudslinging aside for a moment. > RFC 5576 has multiple implementations today, and none of them have a one-at-a-time restriction. Roni was confused, and you're riffing off his confusion. His comment was on the second bullet of section 2, which tries to clear up historical ambiguity by defining clear semantics for what it means to have multiple SSRCs specified in a single m-line IN THE ABSENCE of any signaling indicating their purpose. Now, this clarification is nearly meaningless outside the context of the *first* bullet of section 2, which explains that each m-line corresponds to exactly one media stream track. I suppose it is this context you are missing, because I've worked with you in the past and know that you're smart enough to connect these dots and arrive at the conclusion that the second bullet, combined with the constraint imposed by the first bullet, is making things better, not worse. In case we need to connect the dots for other working group participants, I'll be explicit. There are quite a number of use cases in which it is perfectly reasonable to have several SSRCs associated with a single media stream track, all of which are sent simultaneously. However, without explicit signaling (" Absent any other signaled extension", to use the exact phrase from the draft), there is very little hope of recipients having the first clue about what to do with these simultaneous streams all associated with the same media stream track. So we don't allow that, in general. There's an exception, and it ties back to legacy use. In the preponderance of legacy cases in which a single m-line (historically, transport 5-tuple) was associated with multiple SSRCs, these multiple streams were sent in an exclusive (that is, non-parallel, one-at-a-time) fashion, and were meant to replace each other [1]. To maximize interoperability with legacy systems, the draft takes this (traditionally non-signaled) behavior and makes it the default when multiple SSRCs are present but not otherwise explained by the signaling. The bullet we're discussing requires signaling for all other uses; and, in doing so, effectively forbids multiple SSRCs only in the cases where sending them would be undefined or ambiguous. If you don't think this course of action is a wise decision, please weigh in on the semantics you think should be implied when several SSRCs are present for a single media stream track without explicit signaling about their purpose. It's certainly something that I'd be happy to engage in useful discussion around. We had what I think is sound logic behind our choice, but there's no way we thought of everything. Your insights may be useful. However, simply sniping that you don't like this aspect of the proposal is counter to the goal (which I hope you share) of making progress. /a ___ [1] I recognize that this observation about common historical behavior is based on my own experiences dealing with an admittedly limited set of products, and does not represent an exhaustive survey of the entire implementaion space. I'd love to hear what other people's observations of implementations' intended semantics when multiple SSRCs are present for a single logical stream without any signaling as to their purpose. --------------070802000300070903020003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/16/13 18:29, Bernard Aboba wrote:
Yes, it is annoying when new docs attempt to redefine behavior in existing deployed RFCs.

And it's annoying when people try to comment on a proposal based solely on the mailing list discussion as opposed to reading the document in question.

Let's set the mudslinging aside for a moment.

  RFC 5576 has multiple implementations today, and none of them have a one-at-a-time restriction.

Roni was confused, and you're riffing off his confusion. His comment was on the second bullet of section 2, which tries to clear up historical ambiguity by defining clear semantics for what it means to have multiple SSRCs specified in a single m-line IN THE ABSENCE of any signaling indicating their purpose.

Now, this clarification is nearly meaningless outside the context of the *first* bullet of section 2, which explains that each m-line corresponds to exactly one media stream track. I suppose it is this context you are missing, because I've worked with you in the past and know that you're smart enough to connect these dots and arrive at the conclusion that the second bullet, combined with the constraint imposed by the first bullet, is making things better, not worse.

In case we need to connect the dots for other working group participants, I'll be explicit. There are quite a number of use cases in which it is perfectly reasonable to have several SSRCs associated with a single media stream track, all of which are sent simultaneously. However, without explicit signaling (" Absent any other signaled extension", to use the exact phrase from the draft), there is very little hope of recipients having the first clue about what to do with these simultaneous streams all associated with the same media stream track. So we don't allow that, in general.

There's an exception, and it ties back to legacy use. In the preponderance of legacy cases in which a single m-line (historically, transport 5-tuple) was associated with multiple SSRCs, these multiple streams were sent in an exclusive (that is, non-parallel, one-at-a-time) fashion, and were meant to replace each other [1]. To maximize interoperability with legacy systems, the draft takes this (traditionally non-signaled) behavior and makes it the default when multiple SSRCs are present but not otherwise explained by the signaling. The bullet we're discussing requires signaling for all other uses; and, in doing so, effectively forbids multiple SSRCs only in the cases where sending them would be undefined or ambiguous.

If you don't think this course of action is a wise decision, please weigh in on the semantics you think should be implied when several SSRCs are present for a single media stream track without explicit signaling about their purpose. It's certainly something that I'd be happy to engage in useful discussion around. We had what I think is sound logic behind our choice, but there's no way we thought of everything. Your insights may be useful. However, simply sniping that you don't like this aspect of the proposal is counter to the goal (which I hope you share) of making progress.

/a

___
[1] I recognize that this observation about common historical behavior is based on my own experiences dealing with an admittedly limited set of products, and does not represent an exhaustive survey of the entire implementaion space. I'd love to hear what other people's observations of implementations' intended semantics when multiple SSRCs are present for a single logical stream without any signaling as to their purpose.
--------------070802000300070903020003-- From ron.even.tlv@gmail.com Tue Jul 16 21:18: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 6725121F9B18 for ; Tue, 16 Jul 2013 21:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 Aa4ZxQl9rLMP for ; Tue, 16 Jul 2013 21:18:36 -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 6DCA121F8AA1 for ; Tue, 16 Jul 2013 21:18:36 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so1296295wes.5 for ; Tue, 16 Jul 2013 21:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=1IsnfnUVrgcQdpR5EkRM8PFob/7/5UujkwpoNiLsOhM=; b=nmwG9JRm8w7RT0vzhQGUsgnWB4X9KXaxJyb3hbz56QX1Kx5XWANr6yhvrr6BSRBGP4 GIlIBlmAchhto6Ar13OZGnCnAh2LlyTnLL24LCm/Fj7XEGHFOuNYZUwUUzVAe/FEODvn 2dIYyuiC7jjrPVHF+ibddqVjhHW8+P4pKFRA/MFPS5A3Wmj6e9n9Y0V3K2wTg4F2OYs8 hdFUnbgWjHssMzkvKy16w8O2dvzEmnRlvhWxcgewZQEKOXfERHC94ShCGMUoDKgD9UZc pQ1hbehqbMhvNXzEYEAKK3SME6/BlQSQlEL1h1dlZYJShcgROACPkP49MWPnc/QfjQGZ dkYg== X-Received: by 10.180.183.180 with SMTP id en20mr14216020wic.58.1374034714319; Tue, 16 Jul 2013 21:18:34 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fb2sm32080951wic.4.2013.07.16.21.18.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 21:18:33 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , "'Adam Roach'" References: <51E447C8.1000701@nostrum.com> <009001ce8263$0ed498b0$2c7dca10$@gmail.com> <51E5AF5A.9050405@nostrum.com> In-Reply-To: Date: Wed, 17 Jul 2013 07:16:44 +0300 Message-ID: <00f301ce82a4$74448ca0$5ccda5e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGN3Ok6C3zH+O6O1w6NRgFPJ+xPXAKo9Jt/AuuKkxgDLihfLpmjeacA Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:18:37 -0000 Adam, I gave the wrong link before. I meant the one Jonathan pointed to Roni > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: 17 July, 2013 1:06 AM > To: Adam Roach > Cc: Roni Even; mmusic@ietf.org > Subject: Re: [MMUSIC] Unified Plan for SDP Handling > > > On Jul 16, 2013, at 4:38 PM, Adam Roach wrote: > > > On 7/16/13 15:28, Roni Even wrote: > >> Adam, > >> For correlation when the SSRC is not known in the SDP look at > >> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt > >> and the option to use SDES and not only RTP header extension. > > > > Roni: > > > > Thanks for the pointer. That's an interesting approach; however, for > > RTCWEB at least, need a solution that also works with DTLS-SRTP. > > > Acronym collision: This uses RTCP Source Description packets, not SDP > Security Descriptions. > > I think the (related) app-id approach described in > http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt will > also be of interest. > > -- > Jonathan Lennox > jonathan@vidyo.com From adam@nostrum.com Tue Jul 16 21:25: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 E34EB21F9B5D for ; Tue, 16 Jul 2013 21:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 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 8e2Gj-2Qps2J for ; Tue, 16 Jul 2013 21:25:19 -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 23D8721F9A98 for ; Tue, 16 Jul 2013 21:25:07 -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 r6H4P2gt058078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 23:25:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E61C99.8040305@nostrum.com> Date: Tue, 16 Jul 2013 23:24:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Lennox References: <00ad01ce826e$43666300$ca332900$@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080808080407000601010105" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:25:21 -0000 This is a multi-part message in MIME format. --------------080808080407000601010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/16/13 17:46, Jonathan Lennox wrote: > Have you readhttp://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt ? This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan. Thanks for the pointer -- I had missed this. On a first read, this proposal seems to be backwards from what we need. The token scoping appears to be summed up by the following passage: The token is chosen by the sender, and represents the RTP stream that will be sent to the receiver. What we need is a token chosen by the *receiver* representing what will be sent to the receiver. The crux of the matter is that the recipient may start receiving an RTP stream prior to receiving any signaling from the far end that can be used to correlate a token to the stream. We need to include something in an offer that allows us to correlate streams *before* the answer arrives. That's not to say we couldn't add such functionality to this draft. But, unless I've completely misunderstood the meaning of the passage I quote above, the current application token proposal doesn't solve the clipping problem that we're trying to avoid. /a --------------080808080407000601010105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/16/13 17:46, Jonathan Lennox wrote:
Have you read http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan.

Thanks for the pointer -- I had missed this.

On a first read, this proposal seems to be backwards from what we need. The token scoping appears to be summed up by the following passage:

   The token is chosen by the sender, and represents the RTP stream that
   will be sent to the receiver.

What we need is a token chosen by the *receiver* representing what will be sent to the receiver. The crux of the matter is that the recipient may start receiving an RTP stream prior to receiving any signaling from the far end that can be used to correlate a token to the stream. We need to include something in an offer that allows us to correlate streams *before* the answer arrives.

That's not to say we couldn't add such functionality to this draft. But, unless I've completely misunderstood the meaning of the passage I quote above, the current application token proposal doesn't solve the clipping problem that we're trying to avoid.

/a
--------------080808080407000601010105-- From ron.even.tlv@gmail.com Tue Jul 16 21: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 F420321F9BAD for ; Tue, 16 Jul 2013 21:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 x-I7KXnkzT1R for ; Tue, 16 Jul 2013 21:26:43 -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 A31DE21F9B94 for ; Tue, 16 Jul 2013 21:26:42 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so1311865wgh.23 for ; Tue, 16 Jul 2013 21:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=H8dvqJIBcyqF4mEaIhrGRhnUQlrnDIGlf/SQlP5mPb0=; b=H+yCVsOGhNPt3VQjp3FZ7MQULIEYMY1AMZp14jBBtHX2z5qur8M5YA5W2zj6EbNEV3 WZ4nKhx0CVzTWCzdfj5GioQK/vEjMG7qvSAqbsStWc7Oyz+4Ba8Wzj6YA2xksAPqhvrG jWo37kpJ+7d/6DoRwWp1IbBjpiH5iCuAmOsAI+kQqxPXJaKzi3rsntztlyoY75Y2pPXm hrMaLP+l2I4NoG/nAaD9LnvfC/5wUhdSIYnV88c/UHFI9K0RNMblAG3e9WyosN0LT5eB er9zVQOalXXNpE3yXz+4pu48xwZhydhpwDz1wtPYA6UvDDdeiskqi9oHtjZH8xamypSF PTlA== X-Received: by 10.180.37.7 with SMTP id u7mr9780819wij.4.1374035201647; Tue, 16 Jul 2013 21:26:41 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id j20sm6710939wie.7.2013.07.16.21.26.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 21:26:41 -0700 (PDT) From: "Roni Even" To: "'Adam Roach'" References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> In-Reply-To: <51E5C863.7000101@nostrum.com> Date: Wed, 17 Jul 2013 07:24:53 +0300 Message-ID: <00f401ce82a5$96dfff00$c49ffd00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2iPpx0KPLPKa3FH2FT2Jx+TgF4AKbyZlZmINZzMA= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:26:44 -0000 Hi, > > > 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an > > integer) used for correlation;" I think that it must be a byte string > > or token not integer > > Do you have some rationale for your assertion? > > The goal here is to limit expansion of the RTP packets as much as possible. > Given that there is a natural limit of 65536 streams in a single RTP session, 16 > bits for a correlator seems sufficient. > > /a [Roni Even] This is the syntax of the header extension and extensionattributes in RFC5285. It is a byte string and not an integer From bernard_aboba@hotmail.com Tue Jul 16 22:07: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 546F221F84A8 for ; Tue, 16 Jul 2013 22:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 p9VT9UxzYpl9 for ; Tue, 16 Jul 2013 22:07:36 -0700 (PDT) Received: from blu0-omc1-s10.blu0.hotmail.com (blu0-omc1-s10.blu0.hotmail.com [65.55.116.21]) by ietfa.amsl.com (Postfix) with ESMTP id E331921F92C2 for ; Tue, 16 Jul 2013 22:07:35 -0700 (PDT) Received: from BLU404-EAS239 ([65.55.116.7]) by blu0-omc1-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 22:07:32 -0700 X-TMN: [/FNtsQdOUAk0OFKr8CEtHsYhko8QftNm] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_c1325d40-388e-408f-bc52-82bf96fd61c7_" Date: Tue, 16 Jul 2013 22:07:29 -0700 From: Bernard Aboba To: Adam Roach MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2013 05:07:32.0786 (UTC) FILETIME=[8B447120:01CE82AB] Cc: Jonathan Lennox , mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:07:44 -0000 --_c1325d40-388e-408f-bc52-82bf96fd61c7_ Content-Type: multipart/alternative; boundary="_8b3dddd7-8ed7-4d18-9758-16f259e8f7e7_" --_8b3dddd7-8ed7-4d18-9758-16f259e8f7e7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Indeed=2C unless the RTP extension is self-describing it has to be chosen b= y the receiver in order to provide guidance to the receiver before an answe= r arrives. If it is opaque and chosen by the sender it isn't all that diff= erent from an SSRC chosen by the sender and potentially signalled in the an= swer. Adam Roach wrote: On 7/16/13 17:46=2C Jonathan Lennox wrote: > Have you readhttp://tools.ietf.org/html/draft-even-mmusic-application-tok= en-00.txt ? This is a more fleshed-out version of the same idea=2C as I u= nderstand the idea in Unified=2C written to be agnostic between Plans A / B= / No Plan. Thanks for the pointer -- I had missed this. On a first read=2C this proposal seems to be backwards from what we need. The token scoping appears to be summed up by the following passage: The token is chosen by the sender=2C and represents the RTP stream that will be sent to the receiver. What we need is a token chosen by the *receiver* representing what will be sent to the receiver. The crux of the matter is that the recipient may start receiving an RTP stream prior to receiving any signaling from the far end that can be used to correlate a token to the stream. We need to include something in an offer that allows us to correlate streams *before* the answer arrives. That's not to say we couldn't add such functionality to this draft. But=2C unless I've completely misunderstood the meaning of the passage I quote above=2C the current application token proposal doesn't solve the clipping problem that we're trying to avoid. /a --_8b3dddd7-8ed7-4d18-9758-16f259e8f7e7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Indeed=2C unless the RTP extension is self-describ= ing it has to be chosen by the receiver in order to provide guidance to the= receiver before an answer arrives. =3B If it is opaque and chosen by t= he sender it isn't all that different from an SSRC chosen by the sender and potentially signalled in the answer.

Adam Roach <=3Badam@nostrum.com>=3B wrote:

On 7/16/13 17:46=2C Jonathan Lennox wrote:= 
Have you read http://tools.ie=
tf.org/html/draft-even-mmusic-application-token-00.txt ?  This is a mor=
e fleshed-out version of the same idea=2C as I understand the idea in Unifi=
ed=2C written to be agnostic between Plans A / B / No Plan.

Thanks for the pointer -- I had missed this.

On a first read=2C this proposal seems to be backwards from what we need. T= he token scoping appears to be summed up by the following passage:

   The token is chosen by the sender=2C and repres=
ents the RTP stream that
   will be sent to the receiver.

What we need is a token chosen by the *receiver* representing what will be = sent to the receiver. The crux of the matter is that the recipient may star= t receiving an RTP stream prior to receiving any signaling from the far end= that can be used to correlate a token to the stream. We need to include something in an offer that allows = us to correlate streams *before* the answer arrives.

That's not to say we couldn't add such functionality to this draft. But=2C = unless I've completely misunderstood the meaning of the passage I quote abo= ve=2C the current application token proposal doesn't solve the clipping pro= blem that we're trying to avoid.

/a
--_8b3dddd7-8ed7-4d18-9758-16f259e8f7e7_-- --_c1325d40-388e-408f-bc52-82bf96fd61c7_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_c1325d40-388e-408f-bc52-82bf96fd61c7_-- From ron.even.tlv@gmail.com Tue Jul 16 22:36: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 1F94921F8925 for ; Tue, 16 Jul 2013 22:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 uTezkAVyoHuS for ; Tue, 16 Jul 2013 22:36:24 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5822821F8904 for ; Tue, 16 Jul 2013 22:36:24 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so4942211wid.15 for ; Tue, 16 Jul 2013 22:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=LuqGbBAw/ExCOVV5awvgmAtmxNtz2KJ7i29qomlSZlI=; b=GlfE0Gp/SFfPJ89ZQpi2nq5aP7znks6pj7uPpIMkJ6buuBt9iEMx+OPVDnS75uhAhF wUEnuKXe1FaBHdzlPN2Xb5DAt2MM84prMZ6NCxiENGlsjqJo1d2q5jQcAkSpqvbmfOQh ttTjjO+GODQ4xsSQyj2SsanzgXQJ8qkcl96V5RvMHtZyoZ9WWm7t5ljUBLOjkSjDpQxW p5GrpzfqEEKKOBL8F4G2NuadTqC3Rk/KwAh/avjEKlqG2FIQ03oHvn2YW+A+rJa/TD0e Ay5AU3yBsFBCLj6XfDi7BBbYJ/ApD2x+3aFKG4Lh/US+iCT76tc5ko/gQ+Iz6rUrB4gU DhdQ== X-Received: by 10.194.78.110 with SMTP id a14mr3543675wjx.84.1374039383453; Tue, 16 Jul 2013 22:36:23 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id o10sm6983787wiz.5.2013.07.16.22.36.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 22:36:22 -0700 (PDT) From: "Roni Even" To: "'Adam Roach'" References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> In-Reply-To: <51E5C863.7000101@nostrum.com> Date: Wed, 17 Jul 2013 08:34:34 +0300 Message-ID: <011301ce82af$534d5df0$f9e819d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2iPpx0KPLPKa3FH2FT2Jx+TgF4AKbyZlZmINoo1A= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:36:25 -0000 I think that the problem in bullet 2 of section 2 when reading bullet 1 is that it is not clear. Bullet 1 says "nor may a single m-line represent multiple media stream tracks". Since there is no definition of media stream track in this document and of source I looked at section 2.3 of http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01 which tries to clarify the terminology based on existing documents. To me even though bullet 2 says "in the absent of other signaled extension" it will be not correct according to bullet 1 to have one m-line that have multiple sources (according to my reading of the taxonomy source and media stream track are equivalent) As for "although senders can switch between the SSRCs as frequently as desired, only one should be sent at any given time." It got me confused, in simulcast does it mean that a sender can send one packet of one resolution followed by a packet of a second resolution each has a unique SSRC but they should have a different timestamp. What is "at any given time"? Roni > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 17 July, 2013 1:26 AM > To: Roni Even > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media > sources > > On 7/16/13 16:48, Roni Even wrote: > > Hi, > > Some comments. > > In section 2 bullet 2 is changing RFC 5576 semantics and not for good. > > Why do you want more than one SSRC for m-line but allow only one at a > > time, is this for the simulcast case? > > No, simulcast is signaled explicitly (I will point out and emphasize the phrase > "absent any other signaled extension"). This is "default behavior" is intended > to accommodate MCUs that perform packet switching for RTP (and similar > architectures that require different timing and/or sequence number spaces > on a single stream). > > > Others which are not on section 2 > > > /a From adam@nostrum.com Tue Jul 16 22:52: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 C5D7F21F8FA1 for ; Tue, 16 Jul 2013 22:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 fv0KIsa6rfbQ for ; Tue, 16 Jul 2013 22:52:32 -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 6617D21F89C3 for ; Tue, 16 Jul 2013 22:52:32 -0700 (PDT) Received: from [192.168.0.159] (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 r6H5qQda067212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 00:52:27 -0500 (CDT) (envelope-from adam@nostrum.com) References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> <011301ce82af$534d5df0$f9e819d0$@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <011301ce82af$534d5df0$f9e819d0$@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <70CC1D09-E0BE-432A-BB2A-90B46BCF4973@nostrum.com> X-Mailer: iPad Mail (10B329) From: Adam Roach Date: Wed, 17 Jul 2013 00:52:21 -0500 To: Roni Even Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:52:32 -0000 On Jul 17, 2013, at 0:34, "Roni Even" wrote: > As for "although senders can switch between the SSRCs as frequently as > desired, only one should be sent at any given time." It got me confused= , > in simulcast... This bullet has no bearing on simulcast behavior, other than to say that sim= ulcast must be explicitly signaled. /a= From keith.drage@alcatel-lucent.com Wed Jul 17 04:07: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 C366921F9948; Wed, 17 Jul 2013 04:07:01 -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=[AWL=0.000, 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 E7BkwHXD8h6U; Wed, 17 Jul 2013 04:06:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF521F9D4A; Wed, 17 Jul 2013 04:06:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6HB6nwZ009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:06:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HB6lVR032483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:06:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:06:48 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARA= Date: Wed, 17 Jul 2013 11:06:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [MMUSIC] Taxonomy X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 11:07:02 -0000 Breaking my own rule about cross posting... Just wanted to add is that this document would not be retrospective, i.e. w= e would not start rewriting the existing published RFCs to take into accoun= t the new terminology. The expectation however is that documents going forward from other working = groups would use the new terminology rather than other terms.=20 Obviously how this is handled is up to the individual working groups, but u= sing the new terminology will be the only good way of making your results u= nderstandable outside your specific field. So that is why your review and input is important. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 16 July 2013 15:58 > To: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; > avt@ietf.org > Subject: FW: Taxonomy >=20 > Extensive cross-post do not reply to this email. >=20 > For information. We do expect participation input from all the listed > working groups (and possibly more). >=20 > Keith >=20 > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 15:53 > To: avtext@ietf.org > Subject: [avtext] Taxonomy >=20 > (As AVTEXT WG cochair) >=20 > The latest version of the RTP taxonomy draft has been submitted. >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping- > taxonomy/ >=20 > This document was allocated to AVTEXT by DISPATCH, and we have created a > milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant meeting time discussing the > contents in the AVTEXT meeting in Berlin, so please start raising your > issues on the AVTEXT list. >=20 > Additionally, if there are counter proposals existing that the AVTEXT > chairs would not otherwise be aware of, then please identify them to the > AVTEXT chairs / list. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From ibc@aliax.net Wed Jul 17 04: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 BB27621F9E47 for ; Wed, 17 Jul 2013 04:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 Gg9CvQa09RwN for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31321F9D92 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e11so1014571qcx.10 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EKaU4MI2ZQsAWPvMCk3JxHj6BeoOuRCIjkCYNQ+jx9I=; b=SwV8X2N8VOsu90ecY+6pdf0wZ75/SZYh7E8cNH4WfZrhRMye5LdNJvCIhhcXd5qyAO P3JDt9czvGQpb+TRIJD0NK5kZCCnTveWLVFL5wqCXerY6Jc/Eo4QoWqjU573/dd/zowM fmagoogahbeNK7bs5hrJvu0PmwvhuVMEjTNwiMsUtZM/Hj32rI/kjk42NhW/+s3R7EH9 wbTVNx16IzUcvjMU9ItR7mLHZm92kioV45TrPQDYzGCHSOZmd41SJ0YFGL6FU8p6r9jq 1VY3i/WQwZMbUJrtpH2ZDizdxOUVMSnhO6I4zFxrxwb5ApRIjS7iN/ogX61T2zjKQ5JR DK/g== X-Received: by 10.224.90.1 with SMTP id g1mr8708293qam.0.1374060427977; Wed, 17 Jul 2013 04:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 17 Jul 2013 04:26:47 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 13:26:47 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkKWfKt0DgTBsoswov82Pv9mbCIPNOUM0AbrLD7GLh63F3+VMYcxnp7QTXfus+fZhCtAV0n Cc: "clue@ietf.org" , "dispatch@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [MMUSIC] [dispatch] Taxonomy X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 11:27:12 -0000 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Wed Jul 17 07:09: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 4BDF921E804E for ; Wed, 17 Jul 2013 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.291 X-Spam-Level: X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=0.658, 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 duSM2f1xzdRP for ; Wed, 17 Jul 2013 07:08:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD3F321F999B for ; Wed, 17 Jul 2013 07:08:56 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-a1-51e6a5764383 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7E.8D.05990.675A6E15; Wed, 17 Jul 2013 16:08:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 16:08:54 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Unified Plan for SDP Handling Thread-Index: AQHOgY5x7Vyx1Crt5kGKxBJDnL9f8g== Date: Wed, 17 Jul 2013 14:08:53 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> References: <51E447C8.1000701@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrW750meBBktvcFrs+buI3WLq8scs DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfG+lt72Aumy1TcmHKJrYGxRbyLkZNDQsBE 4szro8wQtpjEhXvr2boYuTiEBA4zSqyd9IUJwlnEKHF/039GkCo2gUCJrfsWsIHYIgLqEl/3 9gB1c3AwCyhKLFurDBIWFjCWeP99HQtEiYnE8523GCFsPYk9cw+BLWMRUJV4fnUaWA2vgK/E 8oWL2EFsIQEtiVdPJ4LVMAId9P3UGiYQm1lAXOLWk/lMEIcKSCzZcx7qaFGJl4//sULYShKN S56wQtTrSdyYOoUNwtaWWLbwNTPELkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJm Tnq50SZGYCwc3PJbdQfjnXMihxilOViUxHk3650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cA489uiioi68rSabo9T2bbGd9+5dqZK/N14vYHDs+nWM6Gz+iY5H3Ler3qek8r4/+CaY5Gq EX/i110y77/BqR2x/deHpHxndflvy+bMcc03ZN77fPfVvtNKd8NTEr8nT2GbvzawKeTTknKJ udl/+4+lT0qTSjXlr/6T7r+kcfuBtS1fJnd1VhkqsRRnJBpqMRcVJwIAtVzW+VMCAAA= Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:09:02 -0000 On 7/15/13 9:06 PM, Adam Roach wrote:=0A= > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please]=0A= >=0A= > After significant work, Justin, Martin and I have managed to produce a=0A= > compromise plan that provides a high degree of interoperability with=0A= > existing devices (and future non-WebRTC devices) while not being=0A= > excessively onerous for WebRTC implementations or applications that use= =0A= > them. It's been a tricky balancing act, but I think we've found a good=0A= > mix between the two that can form a solid basis for the working group to= =0A= > move forward.=0A= =0A= Thanks for doing this work, I hope that we now finally can get going on =0A= specifying this up (and I hope it won't take too long to do so!).=0A= =0A= I think this looks like a really good start, and there is a lot I like =0A= (e.g. the independent signaling per MediaStreamTrack).=0A= =0A= I have a couple of specific questions/comments, coming from a very =0A= WebRTC centric (sorry for that) perspective:=0A= =0A= * Simulcast: In the current API model, MediaStreamTrack is about the =0A= lowest you can get to. And the same source (camera, microphone) can =0A= source several MediaStreamTrack - and each of those can use individual =0A= constraints for width, height, framerate, etc. So in a WebRTC context, =0A= there seem to me we would not need the simulcast solution you have =0A= included. The different resolutions can be sent as different =0A= MediaStreamTrack's - meaning they would be separate m-lines.=0A= =0A= * Direction attribute: The current WebRTC API is "sender" oriented: the =0A= application can select MediaStream(Track)'s to send. Would it for WebRTC = =0A= make sense to have all m-lines being unidirectional (send/recvonly)? (If = =0A= they should be sendrecv we also need to specify when a return track =0A= should reuse an existing m-line, and when a new m-line should be created.)= =0A= =0A= Stefan=0A= =0A= >=0A= > Rather than summarize the key points of the document in this email, I=0A= > direct interested parties to section 2 of the document, which summarizes= =0A= > the key aspects of the plan in eight relatively concise bullet points.=0A= >=0A= > I apologize for the late publication date of this document -- there's=0A= > actually been a lot more work put into coming up with a unified draft=0A= > than I originally anticipated, and the production of this document took= =0A= > at least two weeks longer than I expected it to.=0A= >=0A= > Note that this document is intended to be a plan for the work to be done= =0A= > in this area, and not a specification in itself. The intention is that=0A= > its contents are used as the basis for work in several other drafts --=0A= > some new, some not -- that form the corpus of work necessary for RTCWEB= =0A= > (and potentially CLUE) to move forward. Except in rare cases, the=0A= > document does not attempt to explicitly call out venues or documents for= =0A= > such work, as we (or, at the very least, I) anticipate guidance from the= =0A= > various working group chairs to assist in such decisions.=0A= >=0A= > Comments prior to Berlin would be very helpful, although this will=0A= > clearly be a point of significant discussion at the face-to-face meeting.= =0A= >=0A= > Document link:=0A= >=0A= > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt=0A= >=0A= > /a=0A= > _______________________________________________=0A= > mmusic mailing list=0A= > mmusic@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/mmusic=0A= >=0A= =0A= From pkyzivat@alum.mit.edu Wed Jul 17 09:38: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 11E0521F9D09 for ; Wed, 17 Jul 2013 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[AWL=0.212, 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 bTzZYBJfZVc1 for ; Wed, 17 Jul 2013 09:38:10 -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 DB5A821F9D4F for ; Wed, 17 Jul 2013 09:38:05 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1Q2c1m0060mv7h058Ue5RX; Wed, 17 Jul 2013 16:38:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 1Ue51m00G3ZTu2S3XUe5Hp; Wed, 17 Jul 2013 16:38:05 +0000 Message-ID: <51E6C86C.5020101@alum.mit.edu> Date: Wed, 17 Jul 2013 12:38:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E447C8.1000701@nostrum.com> 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=1374079085; bh=FmySFjbz67z/QV50mf6mv+M6MBDUuL0dSedPKNv8FAI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=doAGp2Zao2QwDWNq3xE1ewUNraoMeThqer5o5wO0fDE2dtylb60wDUHGisKfQ9hec azG91rAtGPHNNcDN15lu3HYShNn1UQ6lJkGUxHRsa9sPTFswR2AYartsfYhJhArkBl HlmF4qKoTg2+pmfkMBzmHPInqyUPEpgK6k6VNsKKVaZTSZcTX8/17EZkfuXuHTcv5n u2904y9vs0cDbFD7R2RZKOBwzPk5cnCVt80E/ubmxvNANsi5q4Wp+5k/ll4u4EbfrG sNdPPFuHjdV7j/v0yEywFFE0OOAc0fUzmo46SvDmPxK+ASs83+uOkf/aRECU1kxTuQ ff/phEUZZzxAg== Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:38:29 -0000 Adam, While I see there can be some value to extending O/A to allow for smaller critical sections, I fear that it is going to be very messy to get "right". Some messy things: - Glare between a partial O/A and a full O/A - Is a partial O/A permitted in a sip reINVITE? Can you have an offerless reINVITE where the response contains a partial offer? Or can these only be done in UPDATE? - In SIP, processing of concurrent reINVITEs/UPDATEs containing partial SDP updates. This seems to already be a - How to assign version numbers to the full SDP as a result of partial updates - I'm not sure your algorithm for resolving glare when adding streams works in all cases. (More below on this.) These (and ones I haven't thought of) *may* all be resolvable. But this certainly complicates the already complex O/A process - maybe to the point that many get it wrong. (I don't want to write rfc6337bis!) My concern with the glare resolution algorithm is that for it to work both sides must realize that glare occurred. And I think there are common sequences when one side won't realize it. I'm reluctant to buy into a scheme that depends on this without knowing it it will be implementable. Thanks, Paul From jonathan@vidyo.com Wed Jul 17 10:07: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 C428021F8FF3 for ; Wed, 17 Jul 2013 10:07:55 -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 1FCEuBLVn5RX for ; Wed, 17 Jul 2013 10:07:51 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id A82A321F84E3 for ; Wed, 17 Jul 2013 10:07:51 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 15E7F557301; Wed, 17 Jul 2013 13:07:50 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 323DE5570AB; Wed, 17 Jul 2013 13:07:46 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 17 Jul 2013 13:05:31 -0400 From: Jonathan Lennox To: Bernard Aboba Date: Wed, 17 Jul 2013 13:07:41 -0400 Thread-Topic: [MMUSIC] Unified Plan for SDP Handling Thread-Index: Ac6DD9doYXIsZIqjSRWj2seGgzELFw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 17:07:55 -0000 On Jul 16, 2013, at 7:21 PM, Bernard Aboba wrot= e: > The app-id idea is useful for multiple reasons. One reason similar RTP e= xtensions are used today is to avoid having to parse the payload to figure = out what the stream is (e.g. looking for parameter sets or SEI NAL units). = =20 That sounds like an interesting idea, but unless I'm misunderstanding you, = that sounds very different from what app-id (or the correlator, in Unified)= is doing. Those are for identifying streams, whereas this sounds more lik= e identifying the sub-structure of a stream (i.e. which packets contain par= ameter sets or SEIs). I could imagine that being useful, but it doesn't sound very related to str= eam correlation. > It is cleaner to solve this in as generic rather than a codec-specific wa= y. I see no conflict with no-plan; in fact, I believe no plan suggested an= RTP extension, no? >=20 > Jonathan Lennox wrote: >=20 >=20 > On Jul 16, 2013, at 4:38 PM, Adam Roach wrote: >=20 >> On 7/16/13 15:28, Roni Even wrote: >>> Adam, >>> For correlation when the SSRC is not known in the SDP look at >>> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and = the >>> option to use SDES and not only RTP header extension. >>=20 >> Roni: >>=20 >> Thanks for the pointer. That's an interesting approach; however, for >> RTCWEB at least, need a solution that also works with DTLS-SRTP. >=20 >=20 > Acronym collision: This uses RTCP Source Description packets, not SDP Sec= urity Descriptions. >=20 > I think the (related) app-id approach described in http://tools.ietf.org/= html/draft-even-mmusic-application-token-00.txt will also be of interest. >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Jonathan Lennox jonathan@vidyo.com From adam@nostrum.com Wed Jul 17 10:07: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 76CBF21F9130 for ; Wed, 17 Jul 2013 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 CiTHc6837f4L for ; Wed, 17 Jul 2013 10:07:58 -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 6BA5521F9011 for ; Wed, 17 Jul 2013 10:07:58 -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 r6HH7tmK047545 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 12:07:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E6CF66.1030309@nostrum.com> Date: Wed, 17 Jul 2013 12:07:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51E447C8.1000701@nostrum.com> <51E6C86C.5020101@alum.mit.edu> In-Reply-To: <51E6C86C.5020101@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------070101020305040305030907" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 17:07:59 -0000 This is a multi-part message in MIME format. --------------070101020305040305030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/13 11:38, Paul Kyzivat wrote: > Adam, > > While I see there can be some value to extending O/A to allow for > smaller critical sections, I fear that it is going to be very messy to > get "right". Some messy things: > > - Glare between a partial O/A and a full O/A ...is glare. Resolve as normal. For SIP, that means timers. > - Is a partial O/A permitted in a sip reINVITE? Can you have > an offerless reINVITE where the response contains a partial offer? > Or can these only be done in UPDATE? No, no, and no. In SIP, the protocol machinery would not allow INVITE or UPDATE to complete concurrently in opposite directions for any amount of overlap. We aren't proposing a change to SIP state machines here, only to the offer/answer model. This necessarily means that we need to carry partial offers and partial answers in something else -- probably INFO. > - In SIP, processing of concurrent reINVITEs/UPDATEs containing > partial SDP updates. This seems to already be a You left this unfinished, but I *think* it was going to make the same point I did in my response above. > - How to assign version numbers to the full SDP as a result > of partial updates Section 3.4.1: "... the SDP version is incremented by one..." > - I'm not sure your algorithm for resolving glare when adding > streams works in all cases. (More below on this.) > > These (and ones I haven't thought of) *may* all be resolvable. But > this certainly complicates the already complex O/A process - maybe to > the point that many get it wrong. (I don't want to write rfc6337bis!) > > My concern with the glare resolution algorithm is that for it to work > both sides must realize that glare occurred. And I think there are > common sequences when one side won't realize it. I'm not saying I didn't miss it, but I did work through as many permutations as I could think of, and none of them are left out by the algorithm described in section 3.4.1. That said, I did my analysis in the context of WebRTC, and assumed a reliable, in-order delivery channel for messages. I recognize that we don't have that for SIP, and that messages in the same direction can be reordered. I admit that this does raise some interesting scenarios that may require additional work to resolve. > I'm reluctant to buy into a scheme that depends on this without > knowing it it will be implementable. I understand your reluctance, and don't want to gloss over it. This is but one plank in the overall plan, and it represents what we think is the best (but not only) solution to this specific requirement. If the issues prove intractable, we could fall back to an alternate scheme, such as the designated-offerer I describe in draft-roach-rtcweb-glareless-add-00, or the token-passing scheme described by Ted Hardie (cf. http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html). /a --------------070101020305040305030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/17/13 11:38, Paul Kyzivat wrote:
Adam,

While I see there can be some value to extending O/A to allow for smaller critical sections, I fear that it is going to be very messy to get "right". Some messy things:

- Glare between a partial O/A and a full O/A

...is glare. Resolve as normal. For SIP, that means timers.

- Is a partial O/A permitted in a sip reINVITE? Can you have
  an offerless reINVITE where the response contains a partial offer?
  Or can these only be done in UPDATE?

No, no, and no. In SIP, the protocol machinery would not allow INVITE or UPDATE to complete concurrently in opposite directions for any amount of overlap. We aren't proposing a change to SIP state machines here, only to the offer/answer model. This necessarily means that we need to carry partial offers and partial answers in something else -- probably INFO.

- In SIP, processing of concurrent reINVITEs/UPDATEs containing
  partial SDP updates. This seems to already be a

You left this unfinished, but I *think* it was going to make the same point I did in my response above.

- How to assign version numbers to the full SDP as a result
  of partial updates

Section 3.4.1: "... the SDP version is incremented by one..."


- I'm not sure your algorithm for resolving glare when adding
  streams works in all cases. (More below on this.)

These (and ones I haven't thought of) *may* all be resolvable. But this certainly complicates the already complex O/A process - maybe to the point that many get it wrong. (I don't want to write rfc6337bis!)

My concern with the glare resolution algorithm is that for it to work both sides must realize that glare occurred. And I think there are common sequences when one side won't realize it.

I'm not saying I didn't miss it, but I did work through as many permutations as I could think of, and none of them are left out by the algorithm described in section 3.4.1.

That said, I did my analysis in the context of WebRTC, and assumed a reliable, in-order delivery channel for messages. I recognize that we don't have that for SIP, and that messages in the same direction can be reordered. I admit that this does raise some interesting scenarios that may require additional work to resolve.

I'm reluctant to buy into a scheme that depends on this without knowing it it will be implementable.

I understand your reluctance, and don't want to gloss over it. This is but one plank in the overall plan, and it represents what we think is the best (but not only) solution to this specific requirement. If the issues prove intractable, we could fall back to an alternate scheme, such as the designated-offerer I describe in draft-roach-rtcweb-glareless-add-00, or the token-passing scheme described by Ted Hardie (cf. http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html).

/a
--------------070101020305040305030907-- From adam@nostrum.com Wed Jul 17 13:23: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 85E4A21F99F1 for ; Wed, 17 Jul 2013 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 j0gu7viYJceC for ; Wed, 17 Jul 2013 13:23:55 -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 45C5D21F99FC for ; Wed, 17 Jul 2013 13:23:51 -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 r6HKNiU5069468 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 15:23:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E6FD4B.3030200@nostrum.com> Date: Wed, 17 Jul 2013 15:23:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <51E447C8.1000701@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:23:55 -0000 On 7/17/13 09:08, Stefan Håkansson LK wrote: > I have a couple of specific questions/comments, coming from a very > WebRTC centric (sorry for that) perspective: > > * Simulcast: In the current API model, MediaStreamTrack is about the > lowest you can get to. And the same source (camera, microphone) can > source several MediaStreamTrack - and each of those can use individual > constraints for width, height, framerate, etc. So in a WebRTC context, > there seem to me we would not need the simulcast solution you have > included. The different resolutions can be sent as different > MediaStreamTrack's - meaning they would be separate m-lines. That's what we meant to convey with this (section 2, bullet 1): "This does not preclude 'application level' simulcasting; i.e., the creation of multiple media stream tracks from a single source." It's true that we don't broach the issue of how to indicate the need for simulcast via a WebRTC javascript API. I think this is something that would be future work, probably in the W3C. I'm going to leave any further explanation to Justin, as most of the simulcast ideas in the document came from him. > * Direction attribute: The current WebRTC API is "sender" oriented: the > application can select MediaStream(Track)'s to send. Would it for WebRTC > make sense to have all m-lines being unidirectional (send/recvonly)? I understand how this makes things cleaner in general. The issue I have is that it interacts poorly with legacy uses. > (If > they should be sendrecv we also need to specify when a return track > should reuse an existing m-line, and when a new m-line should be created.) > I agree that this could stand to be spelled out more clearly. I do not think that doing so will prove particularly controversial. /a From jonathan@vidyo.com Wed Jul 17 14:40: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 46E6521F99F6 for ; Wed, 17 Jul 2013 14:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_14=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 8-4ebSXqsX1R for ; Wed, 17 Jul 2013 14:40:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3953121F99C2 for ; Wed, 17 Jul 2013 14:40:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D89445557EA; Wed, 17 Jul 2013 17:40:11 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5064E5555E1; Wed, 17 Jul 2013 17:40:11 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 17 Jul 2013 17:39:19 -0400 From: Jonathan Lennox To: Adam Roach Date: Wed, 17 Jul 2013 17:40:11 -0400 Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - multiple media sources Thread-Index: Ac6DNeX4Oa//q1ODSSKhJi2sAne0XA== Message-ID: References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E61C99.8040305@nostrum.com> In-Reply-To: <51E61C99.8040305@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:40:18 -0000 On Jul 17, 2013, at 12:24 AM, Adam Roach wrote: > What we need is a token chosen by the *receiver* representing what will b= e sent to the receiver. The crux of the matter is that the recipient may st= art receiving an RTP stream prior to receiving any signaling from the far e= nd that can be used to correlate a token to the stream. We need to include = something in an offer that allows us to correlate streams *before* the answ= er arrives. >=20 > That's not to say we couldn't add such functionality to this draft. But, = unless I've completely misunderstood the meaning of the passage I quote abo= ve, the current application token proposal doesn't solve the clipping probl= em that we're trying to avoid. Ah, interesting. The problem case is an offerer offering a new bundled sen= drecv or recvonly m-line, where the answerer can start sending media for it= immediately, outracing the answer? Yes, I see how a receiver-chosen correlator solves that case. That said, what I still don't see is, if you have the correlator, why you t= hen actually need to send the a=3Dssrc in the SDP at all? The correlator sh= ould be sufficient for disambiguation, and it lets the sender switch the ss= rc it's sending for an m-line without needing a fresh offer/answer. (The use case I'm thinking about here is something like the CLUE "dynamic c= apture" in the context of what Magnus named the "Source-projecting mixer" t= opology -- where the ssrc sent for a given m-line switches dynamically and = quickly, e.g. with loudest-speaker switching.) -- Jonathan Lennox jonathan@vidyo.com From adam@nostrum.com Wed Jul 17 14:44: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 C749821E8055 for ; Wed, 17 Jul 2013 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 AHOjRbC3WiPF for ; Wed, 17 Jul 2013 14:44:59 -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 54D6321E804C for ; Wed, 17 Jul 2013 14:44:59 -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 r6HLitgT078544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 16:44:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E71052.7010206@nostrum.com> Date: Wed, 17 Jul 2013 16:44:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Lennox References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E61C99.8040305@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:44:59 -0000 On 7/17/13 16:40, Jonathan Lennox wrote: > That said, what I still don't see is, if you have the correlator, why you then actually need to send the a=ssrc in the SDP at all? The correlator should be sufficient for disambiguation, and it lets the sender switch the ssrc it's sending for an m-line without needing a fresh offer/answer. That might be worth exploring. I honestly haven't given it a whole lot of thought. Perhaps Justin or Martin have a more well-formed opinion on the topic? /a From fandreas@cisco.com Wed Jul 17 14:49: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 0388421F9D2A for ; Wed, 17 Jul 2013 14:49:36 -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 NdDvCMZUsOCo for ; Wed, 17 Jul 2013 14:49:31 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A26A521F9E7E for ; Wed, 17 Jul 2013 14:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=225; q=dns/txt; s=iport; t=1374097771; x=1375307371; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=CxQl9wBSqMI+osLRMPoEprmOah63Q83HDqs0Rc1kqzE=; b=YeYW5UNh19P8tB9gEdF8dSI0o0H8uAaWs3vDvYOu9v3oHxRDzNprcfWy //HzdGDzGZWt9Jql51cYPRdMM0Y1iUheN8Cip8XYk4Y9W/KfPFWkISLML UOVObnBeMz/pCU2ZS2182aOaR+VhB0TspciVPKMkzGiHr/9DOMpmgjivp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcPAIkQ51GrRDoH/2dsb2JhbABagwY0gw+9dwEBAgEBAoETFnSCYkA9FhgDAgECAUsNCAEBiAsNlVugRQSTfAOXXJFNgy4g X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="86369668" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 17 Jul 2013 21:49:28 +0000 Received: from Flemmings-MacBook-Pro.local ([10.156.8.45]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6HLnRji003927 for ; Wed, 17 Jul 2013 21:49:27 GMT Message-ID: <51E71167.3020203@cisco.com> Date: Wed, 17 Jul 2013 17:49:27 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC Draft Agenda for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:49:36 -0000 The MMUSIC draft agenda for IETF 87 has been posted at: https://datatracker.ietf.org/meeting/87/agenda/mmusic/ Please take a look and let us know if you have any questions or comments. Thanks Ari & Flemming From martin.thomson@gmail.com Wed Jul 17 19:21: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 994FE21F9943 for ; Wed, 17 Jul 2013 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_14=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 GVhnsDlun1lZ for ; Wed, 17 Jul 2013 19:21:23 -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 C417521F96EF for ; Wed, 17 Jul 2013 19:21:22 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so2400925wev.22 for ; Wed, 17 Jul 2013 19:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U3yR16LlqXZggpVXkKqLXK7ZVsLEvYZvGbd6RQn8UPQ=; b=jiUWsykdNUl/bMj2HdopX/CGvkYMc/AV3gJR9nS9KsIm5ElnHdgdcHRnegN9BfM1LR Dlebf9V+AV0xx88/CubZbIjX/jbPfEuf8cnEC549gibUrmy1HqMPn9C1Q2/psrf6ZOsu 5WUDD14LMgVaKsVTIdbDbTTq8C3GAXpWeg1QZj2/fh0JBt+q8HLtCVJrb6dlfJ63RwjG hDuihYUAaHkmClwfUnRznSzNVbVzaUaeUnOE7IvDbEH+OqIWUtCPNs1yB3cV6CZT2b9T uMcKeiHcFMGC6AsSv4hFUC7b91UzIm4NmJNpzNvj2CMHsphyKsoFJJqkhN/0viRl4/6c R/qA== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr17623670wib.65.1374114081927; Wed, 17 Jul 2013 19:21:21 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 17 Jul 2013 19:21:21 -0700 (PDT) In-Reply-To: <51E71052.7010206@nostrum.com> References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E61C99.8040305@nostrum.com> <51E71052.7010206@nostrum.com> Date: Wed, 17 Jul 2013 19:21:21 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:21:23 -0000 On 17 July 2013 14:44, Adam Roach wrote: > On 7/17/13 16:40, Jonathan Lennox wrote: >> >> That said, what I still don't see is, if you have the correlator, why you >> then actually need to send the a=ssrc in the SDP at all? The correlator >> should be sufficient for disambiguation, and it lets the sender switch the >> ssrc it's sending for an m-line without needing a fresh offer/answer. > > > That might be worth exploring. I honestly haven't given it a whole lot of > thought. Perhaps Justin or Martin have a more well-formed opinion on the > topic? I did consider this, but there are several reasons that I prefer to have signaling. The main one being that it is the only guaranteed way to get this information through. In the happy cases, the RTP header is enough, but if you are losing packets at session startup (a real possibility in some configurations), or RTP header extensions are being dropped, or you need to communicate about an in progress stream and can't guarantee that you can cause the sender to re-send a few packets with the header extension, or ... Basically, there are too many ways for the RTP extension to break. Not enough that it isn't hugely valuable for dealing with the race, but it can't be the only mechanism that you rely on. From bernard_aboba@hotmail.com Wed Jul 17 20:35: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 1042F21F9A5F for ; Wed, 17 Jul 2013 20:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 XLmz8BiUKSHB for ; Wed, 17 Jul 2013 20:35:02 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1980621F9655 for ; Wed, 17 Jul 2013 20:35:02 -0700 (PDT) Received: from BLU169-W26 ([65.55.111.136]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 20:35:02 -0700 X-TMN: [UvhbByk067HEg/ekNTBY7vRjDA6aJFlc] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ca3bc5a5-325a-4274-b533-777b1bdfdfbf_" From: Bernard Aboba To: Martin Thomson Date: Wed, 17 Jul 2013 20:35:01 -0700 Importance: Normal In-Reply-To: References: <00ad01ce826e$43666300$ca332900$@gmail.com>, , , <51E61C99.8040305@nostrum.com>, , <51E71052.7010206@nostrum.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2013 03:35:02.0211 (UTC) FILETIME=[C947A930:01CE8367] Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 03:35:15 -0000 --_ca3bc5a5-325a-4274-b533-777b1bdfdfbf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said:=20 > I did consider this=2C but there are several reasons that I prefer to hav= e signaling. =20 =20 [BA] The RTP Extension is by definition=2C optional. So it cannot be used = instead of initial signaling=2C because of reliability issues (same issue a= pplies with SDES packets) and because it might not be there. However=2C in= the event of an SSRC collision it can be useful. Also=2C RTP extensions = are deployed today to label temporal=2C spatial or quality scalability stre= ams=2C so that the SRTP packets don't have to be decrypted and parsed befor= e figuring out what layer they pertain to.=20 = --_ca3bc5a5-325a-4274-b533-777b1bdfdfbf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said:

>=3B I di= d consider this=2C but there are several reasons that I prefer to =3Bha= ve signaling. =3B
 =3B
[BA] The RTP Extension is by definiti= on=2C optional. =3B So it cannot be used instead of initial signaling= =2C because of reliability issues (same issue applies with SDES packets) an= d because it might not be there. =3B =3BHowever=2C in the event of = an SSRC collision =3Bit can be useful.  =3BAlso=2C =3B RTP exte= nsions are deployed today to label temporal=2C spatial or quality scalabili= ty streams=2C so that the SRTP packets don't have to be decrypted and parse= d before figuring out what layer they pertain to.
= --_ca3bc5a5-325a-4274-b533-777b1bdfdfbf_-- From harald@alvestrand.no Thu Jul 18 02:40: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 F3CC111E8101 for ; Thu, 18 Jul 2013 02:40:48 -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_15=0.6, J_CHICKENPOX_17=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 KiKot16e39N6 for ; Thu, 18 Jul 2013 02:40:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8676D21E80AC for ; Thu, 18 Jul 2013 02:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97FF239E238 for ; Thu, 18 Jul 2013 11:40:41 +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 SqqRt+Extbk5 for ; Thu, 18 Jul 2013 11:40:40 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B20FC39E0D7 for ; Thu, 18 Jul 2013 11:40:40 +0200 (CEST) Message-ID: <51E7B818.6000802@alvestrand.no> Date: Thu, 18 Jul 2013 11:40:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Review of unified-plan-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 Jul 2013 09:40:49 -0000 First of all, let me say that I'm very happy to see a plan that the people who have been voicing the strongest opinions in this debate are willing to stand behind. I believe, extremely strongly, that it is better to move forward on one path, no matter what it is (as long as it's not obviously broken), than to continue to debate. This topic has long been needing a decision. Thus, I stand behind the technology proposed, and have no wish to change it. The purpose of this review is to help make sure it's fully described, and that all parties understand it the same way. I have ignored language-only issues at this time. Introduction, paragraph 2: The standard way of encoding this information in SDP is to have each RTP flow (i.e., SSRC) appear on its own m-line. This is not strictly true, since the proposal continues to use each m-line for up to two flows, one in each direction, and some of the . Suggested rephrase: One common way of encoding this information uses each M-line to describe one media source in each direction. "media source" is as defined in draft-westerlund-avtcore-multiplex-architecture-03 section 2.1. The term is used elsewhere in the document, and seems to have this meaning. "One common" is a reflection of my belief that practice has not been uniform in this area. 3.1, Bundle-only M-lines This mechanism requires sending M-lines with port zero as part of a bundle in an SDP OFFER. It needs to note that this specification modifies RFC 5888 section 9.2 (the grouping framework) by allowing such M-lines to be part of a group in an offer (but I do not think it needs to be allowed in an answer). 4.1 Simple example "It also shows unique payload across the audio and video m=lines for the Answerer that does not support BUNDLE semantics." - this doesn't make sense to me; unique payloads are needed for answerers that support BUNDLE semantics. Copy/paste error? Would be consistent if it said "for the Answerer that supports BUNDLE semantics". 4.4 Multiple Video with Simulcast If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, the ssrc-group lines should probably say SCS rather than SIMULCAST. And now for some stuff that isn't in the document, but might want to be: More examples There should probably be one example where the offer contains 1 audio and 2 video streams, and the answer contains 1 audio and 1 video stream (fewer streams in response than in request); I believe that this answer would then contain "a=recvonly" and no "a=msid" attribute on the 3rd m-line, but it's nice to be sure. Interaction with a=content Previously, we had discussed having a "content" attribute on MediaStreamTracks that would make a track link to an m-line with the same "a=content" attribute. If this is still expected to work, it might be worthy of inclusion here. I think that's all for this round of review. Thanks for getting it out! Harald From harald@alvestrand.no Thu Jul 18 05:25: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 7F53311E814D for ; Thu, 18 Jul 2013 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.478 X-Spam-Level: X-Spam-Status: No, score=-110.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-3cpzj8dYv8 for ; Thu, 18 Jul 2013 05:25:55 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AB04F11E813B for ; Thu, 18 Jul 2013 05:25:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA3AF39E0FA for ; Thu, 18 Jul 2013 14:25:47 +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 nK67P-GxTsRB for ; Thu, 18 Jul 2013 14:25:46 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3BF6B39E1CC for ; Thu, 18 Jul 2013 14:25:46 +0200 (CEST) Message-ID: <51E7DEC9.3020802@alvestrand.no> Date: Thu, 18 Jul 2013 14:25:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E71167.3020203@cisco.com> In-Reply-To: <51E71167.3020203@cisco.com> Content-Type: multipart/alternative; boundary="------------010602010005010600090406" Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:25:59 -0000 This is a multi-part message in MIME format. --------------010602010005010600090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/17/2013 11:49 PM, Flemming Andreasen wrote: > The MMUSIC draft agenda for IETF 87 has been posted at: > > https://datatracker.ietf.org/meeting/87/agenda/mmusic/ > > Please take a look and let us know if you have any questions or comments. Hi, I note that AVTEXT's posted agenda: https://datatracker.ietf.org/meeting/87/agenda/avtext/ has them meeting on Tuesday at 1700, and they want to consider the result of MMUSIC's discussions on draft-roach-mmusic-unified-plan - which according to https://datatracker.ietf.org/meeting/87/agenda/mmusic/ will take place on Wednesday, making this a little bit difficult absent temporal manipulation. Perhaps the chairs should consult on whether it's worth swapping the two days of MMUSIC discussion in order to accomodate the AVTEXT linkage? > > Thanks > > Ari & Flemming > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------010602010005010600090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/17/2013 11:49 PM, Flemming Andreasen wrote:
The MMUSIC draft agenda for IETF 87 has been posted at:

https://datatracker.ietf.org/meeting/87/agenda/mmusic/

Please take a look and let us know if you have any questions or comments.

Hi,

I note that AVTEXT's posted agenda:

https://datatracker.ietf.org/meeting/87/agenda/avtext/

has them meeting on Tuesday at 1700, and they want to consider the result of MMUSIC's discussions on draft-roach-mmusic-unified-plan - which according to

https://datatracker.ietf.org/meeting/87/agenda/mmusic/

will take place on Wednesday, making this a little bit difficult absent temporal manipulation.

Perhaps the chairs should consult on whether it's worth swapping the two days of MMUSIC discussion in order to accomodate the AVTEXT linkage?


Thanks

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

--------------010602010005010600090406-- From keith.drage@alcatel-lucent.com Thu Jul 18 05:46: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 758B311E813D for ; Thu, 18 Jul 2013 05:46:18 -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=[AWL=0.000, 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 KnOl3yCs5OVL for ; Thu, 18 Jul 2013 05:46:13 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8AA21E80E0 for ; Thu, 18 Jul 2013 05:46:11 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6ICk50t016052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jul 2013 07:46:07 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6ICk0V7019828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 14:46:02 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 14:46:01 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] MMUSIC Draft Agenda for IETF 87 Thread-Index: AQHOg7IEquvwH4osDkel9YL+QyfPsplqXp2A Date: Thu, 18 Jul 2013 12:46:00 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06C8B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51E71167.3020203@cisco.com> <51E7DEC9.3020802@alvestrand.no> In-Reply-To: <51E7DEC9.3020802@alvestrand.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:46:18 -0000 Ideally, AVTEXT (as in the AVTEXT chairs) would have liked the MMUSIC discu= ssion first, but I suspect they are dealing with a whole lot of other sched= uling problems. I'd also note that the AVTEXT agenda point relates to one very small part o= f this discussion. There have been a number of mentions of the need for RTP header extensions,= which are therefore within the scope of AVTEXT. Timescales are getting sho= rter and shorter for this to happen, so we want to open up some information= exchange about: 1) Is this a sensible usage of a RTP header extension; 2) What we need to do (and that is "we" as in IETF as a whole) to make this= happen. I may be wrong, and if need be we'll have one slide per solution, but I sus= pect all the discussions that identify a need for an RTP header extension a= re trying to address a similar problem. It may be that we can corner the va= rious authors into a hallway discussion on Monday and get them to come up w= ith a single idea of what is needed. That means we don't necessarily need the MMUSIC discussion to happen first,= even if it makes any AVTEXT discussion results conditional on MMUSIC makin= g some form of agreement. The AVTEXT chairs would welcome any input to this. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 18 July 2013 13:26 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 >=20 > On 07/17/2013 11:49 PM, Flemming Andreasen wrote: >=20 >=20 > The MMUSIC draft agenda for IETF 87 has been posted at: >=20 > https://datatracker.ietf.org/meeting/87/agenda/mmusic/ >=20 > Please take a look and let us know if you have any questions or > comments. >=20 >=20 >=20 > Hi, >=20 > I note that AVTEXT's posted agenda: >=20 > https://datatracker.ietf.org/meeting/87/agenda/avtext/ >=20 > has them meeting on Tuesday at 1700, and they want to consider the result > of MMUSIC's discussions on draft-roach-mmusic-unified-plan - which > according to >=20 > https://datatracker.ietf.org/meeting/87/agenda/mmusic/ >=20 > will take place on Wednesday, making this a little bit difficult absent > temporal manipulation. >=20 > Perhaps the chairs should consult on whether it's worth swapping the two > days of MMUSIC discussion in order to accomodate the AVTEXT linkage? >=20 >=20 >=20 >=20 > Thanks >=20 > Ari & Flemming > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 From keith.drage@alcatel-lucent.com Thu Jul 18 05:55: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 2F8AE11E813D for ; Thu, 18 Jul 2013 05:55:13 -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=[AWL=0.000, 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 32iiMded5EBw for ; Thu, 18 Jul 2013 05:54:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8321E80DF for ; Thu, 18 Jul 2013 05:54:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6ICsfSn024664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jul 2013 07:54:43 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6ICsfcv026056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 14:54:41 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 14:54:41 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] MMUSIC Draft Agenda for IETF 87 Thread-Index: AQHOg7IEquvwH4osDkel9YL+QyfPsplqXp2AgAAFdhA= Date: Thu, 18 Jul 2013 12:54:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06C8DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51E71167.3020203@cisco.com> <51E7DEC9.3020802@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B06C8B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06C8B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 12:55:13 -0000 Just to also note that we haven't directly yet opened up a discussion with = the MMUSIC chairs on this, AVTEXT chairs were busy working out what they wa= nted to cover last night before we hit the agenda deadline. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 18 July 2013 13:46 > To: Harald Alvestrand; mmusic@ietf.org > Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 >=20 > Ideally, AVTEXT (as in the AVTEXT chairs) would have liked the MMUSIC > discussion first, but I suspect they are dealing with a whole lot of othe= r > scheduling problems. >=20 > I'd also note that the AVTEXT agenda point relates to one very small part > of this discussion. >=20 > There have been a number of mentions of the need for RTP header extension= s, > which are therefore within the scope of AVTEXT. Timescales are getting > shorter and shorter for this to happen, so we want to open up some > information exchange about: >=20 > 1) Is this a sensible usage of a RTP header extension; > 2) What we need to do (and that is "we" as in IETF as a whole) to make > this happen. >=20 > I may be wrong, and if need be we'll have one slide per solution, but I > suspect all the discussions that identify a need for an RTP header > extension are trying to address a similar problem. It may be that we can > corner the various authors into a hallway discussion on Monday and get > them to come up with a single idea of what is needed. >=20 > That means we don't necessarily need the MMUSIC discussion to happen firs= t, > even if it makes any AVTEXT discussion results conditional on MMUSIC > making some form of agreement. >=20 > The AVTEXT chairs would welcome any input to this. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > > Of Harald Alvestrand > > Sent: 18 July 2013 13:26 > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 > > > > On 07/17/2013 11:49 PM, Flemming Andreasen wrote: > > > > > > The MMUSIC draft agenda for IETF 87 has been posted at: > > > > https://datatracker.ietf.org/meeting/87/agenda/mmusic/ > > > > Please take a look and let us know if you have any questions or > > comments. > > > > > > > > Hi, > > > > I note that AVTEXT's posted agenda: > > > > https://datatracker.ietf.org/meeting/87/agenda/avtext/ > > > > has them meeting on Tuesday at 1700, and they want to consider the > result > > of MMUSIC's discussions on draft-roach-mmusic-unified-plan - which > > according to > > > > https://datatracker.ietf.org/meeting/87/agenda/mmusic/ > > > > will take place on Wednesday, making this a little bit difficult absent > > temporal manipulation. > > > > Perhaps the chairs should consult on whether it's worth swapping the tw= o > > days of MMUSIC discussion in order to accomodate the AVTEXT linkage? > > > > > > > > > > Thanks > > > > Ari & Flemming > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.belling@nsn.com Thu Jul 18 06:06: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 6AAA211E813B for ; Thu, 18 Jul 2013 06:06:17 -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_14=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 za+S+SnLx2ki for ; Thu, 18 Jul 2013 06:06:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BF2F511E8132 for ; Thu, 18 Jul 2013 06:06:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6ID65Kd001312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 15:06:08 +0200 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6ID652a007730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 15:06:05 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 15:06:05 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.212]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 15:06:04 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: "mmusic@ietf.org" , ext Adam Roach Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track Thread-Index: AQHOg7eP8agj5MucQUyNspbOl23nzA== Date: Thu, 18 Jul 2013 13:06:04 +0000 Message-ID: References: <51E447C8.1000701@nostrum.com> In-Reply-To: <51E447C8.1000701@nostrum.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5000 X-purgate-ID: 151667::1374152768-000017BA-072D70F7/0-0/0-0 Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 13:06:17 -0000 Dear Adam, all, good to see significant progress. One aspect I still struggle to understand is the need for the "msid" attrib= ute. The draft says: 2. Solution Overview At a high level, the solution described in this document can be summarized as follows: 1. Each media stream track is represented by its own unique m-line. This is a strict one-to-one mapping; a single media stream track cannot be spread across several m-lines, nor may a single m-line represent multiple media stream tracks. ... 3. Each m-line contains an MSID value to correlate it with a Media Stream ID and the Media Stream Track ID. 3.2.2. Correlating Media Stream Tracks with m-lines Media Stream Tracks IDs are correlated with M-Lines directly by including an MSID in each m-line. The MSID also provides the Media Stream ID. (Note the format of the MSID used here is slightly different than what was proposed in the current MSID draft as that draft assumed multiple tracks in a single m-line and this proposal moves to a solution where there is a one to one relation between the Track and MSID. This work assumes the MSID draft will be updated to match the syntax used user which simply provides the value of the MediaStream ID and MediaStreamTrack ID on an "a=3Dmsid" line. ) The draft lacks a related references, but seems to refer to draft-ietf-mmus= ic-msid-00. However, it is assuming some not yet documented modifications o= f that draft, which does not simplify the understanding (hopefully only a p= roblem for a short time). What you have in mind seems no longer an extensio= n of the a=3Dssrc attribute but an own SDP attribute.=20 Unfortunately there is no definition of media stream track. More fundamentally, do we require the term "media stream track" at all (rat= her than simply speaking about m-lines), if there is a one-to-one mapping t= o a unique m-line? And do we require an extra identifier for it, in addition of the position (= that could also be expressed by an ordinal number in some separate protocol= or for cross-referencing within SDP) of the m-line in the SDP? I suspect the need for a new identifier of the m-line/media stream track ha= s something to do with partial SDP offers? But could the identifier not sti= ll be the ordinal number with respect to the "full" SDP (or the next free n= umber if an m-line is added), and be restricted to partial offers? The msid attribute also assings a "media stream ID", but your draft does no= t describe at all what that ID would be used for. Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Adam Roach Sent: Monday, July 15, 2013 9:05 PM To: mmusic@ietf.org Cc: rtcweb@ietf.org Subject: [MMUSIC] Unified Plan for SDP Handling [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] After significant work, Justin, Martin and I have managed to produce a comp= romise plan that provides a high degree of interoperability with existing d= evices (and future non-WebRTC devices) while not being excessively onerous = for WebRTC implementations or applications that use them. It's been a trick= y balancing act, but I think we've found a good mix between the two that ca= n form a solid basis for the working group to move forward. Rather than summarize the key points of the document in this email, I direc= t interested parties to section 2 of the document, which summarizes the key= aspects of the plan in eight relatively concise bullet points. I apologize for the late publication date of this document -- there's actua= lly been a lot more work put into coming up with a unified draft than I ori= ginally anticipated, and the production of this document took at least two = weeks longer than I expected it to. Note that this document is intended to be a plan for the work to be done in= this area, and not a specification in itself. The intention is that its co= ntents are used as the basis for work in several other drafts -- some new, = some not -- that form the corpus of work necessary for RTCWEB (and potentia= lly CLUE) to move forward. Except in rare cases, the document does not atte= mpt to explicitly call out venues or documents for such work, as we (or, at= the very least, I) anticipate guidance from the various working group chai= rs to assist in such decisions. Comments prior to Berlin would be very helpful, although this will clearly = be a point of significant discussion at the face-to-face meeting. Document link: http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Thu Jul 18 06:41: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 DF28F11E813D for ; Thu, 18 Jul 2013 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 eD7xU9k3+xhm for ; Thu, 18 Jul 2013 06:41:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E162521E80F3 for ; Thu, 18 Jul 2013 06:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4E4639E23A for ; Thu, 18 Jul 2013 15:40:44 +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 YUTcT60vKxF5 for ; Thu, 18 Jul 2013 15:40:43 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EC5DB39E0FA for ; Thu, 18 Jul 2013 15:40:42 +0200 (CEST) Message-ID: <51E7F05A.6070401@alvestrand.no> Date: Thu, 18 Jul 2013 15:40:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E447C8.1000701@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020208080909080206000004" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 13:41:09 -0000 This is a multi-part message in MIME format. --------------020208080909080206000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Adam, all, > > > good to see significant progress. > > > One aspect I still struggle to understand is the need for the "msid" attribute. > > > > The draft says: > > 2. Solution Overview > > At a high level, the solution described in this document can be > summarized as follows: > > 1. Each media stream track is represented by its own unique m-line. > This is a strict one-to-one mapping; a single media stream track > cannot be spread across several m-lines, nor may a single m-line > represent multiple media stream tracks. ... > > 3. Each m-line contains an MSID value to correlate it with a Media > Stream ID and the Media Stream Track ID. > > > 3.2.2. Correlating Media Stream Tracks with m-lines > > Media Stream Tracks IDs are correlated with M-Lines directly by > including an MSID in each m-line. The MSID also provides the Media > Stream ID. (Note the format of the MSID used here is slightly > different than what was proposed in the current MSID draft as that > draft assumed multiple tracks in a single m-line and this proposal > moves to a solution where there is a one to one relation between the > Track and MSID. This work assumes the MSID draft will be updated to > match the syntax used user which simply provides the value of the > MediaStream ID and MediaStreamTrack ID on an "a=msid" line. ) > > > The draft lacks a related references, but seems to refer to draft-ietf-mmusic-msid-00. However, it is assuming some not yet documented modifications of that draft, which does not simplify the understanding (hopefully only a problem for a short time). What you have in mind seems no longer an extension of the a=ssrc attribute but an own SDP attribute. I'll fix the MSID draft once I-D submission reopens. Yes, when an MSID is to be assigned for a whole M-line, it needs to be its own attribute, not an a=ssrc attribute (and that is the only change that needs to be made, I think). > > > Unfortunately there is no definition of media stream track. > > More fundamentally, do we require the term "media stream track" at all (rather than simply speaking about m-lines), if there is a one-to-one mapping to a unique m-line? I think it would actually be better if this draft talked in terms of media sources (as defined in the taxonomy draft I noted in my review), and just mentioned that in the case of WebRTC, a media source corresponds to the JavaScript object called MediaStreamTrack. > And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP? > I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers? > > > The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for. The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes > > > > Thomas > > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Adam Roach > Sent: Monday, July 15, 2013 9:05 PM > To: mmusic@ietf.org > Cc: rtcweb@ietf.org > Subject: [MMUSIC] Unified Plan for SDP Handling > > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] > > After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward. > > Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions. > > Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020208080909080206000004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote:
Dear Adam, all,


good to see significant progress.


One aspect I still struggle to understand is the need for the "msid" attribute.



The draft says:

2.  Solution Overview

   At a high level, the solution described in this document can be
   summarized as follows:

   1.  Each media stream track is represented by its own unique m-line.
       This is a strict one-to-one mapping; a single media stream track
       cannot be spread across several m-lines, nor may a single m-line
       represent multiple media stream tracks. ...

   3.  Each m-line contains an MSID value to correlate it with a Media
       Stream ID and the Media Stream Track ID.


3.2.2.  Correlating Media Stream Tracks with m-lines

   Media Stream Tracks IDs are correlated with M-Lines directly by
   including an MSID in each m-line.  The MSID also provides the Media
   Stream ID.  (Note the format of the MSID used here is slightly
   different than what was proposed in the current MSID draft as that
   draft assumed multiple tracks in a single m-line and this proposal
   moves to a solution where there is a one to one relation between the
   Track and MSID.  This work assumes the MSID draft will be updated to
   match the syntax used user which simply provides the value of the
   MediaStream ID and MediaStreamTrack ID on an "a=msid" line.  )


The draft lacks a related references, but seems to refer to draft-ietf-mmusic-msid-00. However, it is assuming some not yet documented modifications of that draft, which does not simplify the understanding (hopefully only a problem for a short time). What you have in mind seems no longer an extension of the a=ssrc attribute but an own SDP attribute.

I'll fix the MSID draft once I-D submission reopens. Yes, when an MSID is to be assigned for a whole M-line, it needs to be its own attribute, not an a=ssrc attribute (and that is the only change that needs to be made, I think).


Unfortunately there is no definition of media stream track.

More fundamentally, do we require the term "media stream track" at all (rather than simply speaking about m-lines), if there is a one-to-one mapping to a unique m-line?

I think it would actually be better if this draft talked in terms of media sources (as defined in the taxonomy draft I noted in my review), and just mentioned that in the case of WebRTC, a media source corresponds to the JavaScript object called MediaStreamTrack.

And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP?
I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers?


The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.

The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes 



Thomas



---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 




-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Adam Roach
Sent: Monday, July 15, 2013 9:05 PM
To: mmusic@ietf.org
Cc: rtcweb@ietf.org
Subject: [MMUSIC] Unified Plan for SDP Handling

[Cross-posting to RTCWEB; follow-ups to MMUSIC, please]

After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward.

Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points.

I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to.

Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions.

Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting.

Document link:

http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt

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

--------------020208080909080206000004-- From thomas.belling@nsn.com Thu Jul 18 07:21: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 3CBA921E8101 for ; Thu, 18 Jul 2013 07:21:37 -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, 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 2g3XbxFuZbV8 for ; Thu, 18 Jul 2013 07:21:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCA11E80E3 for ; Thu, 18 Jul 2013 07:21:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6IELDhf011497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 16:21:14 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6IELDG7026666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 16:21:13 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 16:21:13 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.212]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 16:21:13 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track Thread-Index: AQHOg7eYiqJibBkYeUq8/d0kMSi315lqT9QAgAAmLvA= Date: Thu, 18 Jul 2013 14:21:13 +0000 Message-ID: References: <51E447C8.1000701@nostrum.com> <51E7F05A.6070401@alvestrand.no> In-Reply-To: <51E7F05A.6070401@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F351179DEDEMUMBX001nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9434 X-purgate-ID: 151667::1374157274-000017BA-0BAC7E10/0-0/0-0 Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:21:37 -0000 --_000_BDBE1A97E84675488F72A48C23811F351179DEDEMUMBX001nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Harald, I understand the Media Stream ID and Media Stream Track ID appear in the W3= C API. However, this does not necessarily mean they need to be signaled end-to-end= (rather than being only of local significance for the interactions between= the JavaScript application and the API, and being mapped to/from some othe= r SDP properties such as the ordinal number of the SDP m-line). If something important was missing in SDP up to now, we certainly need to a= dd it. But we should not duplicate information. This is what I try to find = out. And obviously, requiring mandatory SDP extensions does not simplify in= teroperability with existing SDP peers. Thomas From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Harald Alvestrand Sent: Thursday, July 18, 2013 3:41 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and me= dia stream track On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote: ... And do we require an extra identifier for it, in addition of the position (= that could also be expressed by an ordinal number in some separate protocol= or for cross-referencing within SDP) of the m-line in the SDP? I suspect the need for a new identifier of the m-line/media stream track ha= s something to do with partial SDP offers? But could the identifier not sti= ll be the ordinal number with respect to the "full" SDP (or the next free n= umber if an m-line is added), and be restricted to partial offers? The msid attribute also assings a "media stream ID", but your draft does no= t describe at all what that ID would be used for. The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/= editor/getusermedia.html#attributes --_000_BDBE1A97E84675488F72A48C23811F351179DEDEMUMBX001nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Harald,=

 <= /p>

I understa= nd the Media Stream ID and Media Stream Track ID appear in the W3C API.

 = ;

However, t= his does not necessarily mean they need to be signaled end-to-end (rather t= han being only of local significance for the interactions between the JavaScript application and the API, and being mapped to/from s= ome other SDP properties such as the ordinal number of the SDP m-line).

 = ;

If somethi= ng important was missing in SDP up to now, we certainly need to add it. But= we should not duplicate information. This is what I try to find out. And obviously, requiring mandatory SDP extensions does not simpl= ify interoperability with existing SDP peers.

 = ;

Thomas

 = ;

From:= mmusic-bounces@ietf= .org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute= and media stream track

 

On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Mu= nich) wrote:

…

 
And do we require an extra identifier for it, in addition of the posit=
ion (that could also be expressed by an ordinal number in some separate pro=
tocol or for cross-referencing within SDP) of the m-line in the SDP?
I suspect the need for a new identifier of the m-line/media stream tra=
ck has something to do with partial SDP offers? But could the identifier no=
t still be the ordinal number with respect to the "full" SDP (or =
the next free number if an m-line is added), and be restricted to partial o=
ffers?
 
 
The msid attribute also assings a "media stream ID", but you=
r draft does not describe at all what that ID would be used for.=


The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes = 

 
 
 
--_000_BDBE1A97E84675488F72A48C23811F351179DEDEMUMBX001nsnintr_-- From harald@alvestrand.no Thu Jul 18 07:51: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 5FEAE21E810B for ; Thu, 18 Jul 2013 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7gS5-H76UNS for ; Thu, 18 Jul 2013 07:51:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B4E8E21F94DC for ; Thu, 18 Jul 2013 07:51:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DD1939E1C9; Thu, 18 Jul 2013 16:51:05 +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 8UGCpNasL-Qn; Thu, 18 Jul 2013 16:51:03 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A488B39E0FA; Thu, 18 Jul 2013 16:51:03 +0200 (CEST) Message-ID: <51E800D7.3080207@alvestrand.no> Date: Thu, 18 Jul 2013 16:51:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <51E447C8.1000701@nostrum.com> <51E7F05A.6070401@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050403040100090507060703" Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:51:33 -0000 This is a multi-part message in MIME format. --------------050403040100090507060703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Munich) wrote: > > Thanks Harald, > > I understand the Media Stream ID and Media Stream Track ID appear in > the W3C API. > > However, this does not necessarily mean they need to be signaled > end-to-end (rather than being only of local significance for the > interactions between the JavaScript application and the API, and being > mapped to/from some other SDP properties such as the ordinal number of > the SDP m-line). > Well... if we want to have the same ID attached to the same MediaStreamTrack at both ends, the ID has to be carried somehow. If there's no need for the ID to be the same, we don't need it. But so far, I think the consensus in the W3C WG is that it needs to be the same. > If something important was missing in SDP up to now, we certainly need > to add it. But we should not duplicate information. This is what I try > to find out. And obviously, requiring mandatory SDP extensions does > not simplify interoperability with existing SDP peers. > That's why the MSID spec has a section on what to do when you get tracks without MSIDs. > Thomas > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *ext Harald Alvestrand > *Sent:* Thursday, July 18, 2013 3:41 PM > *To:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute > and media stream track > > On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote: > > ... > > > And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP? > I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers? > > > The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for. > > > The ID of a WEBRTC MediaStream is defined in > http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes > > > > --------------050403040100090507060703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Munich) wrote:

Thanks Harald,

 

I understand the Media Stream ID and Media Stream Track ID appear in the W3C API.

 

However, this does not necessarily mean they need to be signaled end-to-end (rather than being only of local significance for the interactions between the JavaScript application and the API, and being mapped to/from some other SDP properties such as the ordinal number of the SDP m-line).


Well... if we want to have the same ID attached to the same MediaStreamTrack at both ends, the ID has to be carried somehow.

If there's no need for the ID to be the same, we don't need it. But so far, I think the consensus in the W3C WG is that it needs to be the same.

 

If something important was missing in SDP up to now, we certainly need to add it. But we should not duplicate information. This is what I try to find out. And obviously, requiring mandatory SDP extensions does not simplify interoperability with existing SDP peers.


That's why the MSID spec has a section on what to do when you get tracks without MSIDs.

 

Thomas

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

 

On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote:

…

 
And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP?
I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers?
 
 
The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.


The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes 

 
 
 

--------------050403040100090507060703-- From thomas.belling@nsn.com Thu Jul 18 08:18: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 32FA621E8108 for ; Thu, 18 Jul 2013 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 iRGRfT1Te0zn for ; Thu, 18 Jul 2013 08:18:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B921E80F5 for ; Thu, 18 Jul 2013 08:18:30 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6IFIPGK024936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 17:18:25 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6IFIP0l027215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 17:18:25 +0200 Received: from DEMUHTC015.nsn-intra.net (10.159.42.46) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 17:18:24 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.212]) by DEMUHTC015.nsn-intra.net ([10.159.42.46]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 17:18:24 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Harald Alvestrand Thread-Topic: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track Thread-Index: AQHOg7eYiqJibBkYeUq8/d0kMSi315lqhQeDgAACXAA= Date: Thu, 18 Jul 2013 15:18:24 +0000 Message-ID: References: <51E447C8.1000701@nostrum.com> <51E7F05A.6070401@alvestrand.no> <51E800D7.3080207@alvestrand.no> In-Reply-To: <51E800D7.3080207@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] Content-Type: multipart/alternative; boundary="_000_BDBE1A97E84675488F72A48C23811F35117A17DEMUMBX001nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 16942 X-purgate-ID: 151667::1374160705-00002EAE-2BB55662/0-0/0-0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 15:18:36 -0000 --_000_BDBE1A97E84675488F72A48C23811F35117A17DEMUMBX001nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is where my confusion starts: The MSID draft, and also your related backward compatibility procedures, as= sumes that multiple tracks can be described by one m-line. This is no longer true. For the MediaStreamTrack ID, I still suspect that a standardized mapping to= m-line ordinal numbers could now be sufficient to have the same IDs at bot= h sides For the MediaStream, the API description says: Each MediaStream object can contain zero or more tracks, in particular aud= io and video tracks. All tracks in a MediaStream are intended to be synchro= nized when rendered. Different MediaStreams do not need to be synchronized. This sounds like a lipsynch group in SDP. The group name can then serve as MediaStrem ID. Each m-line outside such a= group would probably have a separate MediaStream, and the m-line ordinal = number could then serve as MediaStream ID. From: ext Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Thursday, July 18, 2013 4:51 PM To: Belling, Thomas (NSN - DE/Munich) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and me= dia stream track On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Munich) wrote: Thanks Harald, I understand the Media Stream ID and Media Stream Track ID appear in the W3= C API. However, this does not necessarily mean they need to be signaled end-to-end= (rather than being only of local significance for the interactions between= the JavaScript application and the API, and being mapped to/from some othe= r SDP properties such as the ordinal number of the SDP m-line). Well... if we want to have the same ID attached to the same MediaStreamTrac= k at both ends, the ID has to be carried somehow. If there's no need for the ID to be the same, we don't need it. But so far,= I think the consensus in the W3C WG is that it needs to be the same. If something important was missing in SDP up to now, we certainly need to a= dd it. But we should not duplicate information. This is what I try to find = out. And obviously, requiring mandatory SDP extensions does not simplify in= teroperability with existing SDP peers. That's why the MSID spec has a section on what to do when you get tracks wi= thout MSIDs. Thomas From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of ext Harald Alvestrand Sent: Thursday, July 18, 2013 3:41 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and me= dia stream track On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote: ... And do we require an extra identifier for it, in addition of the position (= that could also be expressed by an ordinal number in some separate protocol= or for cross-referencing within SDP) of the m-line in the SDP? I suspect the need for a new identifier of the m-line/media stream track ha= s something to do with partial SDP offers? But could the identifier not sti= ll be the ordinal number with respect to the "full" SDP (or the next free n= umber if an m-line is added), and be restricted to partial offers? The msid attribute also assings a "media stream ID", but your draft does no= t describe at all what that ID would be used for. The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/= editor/getusermedia.html#attributes --_000_BDBE1A97E84675488F72A48C23811F35117A17DEMUMBX001nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is wh= ere my confusion starts:

The MSID d= raft, and also your related backward compatibility procedures, assumes that= multiple tracks can be described by one m-line.

This is no= longer true.

 = ;

For the Me= diaStreamTrack ID, I still suspect that a standardized mapping to m-line or= dinal numbers could now be sufficient to have the same IDs at both sides

 = ;

 = ;

For the Me= diaStream, the API description says:

Each MediaStream object can contain zero or more tracks, in particular audio and video trac= ks. All tracks in a MediaStream are intended to be synchronized when render= ed. Different MediaStreams do not need to be synchronized.

 = ;

This sound= s like a lipsynch group in SDP.

The group = name can then serve as MediaStrem ID.  Each m-line outside such a grou= p would probably have a separate MediaStream,  and the m-line ordinal number could then serve as MediaStream ID.

 = ;

 = ;

 = ;

From:= ext Harald Alvestra= nd [mailto:harald@alvestrand.no]
Sent: Thursday, July 18, 2013 4:51 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute= and media stream track

 

On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Mu= nich) wrote:

Thanks Harald,

 <= /p>

I understa= nd the Media Stream ID and Media Stream Track ID appear in the W3C API.

 

However, t= his does not necessarily mean they need to be signaled end-to-end (rather t= han being only of local significance for the interactions between the JavaScript application and the API, and being mapped to/from s= ome other SDP properties such as the ordinal number of the SDP m-line).


Well... if we want to have the same ID attached to the same MediaStreamTrac= k at both ends, the ID has to be carried somehow.

If there's no need for the ID to be the same, we don't need it. But so far,= I think the consensus in the W3C WG is that it needs to be the same.


 

If somethi= ng important was missing in SDP up to now, we certainly need to add it. But= we should not duplicate information. This is what I try to find out. And obviously, requiring mandatory SDP extensions does not simpl= ify interoperability with existing SDP peers.


That's why the MSID spec has a section on what to do when you get tracks wi= thout MSIDs.


 

Thomas

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute= and media stream track

 

On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Mu= nich) wrote:

…

 
And do we require an extra identifier for it, in addition of the posit=
ion (that could also be expressed by an ordinal number in some separate pro=
tocol or for cross-referencing within SDP) of the m-line in the SDP?
I suspect the need for a new identifier of the m-line/media stream tra=
ck has something to do with partial SDP offers? But could the identifier no=
t still be the ordinal number with respect to the "full" SDP (or =
the next free number if an m-line is added), and be restricted to partial o=
ffers?
 
 
The msid attribute also assings a "media stream ID", but you=
r draft does not describe at all what that ID would be used for.=


The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes = 

 
 
 

 

--_000_BDBE1A97E84675488F72A48C23811F35117A17DEMUMBX001nsnintr_-- From randy@qti.qualcomm.com Thu Jul 18 09:12:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9481D21E8105 for ; Thu, 18 Jul 2013 09:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.172 X-Spam-Level: X-Spam-Status: No, score=-101.172 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 Vf+E-dxX-bUh for ; Thu, 18 Jul 2013 09:12:36 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 737AD21E8108 for ; Thu, 18 Jul 2013 09:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374163956; x=1405699956; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=MJjFllamsW1q2hx8JissamXF53xFxhBv0FYFcwpifxo=; b=pFNrdas+Hu5INW99/QcGLZv44lfEAFVDVwEHaTkRfWuby6CD6VK0Vm7D 4l4d9DOtIPKhxycA41o5UaF8jR3cA1/z/jbds/aJ7xpOEhxVEpBAVt8Ah pb72ZT5tLM7uMOJGvp0YmN8jtZNJAqj6ocmuM9il7xgZLgsTNewckQaEC U=; X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208,217";a="47644398" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 18 Jul 2013 09:12:30 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:12:29 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 18 Jul 2013 09:12:28 -0700 Message-ID: In-Reply-To: <51E322C9.4040002@omnitor.se> References: <51E322C9.4040002@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Jul 2013 09:10:31 -0700 To: Gunnar Hellstrom , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:12:40 -0000 Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
At 12:14 AM +0200 7/15/13, Gunnar Hellstrom wrote:

Randall,

Yes, version 01 is a step forward.


Comments:
1. In 7.1 you now say:
When placing an emergency call, and in any other case where the
   language cannot be assumed from context, each media stream in an
   offer SHOULD specify one or both 'humintlang-send' and 'humintlang-
   recv' attributes (to avoid ambiguity).

This might be a good advice. But to what extent SHOULD it be followed?

Some media might be included in SDP without the user having any interest of using it for language communication.
Video may be included without the person really preferring it for spoken language understanding enhancement but just for pleasure or seeing the scene of the other user.

Do you mean that such cases should also be specified with humintlang but with empty attributes?
As a clear indication that the user is not interested in using that medium for language transfer.
That could make sense. That is different from not providing any humintlang at all, that should be understood as undefined language preferences.


But there are media streams specified by SDP where a language preference specification does not make sense. There are many application and message media specifications that are not used for any human language communication. I think for example that there are media specifications for camera control.
Is the SHOULD a sufficient weakening of the requirement, so that the reader can skip using humintlang for media where it does not make sense?
If not, expand "each media stream"  to: "each media stream in which human language communication might occur".

[RG] I have a -02 (which I can submit when the submission window re-opens) in which I've attempted to clarify this by adding:
   In cases where a media is
   not primarily intended for language (for example, a video or audio
   stream intended for background only) both SHOULD be unset.

However, I'm not convinced that in reality clients will know how the user intends to use various streams.  I'd like to hear more discussion on this point.


2. You have also introduced this paragraph in 7.1:
"
Clients acting on behalf of end users are expected to set one or both
   'humintlang-send' and 'humintlang-recv' attributes on each media
   stream in an offer when placing an outgoing session but ignore the
   attributes when receiving incoming calls.  Systems acting on behalf
   of call centers and PSAPs are expected to take into account the
   values when processing inbound calls.
"

What is the thought behind this?

I see the humintlang specification equally valuable in outgoing as incoming calls, and for end-users as well as call-centers and PSAPs.
If a user gets an incoming call, with humintlang specifications, it can compare with its own profile and decide to invoke a
relay service or interpreter servicde to cover some differences in language preferences, or just prepare for what media, modalities and
languages to use in the call..
I do not see the background for this paragraph, and think it will be better to delete it.

[RG] The reasoning is an attempt to not overly-complicate call set-up with requirements that in reality will be difficult for clients to handle in a reasonable way.  I'd like to hear more views on deleting it or modifying it.



3. Absolute preference is still needed.
I described earlier the need for an absolute preference indication. But I did not provide any coding proposal.
I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there.
Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality
and a "-" a non-preferred, but possible language and modality.
 
( needs to be checked against syntax of language tags.)

 
Regards

Gunnar
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-14 11:05, Randall Gellens wrote:
Hi all,

I've tweaked the human language draft:

   o  Relaxed language on setting -send and -receive to same values;
      added text on leaving on empty to indicate asymmetric usage.

   o  Added text that clients on behalf of end users are expected to set
      the attributes on outgoing calls and ignore on incoming calls
      while systems on behalf of call centers and PSAPs are expected to
      take the attributes into account when processing incoming calls.


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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Books have to be read (worse luck it takes so long a time).  It is the
only way of discovering what they contain.  A few savage tribes eat
them, but reading is the only method of assimilation revealed to the
West.
   --E.M. Forster
From martin.thomson@gmail.com Thu Jul 18 09:14: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 9AEE621E8123 for ; Thu, 18 Jul 2013 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.373, 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 WkcR6XDjQHHI for ; Thu, 18 Jul 2013 09:14:03 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB85F21F91B7 for ; Thu, 18 Jul 2013 09:14:02 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so3132376wes.34 for ; Thu, 18 Jul 2013 09:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1NSNMYnsvKl/5EAudw20/K9vxfvD7xUcRebdHEqo8s=; b=MRy1+ib8OzaRLZVqkyp9VdXoFjFjF2YiabcZwPQrACKi57rqn99Ml4qOcllb0G+cv9 yC0Mep1dMGv7+Pk8rt5sKZMvUxTsFGFxL9Leue5ABaem6OzTSaldmPPjPmsjPxisiGfc aFo+dJjb04jgW0BPEw1pjxX3AK5JEKv7lpSiILnSc23qx+e1fJX3lVj1316tbzPrDe5r Lh1KHxgMcUIP5ONGuKLPpJYprgiZI8dT8J5XBFacmucqKRFnBSwpXDA9hC4zPZEpcqpd zN/RyYBuNbIpkRlNkYoaOwmMaFvFUJg8KX+XNXa6s4qUUj2w8A8PXth5gh3omg87IJzn fY0w== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr19890128wik.14.1374164042040; Thu, 18 Jul 2013 09:14:02 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 09:14:01 -0700 (PDT) In-Reply-To: <51E71167.3020203@cisco.com> References: <51E71167.3020203@cisco.com> Date: Thu, 18 Jul 2013 09:14:01 -0700 Message-ID: From: Martin Thomson To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:14:03 -0000 On 17 July 2013 14:49, Flemming Andreasen wrote: > The MMUSIC draft agenda for IETF 87 ... unwrapped: TUESDAY, July 30, 2013 (Bellevue), 13:00-15:00 (120 mins) ========================================================== 13:00-13:15 Introduction and Status Update (Chairs) 13:15-13:25, draft-wing-mmusic-ice-mobility-04 (10 mins) Mobility with ICE (MICE) 13:25-13:40, draft-reddy-mmusic-ice-happy-eyeballs-01 (15 mins) Happy Eyeballs Extension for ICE 13:40-13:55, draft-gellens-mmusic-negotiating-human-language-01 (15 mins) Negotiating Human Language Using SDP 13:55-14:10, draft-ivov-mmusic-trickle-ice-01 (15 mins) draft-ivov-mmusic-trickle-ice-sip-00 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol A Session Initiation Protocol (SIP) usage for Trickle ICE 14:10-14:25, draft-even-mmusic-application-token-00 (15 mins) The Session Description Protocol (SDP) Application Token Attribute 14:25-14:40, draft-ivov-mmusic-multiple-sources-00 (15 mins) Economical Use of the Offer/Answer Model in Sessions with Multiple Media Sources 14:40-14:50, draft-nandakumar-mmusic-sdp-mux-attributes-03 (10 mins) A Framework for SDP Attributes when Multiplexing 14:50-15:00, draft-martinsen-mmusic-malice-00 (10 mins) Meta-data Attribute signaLling with ICE WEDNESDAY, July 31, 2013 (Charlottenburg 2/3), 13:00-15:00 (120 mins) ====================================================================== 13:00-13:40, draft-ietf-mmusic-sdp-bundle-negotiation-04 (40 mins) Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers 13:40-14:20, draft-roach-mmusic-unified-plan-00 (40 mins) A Unified Plan for Using SDP with Large Numbers of Media Flows 14:20-15:00 Plan Discussion and Decision on Path Forward (40 mins) Overflow (draft presentation requests with no agenda time) ---------------------------------------------------------- draft-marcon-msrp-over-webrtc-data-channels-00 draft-nandakumar-mmusic-rtcweb-grouping-00 draft-nandakumar-rtcweb-sdp-02 From randy@qti.qualcomm.com Thu Jul 18 09:25: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 DB54B21E808C for ; Thu, 18 Jul 2013 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2LeceldIrcly for ; Thu, 18 Jul 2013 09:25:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD5511E8198 for ; Thu, 18 Jul 2013 09:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374164705; x=1405700705; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=4QAZtdbuMTMkbcXIEdBb+Ccvwks9UGqlormDlekFQas=; b=x9JbLdTWnBepH6/oa+E9GdAQzyHEPrHm95HuBA0wC4zlg8vA7ItqLW5S 1hdR37/n86dbnrfXY61UUPrWlFxN0k+Esferqs2mwtLOcJVrbrUGDQRhe oPWWkrTWma71k7ljI7Ps5NeQDzOLhDWI1CY8UfrVhe7DCiHCAbCc9pdtd U=; X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208";a="63494349" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 18 Jul 2013 09:25:04 -0700 X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208";a="570253624" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:25:03 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 18 Jul 2013 09:25:02 -0700 Message-ID: In-Reply-To: <51E35A53.5030502@nteczone.com> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Jul 2013 09:14:28 -0700 To: Christian Groves , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:25:22 -0000 Hi Christian, How about this text: Clients acting on behalf of end users are expected to set one or both 'humintlang-send' and 'humintlang-recv' attributes on each media stream primarily intended for human communication in an offer when placing an outgoing session, but either ignore or take into consideration the attributes when receiving incoming calls, based on local configuration and capabilities. Systems acting on behalf of call centers and PSAPs are expected to take into account the values when processing inbound calls. At 12:11 PM +1000 7/15/13, Christian Groves wrote: > Hello Randall and Gunnar, > > I think Randall's clarification would be good to have in the draft. > I think that when a caller support the language it is sent for > every call. Whether the language is used by a receiver depends on > the receiver's local capability. > > > Regards, Christian > > > On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: >> On 2013-07-13 10:07, Randall Gellens wrote: >>> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >>> >>>> I wouldn't have thought that it would be use case specific... >>>> i.e. i'd only include my language when I called an emergency >>>> service. I would think an endpoint would be configured with the >>>> information and then provide it whenever I made a call. Is that >>>> the intent? >>> >>> I expect so, but then, I also didn't expect it to be used much in >>> the person-to-person case since usually language is implied by >>> context when calling an individual. I expect it to be used when >>> a person is calling an call center (corporate or emergency). To >>> put it another way, I expect a personal client to always set >>> language on outbound calls, but in most cases to ignore it on >>> inbound calls. I'd expect a corporate call center, as well as >>> emergency call handling facilities, to pay attention. I should >>> make this more clear in the draft. >>> >> I expect the setting to be retrieved from a personal profile >> (likely but not necessarily stored in connection with other user >> information and account information) and used in every call. >> >> /Gunnar >> _______________________________________________ >> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- DETERIORATA Go placidly amid the noise and waste, And remember what comfort there may be in owning a piece thereof. Avoid quiet and passive persons, unless you are in need of sleep. Rotate your tires. Speak glowingly of those greater than yourself, And heed well their advice -- even though they be turkeys. Know what to kiss -- and when. Remember that two wrongs never make a right, But that three do. Wherever possible, put people on "HOLD". Be comforted, that in the face of all aridity and disillusionment, And despite the changing fortunes of time, There is always a big future in computer maintenance. You are a fluke of the universe ... You have no right to be here. Whether you can hear it or not, the universe Is laughing behind your back. -- National Lampoon From randy@qti.qualcomm.com Thu Jul 18 09:25: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 476F021E8128 for ; Thu, 18 Jul 2013 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.87 X-Spam-Level: X-Spam-Status: No, score=-105.87 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 smQTLCzkbldw for ; Thu, 18 Jul 2013 09:25:22 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 61D1A11E819B for ; Thu, 18 Jul 2013 09:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374164705; x=1405700705; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=jDToOhBe46Y+Za8vFPBDr4QzCtml9cDT6EWSLIMUq3I=; b=w6pXdAhHbkwewVGeH5YsMZIJ3X0LYVtRfMFw+xVgvCzZG78qo3XZo7pv oT5T3koICSaESbGIdptLEG3YR42TWUzg25+NTs5x+JF6PNUI6Y61OUlf/ XW1+pCtxczsPjvS93HokGgpn6UY2QC/+sJLeHOKityjXNmBxu4Q8K+x/W I=; X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208,217";a="63494352" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 18 Jul 2013 09:25:04 -0700 X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208,217";a="481677102" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:25:04 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 18 Jul 2013 09:25:03 -0700 Message-ID: In-Reply-To: <51E39957.3080004@omnitor.se> References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> <51E39957.3080004@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Jul 2013 09:21:33 -0700 To: Gunnar Hellstrom , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:25:26 -0000 Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
Hi Gunnar,

I am concerned that getting into person-to-person usage will overly complicate the draft with no real-world benefit, since person-to-person communication has context and implied language/media, as stated in the draft.  The draft is trying to solve a more focused real-world problem where there is no context.

At 8:40 AM +0200 7/15/13, Gunnar Hellstrom wrote:

I suggest to add a couple of use cases.
4.x.  Deaf French sign language user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a call. 
The call offers a video stream listing FSL in both directions with highest preference and also
real-time text stream on low preference level for French in both directions.
Audio is also included but without language indications.
The call destination turns out to be another user of FSL with the same media and language settings.
The called client can find that the language preferences match, so the same language indications are
sent in the SDP answer, and the call can be connected without connection of any relay service.
The users can sign directly with each other in the video streams, and occasionally use the real-time
text streams for data that need exact spelling or noted.


4.y.  Spoken Japanese user calling a Spanish speaking person.

Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call. 
The call offers audio streams using Japanese in both directions on high preference level, video
with spoken Japanese with no specific preference and both message-wise and real-time text in
Japanese in both directions.
This user is customer of an on-line interpreting service. The service adds its interpreting
language capabilities to the SDP on lower level than the originator, and conveys the call to the destination.
The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible
languages even if not highest preference, so that call is answered with indication of spoken Spanish at high
priority level and Spanish text messaging in both directions at low priority level.
The on-line interpreting service detects that their translation between Japanese and Spanish is needed to
make the call work, so they allocate an interpreter to the call, and answers the call with an indication
of Japanese towards the caller.
Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the
appropriate languages in the text message connections.
The users can communicate in their own languages supported by the interpreter.


-------------------------------
More might be needed to clarify some more of the endless possible variations and benefit.




Gunnar Hellstr=9Am
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-15 04:11, Christian Groves wrote:
Hello Randall and Gunnar,

I think Randall's clarification would be good to have in the draft. I think that when a caller support the language it is sent for every call. Whether the language is used by a receiver depends on the receiver's local capability.


Regards, Christian


On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote:
On 2013-07-13 10:07, Randall Gellens wrote:
At 2:49 PM +1000 7/10/13, Christian Groves wrote:
 I wouldn't have thought that it would be use case specific... i.e. i'd only include my language when I called an emergency service. I would think an endpoint would be configured with the information and then provide it whenever I made a call. Is that the intent?

I expect so, but then, I also didn't expect it to be used much in the person-to-person case since usually language is implied by context when calling an individual.  I expect it to be used when a person is calling an call center (corporate or emergency).  To put it another way, I expect a personal client to always set language on outbound calls, but in most cases to ignore it on inbound calls.  I'd expect a corporate call center, as well as emergency call handling facilities, to pay attention.  I should make this more clear in the draft.

I expect the setting to be retrieved from a personal profile (likely but not necessarily stored in connection with other user information and account information) and used in every call.

/Gunnar
_______________________________________________
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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.
From randy@qti.qualcomm.com Thu Jul 18 09:25: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 710E821E812C for ; Thu, 18 Jul 2013 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, 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 so96E5zlgXYB for ; Thu, 18 Jul 2013 09:25:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5477C11E819A for ; Thu, 18 Jul 2013 09:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374164705; x=1405700705; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=N0QCs1O3is3lgNZRj1v8kKnnbtm9wsEXeexaoWw+9SU=; b=Nh9WW7NlHUPAIYEdXrfopbHvm2IT/kRMoRqEIc0BhBk5B+KdmMG2U7k7 nOXC6fXXfSo64QEGOqlEeZDI3aLgsQ64DZYkdMwZOzuU80BclMWpkwv90 LbdmBvwZlor4Tc8tpjGaHmaf46JScg/6YHTCUlMHSoSaz/Y61dQVnAR7N U=; X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208";a="63494351" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 18 Jul 2013 09:25:04 -0700 X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208";a="506739705" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:25:04 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 18 Jul 2013 09:25:03 -0700 Message-ID: In-Reply-To: <51E35C7F.7030101@nteczone.com> References: <51E322C9.4040002@omnitor.se> <51E35C7F.7030101@nteczone.com> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Jul 2013 09:16:08 -0700 To: Christian Groves , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:25:26 -0000 At 12:20 PM +1000 7/15/13, Christian Groves wrote: > Hello Randall, > > Please see my comment below. > > ..snip.. > On 15/07/2013 8:14 AM, Gunnar Hellstrom wrote: >> ... >> >> 2. You have also introduced this paragraph in 7.1: >> " >> Clients acting on behalf of end users are expected to set one or both >> 'humintlang-send' and 'humintlang-recv' attributes on each media >> stream in an offer when placing an outgoing session but ignore the >> attributes when receiving incoming calls. Systems acting on behalf >> of call centers and PSAPs are expected to take into account the >> values when processing inbound calls. >> " >> >> What is the thought behind this? >> >> I see the humintlang specification equally valuable in outgoing as >> incoming calls, and for end-users as well as call-centers and >> PSAPs. >> If a user gets an incoming call, with humintlang specifications, >> it can compare with its own profile and decide to invoke a >> relay service or interpreter servicde to cover some differences in >> language preferences, or just prepare for what media, modalities >> and >> languages to use in the call.. >> I do not see the background for this paragraph, and think it will >> be better to delete it. >> >> > [CNG] I guess this is a question of scope. I would think that the > draft would just describe the syntax and procedures of this new > language tag in a generic manner. The application level behaviour > of call centres and PSAPs would be defined elsewhere? [RG] That would be fine with me; my attempt in adding the text using descriptive rather than normative language was to clarify the intended use without imposing mandates on call centers and PSAPs (which, as you say, will be done elsewhere). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Mythology, n.: The body of a primitive people's beliefs concerning its origin, early history, heroes, deities and so forth, as distinguished from the true accounts which it invents later. --Ambrose Bierce, "The Devil's Dictionary" From martin.thomson@gmail.com Thu Jul 18 10:06: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 7768E11E8150 for ; Thu, 18 Jul 2013 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=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 ACdOzoCp4c92 for ; Thu, 18 Jul 2013 10:06:51 -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 630E311E81A2 for ; Thu, 18 Jul 2013 10:06:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so3455872wib.8 for ; Thu, 18 Jul 2013 10:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FHI7q2kV6SQGVxSS8UnTE+OjmFCrIKaMgqjrtCwnKFs=; b=Dhwde+YgnsH8cOi1fyuILAutjWv0QMzjbpLFD2tLDUEbPaPEQT/ychZmpJpHm/a1dz pzsHihy1bThy4hi+YOw51g4S4dfVCQdu5ETe5VDoeP0DQP3plIn9y1lLDZAvKzkhZrvi 6nwEwv7UzyARlCJPLHbladABb12hC/hJ0K86EQu6X39DxVTxZtz4OyCgRT/eCxFUVuxs zFsRVuMHRHXtM3SqnN7mMaShSLdO+Gv22ZGYKhlU9vUmnPYx19n/B0ItfEgtIyFkBFIh Zmn/ODtYyrBISPBq8MZtgHCQ8vbC/rQMBmzCPxU3UEgOtoYdDX8npYLyqWW50OFrFs3L GrCQ== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr8716842wic.65.1374167208409; Thu, 18 Jul 2013 10:06:48 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 10:06:48 -0700 (PDT) In-Reply-To: <51E7B818.6000802@alvestrand.no> References: <51E7B818.6000802@alvestrand.no> Date: Thu, 18 Jul 2013 10:06:48 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of unified-plan-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 Jul 2013 17:06:51 -0000 On 18 July 2013 02:40, Harald Alvestrand wrote: > The standard way of encoding this information in SDP is to have each > RTP flow (i.e., SSRC) appear on its own m-line. > > This is not strictly true, since the proposal continues to use each m-line > for up to two flows, one in each direction, and some of the . Suggested > rephrase: > > One common way of encoding this information uses each M-line to > describe one media source in each direction. That's fine with me. It seems that there is some contention around what an m-line actually is, and this has no substantive impact. So weasel away. > It needs to note that this specification modifies RFC 5888 section 9.2 Yes. We've talked about that lots, but we missed it somehow. > 4.1 Simple example > > "It also shows unique payload across the audio and video m=lines for the > Answerer that does not support BUNDLE semantics." - this doesn't make sense > to me; unique payloads are needed for answerers that support BUNDLE > semantics. Copy/paste error? > > Would be consistent if it said "for the Answerer that supports BUNDLE > semantics". Actually, this has nothing to do with BUNDLE. It assumes that you support BUNDLE, but might not support the RTP header extension and might want to have media play out at the offerer prior to receiving an answer. > 4.4 Multiple Video with Simulcast > > If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, the > ssrc-group lines should probably say SCS rather than SIMULCAST. Maybe this is a veiled comment along the lines of : "SCS" is a strangely perverse choice of label, why don't you call a spade a spade :) > Interaction with a=content > > Previously, we had discussed having a "content" attribute on > MediaStreamTracks that would make a track link to an m-line with the same > "a=content" attribute. If this is still expected to work, it might be worthy > of inclusion here. The purpose to which a=content was put in plan B isn't really necessary any more. No actual feature would depend on this, so don't see a particular reason to mention this in the plan. Maybe this is one of the SDP mutations we've been looking for. Perhaps you can take this to the W3C. From gunnar.hellstrom@omnitor.se Thu Jul 18 13:24: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 69F4011E8183 for ; Thu, 18 Jul 2013 13:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=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 rVP26-ClljBI for ; Thu, 18 Jul 2013 13:24:17 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 6D40011E80ED for ; Thu, 18 Jul 2013 13:24:15 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Thu, 18 Jul 2013 22:23:30 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 8BFB83A1DF; Thu, 18 Jul 2013 22:23:30 +0200 (CEST) Message-ID: <51E84EC7.4000508@omnitor.se> Date: Thu, 18 Jul 2013 22:23:35 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> <51E39957.3080004@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030105030307070801040102" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:24:22 -0000 This is a multi-part message in MIME format. --------------030105030307070801040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Randall, In my view the draft aims at solving the difference between the user-to-user call with known similar context and the situation when the user-to-user call has dissimilar contexts and need support. The call center gets invoked because of the difference between the users in order to fill the gap. Of course there are other situations where it can be useful, but this is the main application that I see. In USA, it is called to dial-around, when the users are connected without connection of an assisting service, and use of relay service when assistance is needed and invoked. In Sweden we call the concept Call-direct. The function is mentioned and demonstrated a number of times Internationally, and this is an opportunity to get proper standardized support for it. Users interested in this service will have the language settings. It is very valid to do the comparison between the users and invoke services if needed. For users who have not set the language indicators, there will need to be a place for assumptions in the evaluation logic. And. Most important, I think we should follow Christian's advice to get a way to include language indications specified here, and the ways to use it specified in other specifications. But in order to get the indications useful, we must settle some use cases. So there we have a risk of including assumptions of how the indications can be used. Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-07-18 18:21, Randall Gellens wrote: > Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua > Hi Gunnar, > > I am concerned that getting into person-to-person usage will overly > complicate the draft with no real-world benefit, since > person-to-person communication has context and implied language/media, > as stated in the draft. The draft is trying to solve a more focused > real-world problem where there is no context. > > At 8:40 AM +0200 7/15/13, Gunnar Hellstrom wrote: > >> I suggest to add a couple of use cases. >> 4.x. Deaf French sign language user calling another deaf French sign >> language user. >> >> Someone who mainly uses French sign language (FSL) places a call. >> The call offers a video stream listing FSL in both directions with >> highest preference and also >> real-time text stream on low preference level for French in both >> directions. >> Audio is also included but without language indications. >> The call destination turns out to be another user of FSL with the >> same media and language settings. >> The called client can find that the language preferences match, so >> the same language indications are >> sent in the SDP answer, and the call can be connected without >> connection of any relay service. >> The users can sign directly with each other in the video streams, and >> occasionally use the real-time >> text streams for data that need exact spelling or noted. >> >> >> 4.y. Spoken Japanese user calling a Spanish speaking person. >> >> Someone who speaks Japanese and is subscriber of an on-line >> interpreting service places a call. >> The call offers audio streams using Japanese in both directions on >> high preference level, video >> with spoken Japanese with no specific preference and both >> message-wise and real-time text in >> Japanese in both directions. >> This user is customer of an on-line interpreting service. The service >> adds its interpreting >> language capabilities to the SDP on lower level than the originator, >> and conveys the call to the destination. >> The destination is a Spanish speaking person. The called terminal >> detects that Spanish is among the possible >> languages even if not highest preference, so that call is answered >> with indication of spoken Spanish at high >> priority level and Spanish text messaging in both directions at low >> priority level. >> The on-line interpreting service detects that their translation >> between Japanese and Spanish is needed to >> make the call work, so they allocate an interpreter to the call, and >> answers the call with an indication >> of Japanese towards the caller. >> Information that the call will be soon supported by a >> Japanese/Spanish interpreter is provided in the >> appropriate languages in the text message connections. >> The users can communicate in their own languages supported by the >> interpreter. >> >> >> ------------------------------- >> More might be needed to clarify some more of the endless possible >> variations and benefit. >> >> >> >> >> ------------------------------------------------------------------------ >> Gunnar Hellstrs(m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-07-15 04:11, Christian Groves wrote: >>> Hello Randall and Gunnar, >>> >>> I think Randall's clarification would be good to have in the draft. >>> I think that when a caller support the language it is sent for every >>> call. Whether the language is used by a receiver depends on the >>> receiver's local capability. >>> >>> >>> Regards, Christian >>> >>> >>> On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: >>>> On 2013-07-13 10:07, Randall Gellens wrote: >>>>> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >>>>>> I wouldn't have thought that it would be use case specific... >>>>>> i.e. i'd only include my language when I called an emergency >>>>>> service. I would think an endpoint would be configured with the >>>>>> information and then provide it whenever I made a call. Is that >>>>>> the intent? >>>>> >>>>> I expect so, but then, I also didn't expect it to be used much in >>>>> the person-to-person case since usually language is implied by >>>>> context when calling an individual. I expect it to be used when a >>>>> person is calling an call center (corporate or emergency). To put >>>>> it another way, I expect a personal client to always set language >>>>> on outbound calls, but in most cases to ignore it on inbound >>>>> calls. I'd expect a corporate call center, as well as emergency >>>>> call handling facilities, to pay attention. I should make this >>>>> more clear in the draft. >>>>> >>>> I expect the setting to be retrieved from a personal profile >>>> (likely but not necessarily stored in connection with other user >>>> information and account information) and used in every call. >>>> >>>> /Gunnar >>>> _______________________________________________ >>>> 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 > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If you make people think they're thinking, they'll love you; but if you > really make them think they'll hate you. --------------030105030307070801040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Randall,
In my view the draft aims at solving the difference between the user-to-user call with known similar context and the situation when the user-to-user call has dissimilar contexts and need support.

The call center gets invoked because of the difference between the users in order to fill the gap.

Of course there are other situations where it can be useful, but this is the main application that I see.

In USA, it is called to dial-around, when the users are connected without connection of an assisting service, and use of relay service when assistance is needed and invoked.
In Sweden we call the concept Call-direct.
The function is mentioned and demonstrated a number of times Internationally, and this is an opportunity to get proper standardized support for it.

Users interested in this service will have the language settings. It is very valid to do the comparison between the users and invoke services if needed.
For users who have not set the language indicators, there will need to be a place for assumptions in the evaluation logic.


And. Most important, I think we should follow Christian's advice to get a way to include language indications specified here, and the ways to use it specified in other specifications.

But in order to get the indications useful, we must settle some use cases. So there we have a risk of including assumptions of how the indications can be used.

Gunnar

 




Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-18 18:21, Randall Gellens wrote:
Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
Hi Gunnar,

I am concerned that getting into person-to-person usage will overly complicate the draft with no real-world benefit, since person-to-person communication has context and implied language/media, as stated in the draft.  The draft is trying to solve a more focused real-world problem where there is no context.

At 8:40 AM +0200 7/15/13, Gunnar Hellstrom wrote:

I suggest to add a couple of use cases.
4.x.  Deaf French sign language user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a call. 
The call offers a video stream listing FSL in both directions with highest preference and also
real-time text stream on low preference level for French in both directions.
Audio is also included but without language indications.
The call destination turns out to be another user of FSL with the same media and language settings.
The called client can find that the language preferences match, so the same language indications are
sent in the SDP answer, and the call can be connected without connection of any relay service.
The users can sign directly with each other in the video streams, and occasionally use the real-time
text streams for data that need exact spelling or noted.


4.y.  Spoken Japanese user calling a Spanish speaking person.

Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call. 
The call offers audio streams using Japanese in both directions on high preference level, video
with spoken Japanese with no specific preference and both message-wise and real-time text in
Japanese in both directions.
This user is customer of an on-line interpreting service. The service adds its interpreting
language capabilities to the SDP on lower level than the originator, and conveys the call to the destination.
The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible
languages even if not highest preference, so that call is answered with indication of spoken Spanish at high
priority level and Spanish text messaging in both directions at low priority level.
The on-line interpreting service detects that their translation between Japanese and Spanish is needed to
make the call work, so they allocate an interpreter to the call, and answers the call with an indication
of Japanese towards the caller.
Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the
appropriate languages in the text message connections.
The users can communicate in their own languages supported by the interpreter.


-------------------------------
More might be needed to clarify some more of the endless possible variations and benefit.




Gunnar Hellstršm
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-15 04:11, Christian Groves wrote:
Hello Randall and Gunnar,

I think Randall's clarification would be good to have in the draft. I think that when a caller support the language it is sent for every call. Whether the language is used by a receiver depends on the receiver's local capability.


Regards, Christian


On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote:
On 2013-07-13 10:07, Randall Gellens wrote:
At 2:49 PM +1000 7/10/13, Christian Groves wrote:
 I wouldn't have thought that it would be use case specific... i.e. i'd only include my language when I called an emergency service. I would think an endpoint would be configured with the information and then provide it whenever I made a call. Is that the intent?

I expect so, but then, I also didn't expect it to be used much in the person-to-person case since usually language is implied by context when calling an individual.  I expect it to be used when a person is calling an call center (corporate or emergency).  To put it another way, I expect a personal client to always set language on outbound calls, but in most cases to ignore it on inbound calls.  I'd expect a corporate call center, as well as emergency call handling facilities, to pay attention.  I should make this more clear in the draft.

I expect the setting to be retrieved from a personal profile (likely but not necessarily stored in connection with other user information and account information) and used in every call.

/Gunnar
_______________________________________________
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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.

--------------030105030307070801040102-- From harald@alvestrand.no Thu Jul 18 14:04: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 4EB7A11E8202 for ; Thu, 18 Jul 2013 14:04:37 -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_15=0.6, J_CHICKENPOX_17=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 Ou0MptAhREuQ for ; Thu, 18 Jul 2013 14:04:31 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 34BE111E8209 for ; Thu, 18 Jul 2013 14:04:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89D9B39E4B0; Thu, 18 Jul 2013 23:04:28 +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 QV2I11LXxE0g; Thu, 18 Jul 2013 23:04:27 +0200 (CEST) Received: from [172.30.42.116] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A1E5339E1C9; Thu, 18 Jul 2013 23:04:27 +0200 (CEST) Message-ID: <51E8585B.4030906@alvestrand.no> Date: Thu, 18 Jul 2013 23:04:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <51E7B818.6000802@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of unified-plan-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 Jul 2013 21:04:37 -0000 On 07/18/2013 07:06 PM, Martin Thomson wrote: > On 18 July 2013 02:40, Harald Alvestrand wrote: >> The standard way of encoding this information in SDP is to have each >> RTP flow (i.e., SSRC) appear on its own m-line. >> >> This is not strictly true, since the proposal continues to use each m-line >> for up to two flows, one in each direction, and some of the . Suggested >> rephrase: >> >> One common way of encoding this information uses each M-line to >> describe one media source in each direction. > That's fine with me. It seems that there is some contention around > what an m-line actually is, and this has no substantive impact. So > weasel away. > >> It needs to note that this specification modifies RFC 5888 section 9.2 > Yes. We've talked about that lots, but we missed it somehow. > >> 4.1 Simple example >> >> "It also shows unique payload across the audio and video m=lines for the >> Answerer that does not support BUNDLE semantics." - this doesn't make sense >> to me; unique payloads are needed for answerers that support BUNDLE >> semantics. Copy/paste error? >> >> Would be consistent if it said "for the Answerer that supports BUNDLE >> semantics". > Actually, this has nothing to do with BUNDLE. It assumes that you > support BUNDLE, but might not support the RTP header extension and > might want to have media play out at the offerer prior to receiving an > answer. Since all the sentences talking about it have the word BUNDLE in them, I have to assume it has *something* to do with BUNDLE. It's just that the sign bit seemed wrong. > >> 4.4 Multiple Video with Simulcast >> >> If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, the >> ssrc-group lines should probably say SCS rather than SIMULCAST. > Maybe this is a veiled comment along the lines of : "SCS" is a > strangely perverse choice of label, why don't you call a spade a spade > :) I'd be happy to argue for use of a more readable label :-) >> Interaction with a=content >> >> Previously, we had discussed having a "content" attribute on >> MediaStreamTracks that would make a track link to an m-line with the same >> "a=content" attribute. If this is still expected to work, it might be worthy >> of inclusion here. > The purpose to which a=content was put in plan B isn't really > necessary any more. No actual feature would depend on this, so don't > see a particular reason to mention this in the plan. > > Maybe this is one of the SDP mutations we've been looking for. > Perhaps you can take this to the W3C. Cullen claimed at one point that a=content was necessary to make interoperability with some class of devices happen - it may be totally orthogonal to this specification, in which case I'm happy to discus that on a different thread :-) From martin.thomson@gmail.com Thu Jul 18 14:14: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 21B7A21E80A7 for ; Thu, 18 Jul 2013 14:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_15=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 LgciMyaMQR6L for ; Thu, 18 Jul 2013 14:14:27 -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 5869021E805A for ; Thu, 18 Jul 2013 14:14:27 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so7144481wiv.8 for ; Thu, 18 Jul 2013 14:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTYi+pz4/o/FyuZdhTbELUIdW+ighKuw5+N+J6LUhYs=; b=CQGgFUYJ8qVrMehNeQ6ZYGz6Ni5xxEGn1bDiW+XDzcefUWhyYEDhNjOuUzwRxqaWmF 2ZYi/LSlCoSN5ne+d8h5MXrbrxTU40nbH4JrnrxuG4Pg/29sF8ml7L33XckXw2NAHSqN 3dZTPhPqA+I8TIAfoA03ZW2Sc9/YtpirgTXi1BLNlkPCHHUMNJB/0W+Qx3psTfXwLeX0 pXC9vW00XLDRIoTGS/NDTwcO7HRHBo9WG8/bv1pMEr2QudMOiek0AxSTkP6IeJKtbGeT SSsoQBF+9Qei6mflsaZ+EZkSB1GIR6+SZyYjQzzIppkLk9PQob+8Vgf7/AYF649a5gTY rgdw== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr10068264wjb.3.1374182066518; Thu, 18 Jul 2013 14:14:26 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 14:14:26 -0700 (PDT) In-Reply-To: <51E8585B.4030906@alvestrand.no> References: <51E7B818.6000802@alvestrand.no> <51E8585B.4030906@alvestrand.no> Date: Thu, 18 Jul 2013 14:14:26 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of unified-plan-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 Jul 2013 21:14:28 -0000 On 18 July 2013 14:04, Harald Alvestrand wrote: >>> 4.1 Simple example >>> >>> "It also shows unique payload across the audio and video m=lines for the >>> Answerer that does not support BUNDLE semantics." - this doesn't make sense >>> to me; unique payloads are needed for answerers that support BUNDLE >>> semantics. Copy/paste error? >>> >>> Would be consistent if it said "for the Answerer that supports BUNDLE >>> semantics". >> Actually, this has nothing to do with BUNDLE. It assumes that you >> support BUNDLE, but might not support the RTP header extension and >> might want to have media play out at the offerer prior to receiving an >> answer. > > Since all the sentences talking about it have the word BUNDLE in them, I > have to assume it has *something* to do with BUNDLE. It's just that the > sign bit seemed wrong. There is an initial assumption given (one stream per m-line). With that assumption stated, a unique payload type is a way to do the correlation thing. That only causes problems when BUNDLE is used. Without BUNDLE, you have a 5-tuple, which is probably adequate. I'll have to let Adam speak to why the draft says what it says here, he was following the discussion closer than I. From gunnar.hellstrom@omnitor.se Thu Jul 18 14:19: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 2E2DD11E8214 for ; Thu, 18 Jul 2013 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 yhW56mmMzDlM for ; Thu, 18 Jul 2013 14:19:48 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 79FF411E8209 for ; Thu, 18 Jul 2013 14:19:38 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 18 Jul 2013 23:19:29 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 6C0313A161 for ; Thu, 18 Jul 2013 23:19:29 +0200 (CEST) Message-ID: <51E85BE6.50904@omnitor.se> Date: Thu, 18 Jul 2013 23:19:34 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E322C9.4040002@omnitor.se> <51E35C7F.7030101@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:19:55 -0000 On 2013-07-18 18:16, Randall Gellens wrote: >>> 2. You have also introduced this paragraph in 7.1: >>> " >>> Clients acting on behalf of end users are expected to set one or both >>> 'humintlang-send' and 'humintlang-recv' attributes on each media >>> stream in an offer when placing an outgoing session but ignore the >>> attributes when receiving incoming calls. Systems acting on >>> behalf >>> of call centers and PSAPs are expected to take into account the >>> values when processing inbound calls. >>> " >>> >>> What is the thought behind this? >>> >>> I see the humintlang specification equally valuable in outgoing as >>> incoming calls, and for end-users as well as call-centers and PSAPs. >>> If a user gets an incoming call, with humintlang specifications, it >>> can compare with its own profile and decide to invoke a >>> relay service or interpreter servicde to cover some differences in >>> language preferences, or just prepare for what media, modalities and >>> languages to use in the call.. >>> I do not see the background for this paragraph, and think it will >>> be better to delete it. >>> >>> >> [CNG] I guess this is a question of scope. I would think that the >> draft would just describe the syntax and procedures of this new >> language tag in a generic manner. The application level behaviour of >> call centres and PSAPs would be defined elsewhere? > > [RG] That would be fine with me; my attempt in adding the text using > descriptive rather than normative language was to clarify the intended > use without imposing mandates on call centers and PSAPs (which, as you > say, will be done elsewhere). But since your assumption of use was far from mine, I hope that you accept to delete the paragraph. Or change it to: " Clients are expected to set one or both 'humintlang-send' and 'humintlang-recv' attributes on each media stream in an offer and answer for which the users has any preferences or capabilities for use in human communication. Systems are expected to take into account the values when processing inbound calls or when processing the answers on outbound calls. The values can also be used for call handling decisions by service providers. " Regards Gunnar From gunnar.hellstrom@omnitor.se Thu Jul 18 14:28: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 C2D2511E820B for ; Thu, 18 Jul 2013 14:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 ivzskEBfTzoY for ; Thu, 18 Jul 2013 14:28:28 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 81F2511E8210 for ; Thu, 18 Jul 2013 14:28:26 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 18 Jul 2013 23:28:15 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id E33CE3A16B for ; Thu, 18 Jul 2013 23:28:14 +0200 (CEST) Message-ID: <51E85DF3.104@omnitor.se> Date: Thu, 18 Jul 2013 23:28:19 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> <51E39957.3080004@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:28:34 -0000 On 2013-07-18 18:21, Randall Gellens wrote: > Hi Gunnar, > > I am concerned that getting into person-to-person usage will overly > complicate the draft with no real-world benefit, since > person-to-person communication has context and implied language/media, > as stated in the draft. This is not true anymore in the multimedia communication area. Video may be included in a call because the user just want to see the other call participant or it is included because the user urgently prefers to get a sign language commuication. Two persons urgently wanting to use British Sign Language should have a chance to find that both support and prefer that, and they should connect without a relay service. The evaluation can be made by the answering part, the calling part on the answer if the intication is prpoerly inserted, or by a service provider in betweeen the users. But if the answering part ignores the indications, nothing is gained. Gunnar From suhasietf@gmail.com Thu Jul 18 15:18: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 77AD511E8204 for ; Thu, 18 Jul 2013 15:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=-1.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 53ZFBZJMMRe3 for ; Thu, 18 Jul 2013 15:18:31 -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 397A021F8267 for ; Thu, 18 Jul 2013 15:18:31 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so7190754wiw.17 for ; Thu, 18 Jul 2013 15:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w32FONN8uY8x+yyH2tm8mo2efPQFC1PTQsXPWWp8z0U=; b=1HDIdPuleHGSiOQCEzO02hbMKW+D+Fbk6QGN8EUnzWfznYYJfsv5ZqgyLqCSu+ZEg9 Ev9OAPgYWNOLvovAqTERdFrMeWQzZXa+xg+75olrGcku77KCMVN/HcPCRHjwSDwPO/UE pcWshRv6Y1hmUBQ7ssYmri0n5gIw0U57ZoKI5jvDSkdIh0Xvhzx9sr2MPCM5isbngARc r3lAotwJ/3ZfDMJhmYge7XO4P3Zlsjh3gqCcK50C92A4vsyGR38W4pPEtUsPHgqyGlAf o0+QyU9t+HV5PwaMzJKdA1iJpLnKD/3CM2RBtmtcZQSalaqoFy+l7Iw497ccPy7BW/5k Jh8A== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr10054864wjc.30.1374185910308; Thu, 18 Jul 2013 15:18:30 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Thu, 18 Jul 2013 15:18:30 -0700 (PDT) In-Reply-To: <51E7B818.6000802@alvestrand.no> References: <51E7B818.6000802@alvestrand.no> Date: Thu, 18 Jul 2013 15:18:30 -0700 Message-ID: From: Suhas Nandakumar To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e0122f0fe0a162004e1d0975a Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of unified-plan-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 Jul 2013 22:18:32 -0000 --089e0122f0fe0a162004e1d0975a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 18, 2013 at 2:40 AM, Harald Alvestrand wrote: > First of all, let me say that I'm very happy to see a plan that the people > who have been voicing the strongest opinions in this debate are willing to > stand behind. > I believe, extremely strongly, that it is better to move forward on one > path, no matter what it is (as long as it's not obviously broken), than to > continue to debate. This topic has long been needing a decision. > > Thus, I stand behind the technology proposed, and have no wish to change > it. The purpose of this review is to help make sure it's fully described, > and that all parties understand it the same way. > > I have ignored language-only issues at this time. > > Introduction, paragraph 2: > > The standard way of encoding this information in SDP is to have each > RTP flow (i.e., SSRC) appear on its own m-line. > > This is not strictly true, since the proposal continues to use each m-line > for up to two flows, one in each direction, and some of the . Suggested > rephrase: > > One common way of encoding this information uses each M-line to > describe one media source in each direction. > > "media source" is as defined in draft-westerlund-avtcore-**multiplex-architecture-03 > section 2.1. The term is used elsewhere in the document, and seems to have > this meaning. "One common" is a reflection of my belief that practice has > not been uniform in this area. > > 3.1, Bundle-only M-lines > > This mechanism requires sending M-lines with port zero as part of a bundle > in an SDP OFFER. > It needs to note that this specification modifies RFC 5888 section 9.2 > (the grouping framework) by allowing such M-lines to be part of a group in > an offer (but I do not think it needs to be allowed in an answer). > > 4.1 Simple example > > "It also shows unique payload across the audio and video m=lines for the > Answerer that does not support BUNDLE semantics." - this doesn't make sense > to me; unique payloads are needed for answerers that support BUNDLE > semantics. Copy/paste error? > > Would be consistent if it said "for the Answerer that supports BUNDLE > semantics". > > 4.4 Multiple Video with Simulcast > > If it's intended that draft-westerlund-avtcore-rtp-**simulcast is used, > the ssrc-group lines should probably say SCS rather than SIMULCAST. > > Regarding the Simulcast ssrc-group based signaling, the following draft explains its usage: http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00. The idea is very similar to the Unified Plan in that , ssrc-group is used to signal the ssrcs for a given MediaStreamTrack as part of Simulcast. It also talks about using receiver selection of the Simulcast sources offered by the Sender via draft-lennox-mmusic-sdp-source-selection-05 . > > And now for some stuff that isn't in the document, but might want to be: > > More examples > > There should probably be one example where the offer contains 1 audio and > 2 video streams, and the answer contains 1 audio and 1 video stream (fewer > streams in response than in request); I believe that this answer would then > contain "a=recvonly" and no "a=msid" attribute on the 3rd m-line, but it's > nice to be sure. > > Interaction with a=content > > Previously, we had discussed having a "content" attribute on > MediaStreamTracks that would make a track link to an m-line with the same > "a=content" attribute. If this is still expected to work, it might be > worthy of inclusion here. > > I think that's all for this round of review. Thanks for getting it out! > > Harald > > > > > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --089e0122f0fe0a162004e1d0975a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 18, 2013 at 2:40 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
First of all, let me say that I'm very happy to see a plan that the peo= ple who have been voicing the strongest opinions in this debate are willing= to stand behind.
I believe, extremely strongly, that it is better to move forward on one pat= h, no matter what it is (as long as it's not obviously broken), than to= continue to debate. This topic has long been needing a decision.

Thus, I stand behind the technology proposed, and have no wish to change it= . The purpose of this review is to help make sure it's fully described,= and that all parties understand it the same way.

I have ignored language-only issues at this time.

Introduction, paragraph 2:

=A0 =A0The standard way of encoding this information in SDP is to have each=
=A0 =A0RTP flow (i.e., SSRC) appear on its own m-line.

This is not strictly true, since the proposal continues to use each m-line = for up to two flows, one in each direction, and some of the . Suggested rep= hrase:

=A0 One common way of encoding this information uses each M-line to
=A0 describe one media source in each direction.

"media source" is as defined in draft-westerlund-avtcore-m= ultiplex-architecture-03 section 2.1. The term is used elsewhere in the doc= ument, and seems to have this meaning. "One common" is a reflecti= on of my belief that practice has not been uniform in this area.

3.1, Bundle-only M-lines

This mechanism requires sending M-lines with port zero as part of a bundle = in an SDP OFFER.
It needs to note that this specification modifies RFC 5888 section 9.2 (the= grouping framework) by allowing such M-lines to be part of a group in an o= ffer (but I do not think it needs to be allowed in an answer).

4.1 Simple example

"It also shows unique payload across the audio and video m=3Dlines for= the Answerer that does not support BUNDLE semantics." - this doesn= 9;t make sense to me; unique payloads are needed for answerers that support= BUNDLE semantics. Copy/paste error?

Would be consistent if it said "for the Answerer that supports BUNDLE = semantics".

4.4 Multiple Video with Simulcast

If it's intended that draft-westerlund-avtcore-rtp-simulcast is = used, the ssrc-group lines should probably say SCS rather than SIMULCAST.


Regarding the Simulcast= ssrc-group based signaling, the following draft explains its usage:=A0http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00.

=A0

And now for some stuff that isn't in the document, but might want to be= :

More examples

There should probably be one example where the offer contains 1 audio and 2= video streams, and the answer contains 1 audio and 1 video stream (fewer s= treams in response than in request); I believe that this answer would then = contain "a=3Drecvonly" and no "a=3Dmsid" attribute on t= he 3rd m-line, but it's nice to be sure.

Interaction with a=3Dcontent

Previously, we had discussed having a "content" attribute on Medi= aStreamTracks that would make a track link to an m-line with the same "= ;a=3Dcontent" attribute. If this is still expected to work, it might b= e worthy of inclusion here.

I think that's all for this round of review. Thanks for getting it out!=

=A0 =A0 =A0 =A0 =A0 =A0 Harald




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

--089e0122f0fe0a162004e1d0975a-- From Christian.Groves@nteczone.com Thu Jul 18 18:08: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 1734711E8208 for ; Thu, 18 Jul 2013 18:08:47 -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 scyc7bSzxtC3 for ; Thu, 18 Jul 2013 18:08:46 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69711E8186 for ; Thu, 18 Jul 2013 18:08:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoCAAiR6FF20Z+w/2dsb2JhbAANTYM7wQ8EBAGBKoMYAQEBBAEBATUbGwoBEAsOCgkMCg8JAwIBAgEVMAYNAQUCAQGIGKN8kjQEkA8HCoNyA6xO Received: from ppp118-209-159-176.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.159.176]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Jul 2013 10:38:38 +0930 Message-ID: <51E8918C.8030006@nteczone.com> Date: Fri, 19 Jul 2013 11:08:28 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Randall Gellens References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 01:08:47 -0000 Hello Randall, I think you're mixing protocol functionality with application. From a protocol perspective I think that all you need to say is something like: Clients that have a language preference related to a media stream/s shall set the 'humintlang-send' and/or 'humintlang-recv' attribute on the applicable media stream at session establishment. Receivers of the 'humanintlang-*" attributes may then apply session handling based on the received language/s and according to local policy. For example: Call centers and PSAPs may route the session to an operator that is capable of communicating in the preferred language/s. I think this describes the protocol behaviour without requiring behaviour depending on user type. Regards, Christian On 19/07/2013 2:14 AM, Randall Gellens wrote: > Hi Christian, > > How about this text: > > Clients acting on behalf of end users are expected to set one or both > 'humintlang-send' and 'humintlang-recv' attributes on each media > stream primarily intended for human communication in an offer when > placing an outgoing session, but either ignore or take into > consideration the attributes when receiving incoming calls, based on > local configuration and capabilities. Systems acting on behalf of > call centers and PSAPs are expected to take into account the values > when processing inbound calls. > > > At 12:11 PM +1000 7/15/13, Christian Groves wrote: > >> Hello Randall and Gunnar, >> >> I think Randall's clarification would be good to have in the draft. >> I think that when a caller support the language it is sent for every >> call. Whether the language is used by a receiver depends on the >> receiver's local capability. >> >> >> Regards, Christian >> >> >> On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: >>> On 2013-07-13 10:07, Randall Gellens wrote: >>>> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >>>> >>>>> I wouldn't have thought that it would be use case specific... >>>>> i.e. i'd only include my language when I called an emergency >>>>> service. I would think an endpoint would be configured with the >>>>> information and then provide it whenever I made a call. Is that >>>>> the intent? >>>> >>>> I expect so, but then, I also didn't expect it to be used much in >>>> the person-to-person case since usually language is implied by >>>> context when calling an individual. I expect it to be used when a >>>> person is calling an call center (corporate or emergency). To put >>>> it another way, I expect a personal client to always set language >>>> on outbound calls, but in most cases to ignore it on inbound >>>> calls. I'd expect a corporate call center, as well as emergency >>>> call handling facilities, to pay attention. I should make this >>>> more clear in the draft. >>>> >>> I expect the setting to be retrieved from a personal profile >>> (likely but not necessarily stored in connection with other user >>> information and account information) and used in every call. >>> >>> /Gunnar >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From bernard_aboba@hotmail.com Thu Jul 18 19:02: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 7A5B921E8135 for ; Thu, 18 Jul 2013 19:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 WBh4R9hJyG3M for ; Thu, 18 Jul 2013 19:02:21 -0700 (PDT) Received: from blu0-omc1-s35.blu0.hotmail.com (blu0-omc1-s35.blu0.hotmail.com [65.55.116.46]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6E21E8142 for ; Thu, 18 Jul 2013 19:02:17 -0700 (PDT) Received: from BLU169-W120 ([65.55.116.9]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 19:02:17 -0700 X-TMN: [f8qLVuQU30gOGk6DxGoPqg7lRkTC/MSY33VcXZLSAQw=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d703b482-bd81-4fe3-ade3-83c8931f1022_" From: Bernard Aboba To: Jonathan Lennox Date: Thu, 18 Jul 2013 19:02:16 -0700 Importance: Normal In-Reply-To: References: , <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 02:02:17.0216 (UTC) FILETIME=[FEB29000:01CE8423] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:02:27 -0000 --_d703b482-bd81-4fe3-ade3-83c8931f1022_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan said:=20 "I don't understand how single-session multi-source transmission will work = without either a) signaling "a=3Dssrc-group DDP" decoding dependencies=2C o= r b) making various implementation-specific assumptions about the structure= of the SVC streams." =20 [BA] In terms of SDP choices for expressing layering within a single m line= =2C you can either go the a=3Dssrc-group:DDP route=2C or use distinct paylo= ad types for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified P= lan" Section 4.7 appears to advocate). =20 I'm not sure how "MST within a single session" could be expressed in SDP wi= thout BUNDLE. Was the idea to use multiple m lines and group them together= but use the same port?=20 = --_d703b482-bd81-4fe3-ade3-83c8931f1022_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jonathan said:

"I don't understand how single-session multi-source transmission will work= without either a) signaling "a=3Dssrc-group DDP" decoding dependencies=2C = or b) making various implementation-specific assumptions about the structur= e of the SVC streams."
 =3B
[BA] In terms of SDP choices for expr= essing layering within a single m line=2C you can either go the a=3Dssrc-gr= oup:DDP route=2C or use distinct payload types for each layer and RFC 5583 = a=3Dgroup:DDP (this is what "Unified Plan" Section 4.7 appears to advocate)= . =3B

I'm not sure how "MST within a single session" could be e= xpressed in SDP without BUNDLE. =3B Was the idea to use multiple m line= s and group them together but use the same port?
=
= --_d703b482-bd81-4fe3-ade3-83c8931f1022_-- From bernard_aboba@hotmail.com Thu Jul 18 19:28: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 99D7411E8256 for ; Thu, 18 Jul 2013 19:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 lOZlv8HrLyNa for ; Thu, 18 Jul 2013 19:28:39 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by ietfa.amsl.com (Postfix) with ESMTP id BB07C21F9E6B for ; Thu, 18 Jul 2013 19:28:39 -0700 (PDT) Received: from BLU169-W63 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 19:28:38 -0700 X-TMN: [MTAjnZJ0Y/1d9LjMFyQi+CeuUzfbq58WstcP1W1X4mI=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_610810f9-ce09-4112-82e8-92af5887fdd3_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Thu, 18 Jul 2013 19:28:38 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 02:28:38.0935 (UTC) FILETIME=[AD79BA70:01CE8427] Subject: [MMUSIC] Some comments on draft-ivov-mmusic-multiple-sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:28:44 -0000 --_610810f9-ce09-4112-82e8-92af5887fdd3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Overall=2C I like this draft quite a bit. Some thoughts:=20 Section 1 Yet=2C Offer/Answer implementations in SIP=0A= applications have most often used them as an envelope for a maximum=0A= of two RTP streams (SSRCs) at a time: one in each direction. The=0A= most common reason for this has been the fact these applications=0A= could not meaningfully render multiple SSRCs simultaneously. [BA] While the above is probably true of legacy O/A implementations=2C vide= o=20 implementations today frequently can and do render multiple SSRCs simultane= ously. =20 In particular=2C implementations supporting more than "point-to-point" call= s=2C often go beyond "video switching" to rendering of multiple streams=2C all declare= d on the same m-line.=20 In particular=2C where there are multiple layers as well as multiple source= s going into a mixer=2C you may see multiple SSRCs coming out of the mixer. This could happen because a single SSRC is used for all the layers from a given = source (but distinct SSRCs are used for different sources)=2C or because you have = each layer from a given source using a distinct SSRC.=20 Section 2 In cases where endpoints need to be able to detect this from the SDP=0A= Offer/Answer they could use the "max-send-ssrc" and "max-recv-ssrc"=0A= attributes defined in [MAX-SSRC]. It has to be noted however that=0A= this mechanism is still a work in progress and as such it would still=0A= need to be extended to provide ways of distinguishing between=0A= independent flows and complementary ones such as layered FEC and RTX. [BA] Keep in mind that if you don't use a single SSRC per source=2C then th= e semantics of max-send-ssrc and max-recv-ssrc become ambiguous. So you need to be abl= e to=20 express the maximum send and receive sources as well as the maximum sent an= d received layers.=20 Section 5 Another approach could be a combination of RTCP and RTP header=0A= extensions [RFC5285] in a way similar to the one employed by the=0A= Rapid Synchronisation of RTP Flows [RFC6051]. While such a mechanism=0A= is not currently defined by the IETF=2C specifying it could be=0A= relatively straightforward: [BA] Not sure about the "straightforward" part but there are advantages to = using RTP and RTCP extensions. RTP extensions allow RTP parsing to be bypassed w= hich is convenient if SRTP is used (since otherwise unless SSRCs are pre-declare= d you might have to decrypt and parse the RTP packet to figure out what layer it corresponds to). Today there are commonly used RTP configurations that = can't easily be expressed in SDP (e.g. sending individual codec layers with disti= nct SSRCs=2C but within the same RTP session) but that an RTP extension could h= elp with. The argument on the other side is that SDP O/A is reliable=2C wherea= s an RTP extension or RTCP SDES would not be. However=2C if the endgame is W= ebRTC without SDP=2C then I think we need to look for RTP/RTCP solutions for thes= e issues=2C rather than requiring an SDP dependency.=20 = --_610810f9-ce09-4112-82e8-92af5887fdd3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Overall=2C I like this draft qui= te a bit. =3B Some thoughts:

Section 1
   Yet=2C Offer/=
Answer implementations in SIP=0A=
   applications have most often used them as an envelope for a maximum=0A=
   of two RTP streams (SSRCs) at a time: one in each direction.  The=0A=
   most common reason for this has been the fact these applications=0A=
   could not meaningfully render multiple SSRCs simultaneously.

[BA]=
 While the above is probably true of legacy O/A implementations=2C video implementations today frequently can and do render multiple SSRCs simulta=
neously.  
In particular=2C implementations supporting more than "point-=
to-point" calls=2C often
go beyond "video switching" to rendering of mul=
tiple streams=2C all declared on
the same m-line. 

In particular=
=2C where there are multiple layers as well as multiple sources going
in=
to a mixer=2C you may see multiple SSRCs coming out of the mixer.  This
=
could happen because a single SSRC is used for all the layers from a given =
source
(but distinct SSRCs are used for different sources)=2C or because=
 you have each
layer from a given source using a distinct SSRC. 

=
Section 2

   In cases where endpoints need to be able to detect this=
 from the SDP=0A=
   Offer/Answer they could use the "max-send-ssrc" and "max-recv-ssrc"=0A=
   attributes defined in [MAX-SSRC].  It has to be noted=
 however that=0A=
   this mechanism is still a work in progress and as such it would still=0A=
   need to be extended to provide ways of distinguishing between=0A=
   independent flows and complementary ones such as layered FEC and RTX.
[BA] Keep in mind that if you don't use a single SSRC per source=2C th=
en the semantics
of max-send-ssrc and max-recv-ssrc become ambiguous.  S=
o you need to be able to 
express the maximum send and receive sources a=
s well as the maximum sent and
received layers. 

Section 5
   Another approach could be a combination of RTCP and RTP header=0A=
   extensions [RFC5285] in =
a way similar to the one employed by the=0A=
   Rapid Synchronisation of RTP Flows [RFC=
6051].  While such a mechanism=0A=
   is not currently defined by the IETF=2C specifying it could be=0A=
   relatively straightforward:

[BA] Not sure about the "straightforw=
ard" part but there are advantages to using
RTP and RTCP extensions.  RT=
P extensions allow RTP parsing to be bypassed which
is convenient if SRT=
P is used (since otherwise unless SSRCs are pre-declared
you might have =
to decrypt and parse the RTP packet to figure out what layer
it correspo=
nds to).  Today there are commonly used RTP configurations that can't
ea=
sily be expressed in SDP (e.g. sending individual codec layers with distinc=
t
SSRCs=2C but within the same RTP session) but that an RTP extension co=
uld help
with.  The argument on the other side is that SDP O/A is reliab=
le=2C whereas
an RTP extension or RTCP SDES would not be.  However=2C if=
 the endgame is WebRTC
without SDP=2C then I think we need to look for R=
TP/RTCP solutions for these issues=2C
rather than requiring an SDP depen=
dency.



= --_610810f9-ce09-4112-82e8-92af5887fdd3_-- From bernard_aboba@hotmail.com Thu Jul 18 19:53: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 2E65E21F99F8 for ; Thu, 18 Jul 2013 19:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 QfREpJ1-Pj+w for ; Thu, 18 Jul 2013 19:53:04 -0700 (PDT) Received: from blu0-omc1-s9.blu0.hotmail.com (blu0-omc1-s9.blu0.hotmail.com [65.55.116.20]) by ietfa.amsl.com (Postfix) with ESMTP id 63B8011E824E for ; Thu, 18 Jul 2013 19:52:54 -0700 (PDT) Received: from BLU169-W53 ([65.55.116.7]) by blu0-omc1-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 19:52:53 -0700 X-TMN: [jALCbbfY0SM1MtqvIm1IEjFcUDYoGAjaeUNHL+8xzUs=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e19360b0-68a9-4770-b130-b85922c3f90e_" From: Bernard Aboba To: Jonathan Lennox Date: Thu, 18 Jul 2013 19:52:53 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 02:52:53.0672 (UTC) FILETIME=[1090FA80:01CE842B] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 02:53:14 -0000 --_e19360b0-68a9-4770-b130-b85922c3f90e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan said:=20 > > The app-id idea is useful for multiple reasons. One reason similar RTP= extensions are used today is to avoid having to parse the payload to figur= e out what the stream is (e.g. looking for parameter sets or SEI NAL units)= . =20 >=20 > That sounds like an interesting idea=2C but unless I'm misunderstanding y= ou=2C that sounds very different from what app-id (or the correlator=2C in = Unified) is doing. Those are for identifying streams=2C whereas this sound= s more like identifying the sub-structure of a stream (i.e. which packets c= ontain parameter sets or SEIs). [BA] My understanding of the problem solved by deployed RTP extensions expr= essing layering is similar to=20 that in: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext=20 That is=2C these extensions are not used to flag packets containing paramet= er sets or SEIs. Rather the desire is to allow the MANE to avoid having to decrypt the SRTP packet to f= igure out what layer it corresponds to before deciding whether to drop or forward it. In a circums= tance where the SSRC either isn't pre-declared in SDP O/A or could correspond to multiple layers= =2C that makes some sense.=20 = --_e19360b0-68a9-4770-b130-b85922c3f90e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jonathan said:
>=3B &= gt=3B The app-id idea is useful for multiple reasons. One reason similar R= TP extensions are used today is to avoid having to parse the payload to fig= ure out what the stream is (e.g. looking for parameter sets or SEI NAL unit= s).
>=3B
>=3B That sounds like an interesting idea=2C but unle= ss I'm misunderstanding you=2C that sounds very different from what app-id = (or the correlator=2C in Unified) is doing. Those are for identifying stre= ams=2C whereas this sounds more like identifying the sub-structure of a str= eam (i.e. which packets contain parameter sets or SEIs).

[BA] My und= erstanding of the problem solved by deployed RTP extensions expressing laye= ring is similar to
that in:
http://tools.ietf= .org/html/draft-fineberg-avtext-temporal-layer-ext

That is=2C t= hese extensions are not used to flag packets containing parameter sets or S= EIs. =3B Rather the
desire is to allow the MANE to avoid having to d= ecrypt the SRTP packet to figure out what layer it
corresponds to before= deciding whether to drop or forward it. =3B In a circumstance where th= e SSRC
either isn't pre-declared in SDP O/A or could correspond to multi= ple layers=2C that makes some sense.
= --_e19360b0-68a9-4770-b130-b85922c3f90e_-- From juberti@google.com Thu Jul 18 20:43: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 2D7B211E827D for ; Thu, 18 Jul 2013 20:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 L05K-rKYq90S for ; Thu, 18 Jul 2013 20:43:21 -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 04BD721F9C32 for ; Thu, 18 Jul 2013 20:43:20 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so139397wgg.4 for ; Thu, 18 Jul 2013 20:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fvK888CACOtUMshRNVy922pSojkQixgwX83KmFnFqIQ=; b=gtMI2h8+2sCwjgcuKbJtoXI3DAIwDHNe9Pvn91NmaVOoCT3cYvlLyg9dw2nYiGBPCl UFOo8YUIYtVe7dGjUYcHKshYnyoJfQgHwjsFaX5k9id0L5Z5B/8CGkW1nyAgEvfvBKWh P9WUoMViIJK8LogOh6r4nPiQtak4lH4tOxdFbmCr54wYC3FNELALCpaAjexhr8hDHtE2 u9ElHd93wA68B76oadYhbHt9mpuTqb6IzUjqWyn95mzWjtFak6++j3cP3SAe+nUMcWsP HuYDonyQZd1QQSY2or4ZSsXuwjCeFRTZhgAvuonENQNdRFOc5RRy94MbHOyOVFtyC6Hp EamQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=fvK888CACOtUMshRNVy922pSojkQixgwX83KmFnFqIQ=; b=JNNFrZfwIugpjT8hp66P4QvT1XRbraWBfJCz17qMKFhtavmUnOiaaV5k59yv+Hsyuy x08nLDslneJu7JKO3GRVo/sSEm9V664HYcG/I7hQ7AvDa0ZG+BIuTWucuTDn94zi+ztd 4UioW2HZrP/MfI0M5a8T0mLklNDGlBV6bVcpZriLzJeWCibLHAwGGLZaPV4+/HRrz1co u6Q7rp1DiZF4pA8s7ZC2k0+iM0KKbMtB1LeZUfXd8fw2dfFrPBxonoOE3l64Ayshkuf3 fwscykkHeAU0bV2CNw30Lbagcmnmu2I/e72h44+lux2XPBLdFIPlUjK7Gp0y//6Bhf2r 9ORw== X-Received: by 10.194.58.239 with SMTP id u15mr10525089wjq.87.1374205400118; Thu, 18 Jul 2013 20:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Thu, 18 Jul 2013 20:43:00 -0700 (PDT) In-Reply-To: <51E6FD4B.3030200@nostrum.com> References: <51E447C8.1000701@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> <51E6FD4B.3030200@nostrum.com> From: Justin Uberti Date: Thu, 18 Jul 2013 23:43:00 -0400 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7ba97b94b912b404e1d52085 X-Gm-Message-State: ALoCoQntPST6TcLdDyNEAmMIb5QDpDHEQuFD/dojwwz9Ph7nceY/Mm9AtdGESUCycTbzaBgAK2oMdxgxK2CpvkDgyqJj/4/3gBiDgWeeRfRQcw5fKjxh0WiMdQi/nffij1XFFXe+xvf3BAKXBrI9GPiLbcUgpIFdlli+cB0OkD3Jq+iSLO9TQvL7K98nGwqYGSihHOnuUYn+ Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 03:43:22 -0000 --047d7ba97b94b912b404e1d52085 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach wrote: > On 7/17/13 09:08, Stefan H=C3=A5kansson LK wrote: > >> I have a couple of specific questions/comments, coming from a very >> WebRTC centric (sorry for that) perspective: >> >> * Simulcast: In the current API model, MediaStreamTrack is about the >> lowest you can get to. And the same source (camera, microphone) can >> source several MediaStreamTrack - and each of those can use individual >> constraints for width, height, framerate, etc. So in a WebRTC context, >> there seem to me we would not need the simulcast solution you have >> included. The different resolutions can be sent as different >> MediaStreamTrack's - meaning they would be separate m-lines. >> > > That's what we meant to convey with this (section 2, bullet 1): "This doe= s > not preclude 'application level' simulcasting; i.e., the creation of > multiple media stream tracks from a single source." > > It's true that we don't broach the issue of how to indicate the need for > simulcast via a WebRTC javascript API. I think this is something that wou= ld > be future work, probably in the W3C. I'm going to leave any further > explanation to Justin, as most of the simulcast ideas in the document cam= e > from him. Consider the parallel with layered coding - in that case, you have multiple dependent encodings of the track, but it's doubtful you want the recipients to end up with multiple MediaStreamTracks and display them all in their UI. This mechanism is basically a way to say that I have a single MediaStreamTrack coming in, and while there might be multiple independent or dependent encodings of it on the wire, the recipient should only create and display a single MediaStreamTrack on its side. > > > * Direction attribute: The current WebRTC API is "sender" oriented: the >> application can select MediaStream(Track)'s to send. Would it for WebRTC >> make sense to have all m-lines being unidirectional (send/recvonly)? >> > > I understand how this makes things cleaner in general. The issue I have i= s > that it interacts poorly with legacy uses. > > > (If >> they should be sendrecv we also need to specify when a return track >> should reuse an existing m-line, and when a new m-line should be created= .) >> >> > I agree that this could stand to be spelled out more clearly. I do not > think that doing so will prove particularly controversial. > > > /a > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --047d7ba97b94b912b404e1d52085 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
On 7/17/13 09:08, Stefan H= =C3=A5kansson LK wrote:
I have a couple of specific questions/comments, coming from a very
WebRTC centric (sorry for that) perspective:

* Simulcast: In the current API model, MediaStreamTrack is about the
lowest you can get to. And the same source (camera, microphone) can
source several MediaStreamTrack - and each of those can use individual
constraints for width, height, framerate, etc. So in a WebRTC context,
there seem to me we would not need the simulcast solution you have
included. The different resolutions can be sent as different
MediaStreamTrack's - meaning they would be separate m-lines.

That's what we meant to convey with this (section 2, bullet 1): "T= his does not preclude 'application level' simulcasting; i.e., the c= reation of multiple media stream tracks from a single source."

It's true that we don't broach the issue of how to indicate the nee= d for simulcast via a WebRTC javascript API. I think this is something that= would be future work, probably in the W3C. I'm going to leave any furt= her explanation to Justin, as most of the simulcast ideas in the document c= ame from him.

Consider the parallel with layered coding - in that cas= e, you have multiple dependent encodings of the track, but it's doubtfu= l you want the recipients to end up with multiple MediaStreamTracks and dis= play them all in their UI.

This mechanism is basically a way to say that I have a = single MediaStreamTrack coming in, and while there might be multiple indepe= ndent or dependent encodings of it on the wire, the recipient should only c= reate and display a single MediaStreamTrack on its side.


* Direction attribute: The current WebRTC API is "sender" oriente= d: the
application can select MediaStream(Track)'s to send. Would it for WebRT= C
make sense to have all m-lines being unidirectional (send/recvonly)?

I understand how this makes things cleaner in general. The issue I have is = that it interacts poorly with legacy uses.


=C2=A0 (If
they should be sendrecv we also need to specify when a return track
should reuse an existing m-line, and when a new m-line should be created.)<= br>

I agree that this could stand to be spelled out more clearly. I do not thin= k that doing so will prove particularly controversial.


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

--047d7ba97b94b912b404e1d52085-- From gunnar.hellstrom@omnitor.se Thu Jul 18 21:45: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 C420221E819E for ; Thu, 18 Jul 2013 21:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 KSi+o6ry5BsB for ; Thu, 18 Jul 2013 21:45:47 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 17E9821E81AB for ; Thu, 18 Jul 2013 21:45:46 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 19 Jul 2013 06:45:29 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 81E1E3A12B for ; Fri, 19 Jul 2013 06:45:29 +0200 (CEST) Message-ID: <51E8C46E.2070202@omnitor.se> Date: Fri, 19 Jul 2013 06:45:34 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <51DBB813.4060607@nteczone.com> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com> <51E8918C.8030006@nteczone.com> In-Reply-To: <51E8918C.8030006@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:45:53 -0000 On 2013-07-19 03:08, Christian Groves wrote: > Hello Randall, > > I think you're mixing protocol functionality with application. > > From a protocol perspective I think that all you need to say is > something like: > > Clients that have a language preference related to a media stream/s > shall set the 'humintlang-send' and/or 'humintlang-recv' attribute on > the applicable media stream at session establishment. Receivers of the > 'humanintlang-*" attributes may then apply session handling based on > the received language/s and according to local policy. For example: > Call centers and PSAPs may route the session to an operator that is > capable of communicating in the preferred language/s. > > I think this describes the protocol behaviour without requiring > behaviour depending on user type. Yes, this looks better. With this wording, I see a risk that the answering part does not realize that they shall also send the attributes. So, I suggest to add "both when offering and answering" in the first sentence. With that, and a couple of other small changes, the paragraph could be: "Clients that have a language preference related to media stream/s shall set the 'humintlang-send' and/or 'humintlang-recv' attribute on the applicable media stream/s at session establishment both when offering and answering. Receivers of the 'humanintlang-*" attributes may apply session handling based on the received language preferences and according to local policy. For example: Call centers and PSAPs may route the session to an operator that is capable of communicating in the preferred language/s ." /Gunnar > > Regards, Christian > > On 19/07/2013 2:14 AM, Randall Gellens wrote: >> Hi Christian, >> >> How about this text: >> >> Clients acting on behalf of end users are expected to set one or both >> 'humintlang-send' and 'humintlang-recv' attributes on each media >> stream primarily intended for human communication in an offer when >> placing an outgoing session, but either ignore or take into >> consideration the attributes when receiving incoming calls, based on >> local configuration and capabilities. Systems acting on behalf of >> call centers and PSAPs are expected to take into account the values >> when processing inbound calls. >> >> >> At 12:11 PM +1000 7/15/13, Christian Groves wrote: >> >>> Hello Randall and Gunnar, >>> >>> I think Randall's clarification would be good to have in the draft. >>> I think that when a caller support the language it is sent for every >>> call. Whether the language is used by a receiver depends on the >>> receiver's local capability. >>> >>> >>> Regards, Christian >>> >>> >>> On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote: >>>> On 2013-07-13 10:07, Randall Gellens wrote: >>>>> At 2:49 PM +1000 7/10/13, Christian Groves wrote: >>>>> >>>>>> I wouldn't have thought that it would be use case specific... >>>>>> i.e. i'd only include my language when I called an emergency >>>>>> service. I would think an endpoint would be configured with the >>>>>> information and then provide it whenever I made a call. Is that >>>>>> the intent? >>>>> >>>>> I expect so, but then, I also didn't expect it to be used much in >>>>> the person-to-person case since usually language is implied by >>>>> context when calling an individual. I expect it to be used when a >>>>> person is calling an call center (corporate or emergency). To put >>>>> it another way, I expect a personal client to always set language >>>>> on outbound calls, but in most cases to ignore it on inbound >>>>> calls. I'd expect a corporate call center, as well as emergency >>>>> call handling facilities, to pay attention. I should make this >>>>> more clear in the draft. >>>>> >>>> I expect the setting to be retrieved from a personal profile >>>> (likely but not necessarily stored in connection with other user >>>> information and account information) and used in every call. >>>> >>>> /Gunnar >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ron.even.tlv@gmail.com Thu Jul 18 23:15: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 C0BE021F9A05 for ; Thu, 18 Jul 2013 23:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, J_CHICKENPOX_14=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 Y0lpNAAcBPs4 for ; Thu, 18 Jul 2013 23:15:42 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id E44A021E8051 for ; Thu, 18 Jul 2013 23:15:39 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id e52so2112571eek.38 for ; Thu, 18 Jul 2013 23:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=XtXSN3jYksq+5EapVlb66RN42E1Jv31Ij/eqQp85YnQ=; b=tQkpZf58V1SiVWx+HTGr8eq2CC5kqUy6lND9Ifsjalw0PL4N4LRSG2wkFnCP0LJDdP CBy7AZGOggfoFoxR5doV6nYgo7kD5CciEXrhxXdZ5R01xImbbycx3C95V8c+D/RJm5wI nhcoMnPhyy3j+kNzG9nC+8RDjoVfyeneMBt9cZvPF5w34AXaBa28xQJbsqMRmWbtNY8E jSTtO0LgixLHWgdMFp/0rA2Y5VeqoEZ7aRbrbNRrfpbspOrBkHrPKN7XmxCiPA6bm29F XyyTNkQ9loQZjweHKp9LSvGEKjwtc7Kr6Tkxtinlu9m8KOiQ5+yE2/PI1q8dx2fq4FoH UIyg== X-Received: by 10.15.36.72 with SMTP id h48mr14529081eev.33.1374214539038; Thu, 18 Jul 2013 23:15:39 -0700 (PDT) Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id l42sm24676199eeo.14.2013.07.18.23.15.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Jul 2013 23:15:38 -0700 (PDT) From: "Roni Even" To: "'Martin Thomson'" , "'Adam Roach'" References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E61C99.8040305@nostrum.com> <51E71052.7010206@nostrum.com> In-Reply-To: Date: Fri, 19 Jul 2013 09:13:48 +0300 Message-ID: <042b01ce8447$23dca410$6b95ec30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2iPpx0KPLPKa3FH2FT2Jx+TgF4AEl1xaeAlT03CcB/oFcOAI0rp0XAp9quyEB+Mynlpg5Sewg Content-Language: en-us Cc: 'Jonathan Lennox' , mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 06:15:42 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Martin Thomson > Sent: 18 July, 2013 5:21 AM > To: Adam Roach > Cc: Jonathan Lennox; mmusic@ietf.org > Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media > sources > > On 17 July 2013 14:44, Adam Roach wrote: > > On 7/17/13 16:40, Jonathan Lennox wrote: > >> > >> That said, what I still don't see is, if you have the correlator, why > >> you then actually need to send the a=ssrc in the SDP at all? The > >> correlator should be sufficient for disambiguation, and it lets the > >> sender switch the ssrc it's sending for an m-line without needing a fresh > offer/answer. > > > > > > That might be worth exploring. I honestly haven't given it a whole lot > > of thought. Perhaps Justin or Martin have a more well-formed opinion > > on the topic? > > I did consider this, but there are several reasons that I prefer to have > signaling. The main one being that it is the only guaranteed way to get this > information through. In the happy cases, the RTP header is enough, but if > you are losing packets at session startup (a real possibility in some > configurations), or RTP header extensions are being dropped, or you need to > communicate about an in progress stream and can't guarantee that you can > cause the sender to re-send a few packets with the header extension, or ... > > Basically, there are too many ways for the RTP extension to break. > Not enough that it isn't hugely valuable for dealing with the race, but it can't > be the only mechanism that you rely on. [Roni Even] One of the reasons we have also SDES message with the ID is because the header extension is optional and can be removed on the path. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gunnar.hellstrom@omnitor.se Thu Jul 18 23:16: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 C98D821E8051 for ; Thu, 18 Jul 2013 23:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 attxLgl4mnzP for ; Thu, 18 Jul 2013 23:16:44 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id ED6DF11E80E4 for ; Thu, 18 Jul 2013 23:16:43 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 19 Jul 2013 08:16:29 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 02DA53A10C for ; Fri, 19 Jul 2013 08:16:29 +0200 (CEST) Message-ID: <51E8D9C1.9050804@omnitor.se> Date: Fri, 19 Jul 2013 08:16:33 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51E322C9.4040002@omnitor.se> In-Reply-To: <51E322C9.4040002@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - absolute preferences X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 06:16:50 -0000 We also have the need for absolute preferences to handle and decide on. On 2013-07-15 00:14, Gunnar Hellstrom wrote: > 3. Absolute preference is still needed. > I described earlier the need for an absolute preference indication. But I did not provide any coding proposal. > I suggest to add something at the end of the language tag. Regardless if it gets before or after the * if it is there. > Can a "+" be used to indicate a strongly preferred language and modality, no extra specification a managed language and modality > and a "-" a non-preferred, but possible language and modality. The background was in an earlier mail: There is also a need for absolute preference. Or relative order of preference between media. It is easy to use a sign language example fort that situation. A person prefers to use British sign language in both directions but is capable with some reluctance to use English text. That is natural. Text is always slower and less expressive than sign language or spoken language. A call goes to a call center that declared spoken English and English text in both directions. The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English. An ability to declare that the British sign language is preferred over the English text would result in the invocation of the sign relay service and make both sides happy with a call with good flow. Without the relative preference between media, the call will likely result in the direct text communication that will work but with less satisfaction. This can be solved either by an absolute preference indication : British sing language *preferred* , English text *managed* Or by some order of preference between the media; video *preferred* text *managed* I think an absolute preference indication is easiest to handle. Media preference will collide with relative preference between languages in each medium. I suggest that that is introduced with some suitable coding. It seems best t enter this in a paragraph in 7.1. I also propose that 7.1 is subdivided in subsections to make it easier to navigate. This addition would fit as a paragraph after this existing one: " In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive. In cases where the user wishes to use one media for sending and another for receiving (such as a speech-impaired user who wishes to send using text and receive using audio), one of the two will be unset. In other cases, both SHOULD have the same values in the same order. The two SHOULD NOT be set to languages which are difficult to match together (e.g., specifying a desire to send audio in Hungarian and receive audio in Portuguese will make it difficult to successfully complete the call)." I suggest to add this paragraph: " In order to express order of preference between different media, an absolute preference indication MAY be inserted in the attribute, after the language tag. An exclamation mark "!" is used to indicate a strongly preferred language and modality, no addition is used to indicate a managed language and modality, and a hash sign "#" is used to indicate a non-preferred but possible fall-back language and modality. An example can be a person who prefers to use British sign language in both directions but is capable with some reluctance to use English text, calling a call center that has competence for spoken English and English text in both directions. The result can be a direct connection using English text, or invocation of a sign relay service translating between British sign language and spoken English. The preference indication on British sign language guides the call centre in this case to invoke a relay service to get most satisfaction in the call, while in another case, a relay service for the discovered gap between the preferred languages might not be available, and then the fall-back to English text is a viable alternative. " Introduction of this coding with "!" , nothing, and "#" creates a need for a syntax chapter, where the allowed combinations of the language tag, these markers and the "*" for connect anyway are described more formally. Regards, Gunnar From fluffy@iii.ca Fri Jul 19 07:49: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 418C511E8145 for ; Fri, 19 Jul 2013 07:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619, SARE_HTML_USL_OBFU=1.666] 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 saOd2lWy45B9 for ; Fri, 19 Jul 2013 07:49:37 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA6421F9FFB for ; Fri, 19 Jul 2013 07:49:37 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 75ABC50A85; Fri, 19 Jul 2013 10:49:36 -0400 (EDT) References: <51E447C8.1000701@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> <51E6FD4B.3030200@nostrum.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-594AF96B-D775-40EE-B9BC-3F519E512D8C Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 07:49:37 -0700 To: Justin Uberti Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:49:42 -0000 --Apple-Mail-594AF96B-D775-40EE-B9BC-3F519E512D8C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is weird - I see your reply but i don't see Stephan's email=20 On Jul 18, 2013, at 8:43 PM, Justin Uberti wrote: >=20 >=20 >=20 > On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach wrote: >> On 7/17/13 09:08, Stefan H=C3=A5kansson LK wrote: >>> I have a couple of specific questions/comments, coming from a very >>> WebRTC centric (sorry for that) perspective: >>>=20 >>> * Simulcast: In the current API model, MediaStreamTrack is about the >>> lowest you can get to. And the same source (camera, microphone) can >>> source several MediaStreamTrack - and each of those can use individual >>> constraints for width, height, framerate, etc. So in a WebRTC context, >>> there seem to me we would not need the simulcast solution you have >>> included. The different resolutions can be sent as different >>> MediaStreamTrack's - meaning they would be separate m-lines. >>=20 >> That's what we meant to convey with this (section 2, bullet 1): "This doe= s not preclude 'application level' simulcasting; i.e., the creation of multi= ple media stream tracks from a single source." >>=20 >> It's true that we don't broach the issue of how to indicate the need for s= imulcast via a WebRTC javascript API. I think this is something that would b= e future work, probably in the W3C. I'm going to leave any further explanati= on to Justin, as most of the simulcast ideas in the document came from him. >=20 > Consider the parallel with layered coding - in that case, you have multipl= e dependent encodings of the track, but it's doubtful you want the recipient= s to end up with multiple MediaStreamTracks and display them all in their UI= . >=20 > This mechanism is basically a way to say that I have a single MediaStreamT= rack coming in, and while there might be multiple independent or dependent e= ncodings of it on the wire, the recipient should only create and display a s= ingle MediaStreamTrack on its side. >>=20 >>=20 >>> * Direction attribute: The current WebRTC API is "sender" oriented: the >>> application can select MediaStream(Track)'s to send. Would it for WebRTC= >>> make sense to have all m-lines being unidirectional (send/recvonly)? >>=20 >> I understand how this makes things cleaner in general. The issue I have i= s that it interacts poorly with legacy uses. >>=20 >>=20 >>> (If >>> they should be sendrecv we also need to specify when a return track >>> should reuse an existing m-line, and when a new m-line should be created= .) >>=20 >> I agree that this could stand to be spelled out more clearly. I do not th= ink that doing so will prove particularly controversial. >>=20 >>=20 >> /a >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-594AF96B-D775-40EE-B9BC-3F519E512D8C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This is weird - I see your reply but i= don't see Stephan's email 

On Jul 18, 2013, at 8:43 PM, J= ustin Uberti <juberti@google.com> wrote:



On Wed, Jul 1= 7, 2013 at 4:23 PM, Adam Roach <adam@nostrum.com> wrote:
On 7/17/13 09:08, Stefan H=C3= =A5kansson LK wrote:
I have a couple of specific questions/comments, coming from a very
WebRTC centric (sorry for that) perspective:

* Simulcast: In the current API model, MediaStreamTrack is about the
lowest you can get to. And the same source (camera, microphone) can
source several MediaStreamTrack - and each of those can use individual
constraints for width, height, framerate, etc. So in a WebRTC context,
there seem to me we would not need the simulcast solution you have
included. The different resolutions can be sent as different
MediaStreamTrack's - meaning they would be separate m-lines.

That's what we meant to convey with this (section 2, bullet 1): "This does n= ot preclude 'application level' simulcasting; i.e., the creation of multiple= media stream tracks from a single source."

It's true that we don't broach the issue of how to indicate the need for sim= ulcast via a WebRTC javascript API. I think this is something that would be f= uture work, probably in the W3C. I'm going to leave any further explanation t= o Justin, as most of the simulcast ideas in the document came from him.

Consider the parallel with layered coding - in that case= , you have multiple dependent encodings of the track, but it's doubtful you w= ant the recipients to end up with multiple MediaStreamTracks and display the= m all in their UI.

This mechanism is basically a way to say that I have a s= ingle MediaStreamTrack coming in, and while there might be multiple independ= ent or dependent encodings of it on the wire, the recipient should only crea= te and display a single MediaStreamTrack on its side.


* Direction attribute: The current WebRTC API is "sender" oriented: the
application can select MediaStream(Track)'s to send. Would it for WebRTC
= make sense to have all m-lines being unidirectional (send/recvonly)?

I understand how this makes things cleaner in general. The issue I have is t= hat it interacts poorly with legacy uses.


  (If
they should be sendrecv we also need to specify when a return track
should reuse an existing m-line, and when a new m-line should be created.)

I agree that this could stand to be spelled out more clearly. I do not think= that doing so will prove particularly controversial.
<= div class=3D"h5">

/a
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/mmusic

____________________= ___________________________
mmusic mailing list
mmusic@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mmusic">https://www.ietf.org= /mailman/listinfo/mmusic
= --Apple-Mail-594AF96B-D775-40EE-B9BC-3F519E512D8C-- From fluffy@iii.ca Fri Jul 19 07: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 55E6911E8249 for ; Fri, 19 Jul 2013 07:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 0STZBhFY--iA for ; Fri, 19 Jul 2013 07:53:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E87EB21E80EA for ; Fri, 19 Jul 2013 07:53:04 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 279E850A84; Fri, 19 Jul 2013 10:53:04 -0400 (EDT) References: <51E447C8.1000701@nostrum.com> In-Reply-To: <51E447C8.1000701@nostrum.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <539DC64D-8D51-4803-9EF0-5046D5C92AC6@iii.ca> Cc: "mmusic@ietf.org" X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 07:53:04 -0700 To: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:53:16 -0000 I like this - it looks like a reasonable way forward=20 On Jul 15, 2013, at 12:04 PM, Adam Roach wrote: > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] >=20 > After significant work, Justin, Martin and I have managed to produce a com= promise plan that provides a high degree of interoperability with existing d= evices (and future non-WebRTC devices) while not being excessively onerous f= or WebRTC implementations or applications that use them. It's been a tricky b= alancing act, but I think we've found a good mix between the two that can fo= rm a solid basis for the working group to move forward. >=20 > Rather than summarize the key points of the document in this email, I dire= ct interested parties to section 2 of the document, which summarizes the key= aspects of the plan in eight relatively concise bullet points. >=20 > I apologize for the late publication date of this document -- there's actu= ally been a lot more work put into coming up with a unified draft than I ori= ginally anticipated, and the production of this document took at least two w= eeks longer than I expected it to. >=20 > Note that this document is intended to be a plan for the work to be done i= n this area, and not a specification in itself. The intention is that its co= ntents are used as the basis for work in several other drafts -- some new, s= ome not -- that form the corpus of work necessary for RTCWEB (and potentiall= y CLUE) to move forward. Except in rare cases, the document does not attempt= to explicitly call out venues or documents for such work, as we (or, at the= very least, I) anticipate guidance from the various working group chairs to= assist in such decisions. >=20 > Comments prior to Berlin would be very helpful, although this will clearly= be a point of significant discussion at the face-to-face meeting. >=20 > Document link: >=20 > http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt >=20 > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From jonathan@vidyo.com Fri Jul 19 07:55: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 6423B21E80E1 for ; Fri, 19 Jul 2013 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 3PkSFa5FqygH for ; Fri, 19 Jul 2013 07:54:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEFC11E8249 for ; Fri, 19 Jul 2013 07:54:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CFD258BE947; Fri, 19 Jul 2013 10:54:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 80EBA8BE830; Fri, 19 Jul 2013 10:54:42 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Fri, 19 Jul 2013 10:54:22 -0400 From: Jonathan Lennox To: Bernard Aboba Date: Fri, 19 Jul 2013 10:54:26 -0400 Thread-Topic: [MMUSIC] RFC 6190 Single Session Transport Thread-Index: Ac6Ej4v+6jWzG2xqSoq9enQcMW5ZTg== Message-ID: <3AD93742-DBA4-4EDD-80AD-A667994ECE8D@vidyo.com> References: , <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3AD93742DBA44EDD80ADA667994ECE8Dvidyocom_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:55:03 -0000 --_000_3AD93742DBA44EDD80ADA667994ECE8Dvidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 18, 2013, at 10:02 PM, Bernard Aboba > wrote: Jonathan said: "I don't understand how single-session multi-source transmission will work = without either a) signaling "a=3Dssrc-group DDP" decoding dependencies, or = b) making various implementation-specific assumptions about the structure o= f the SVC streams." [BA] In terms of SDP choices for expressing layering within a single m line= , you can either go the a=3Dssrc-group:DDP route, or use distinct payload t= ypes for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified Plan"= Section 4.7 appears to advocate). I'm not sure how "MST within a single session" could be expressed in SDP wi= thout BUNDLE. Was the idea to use multiple m lines and group them together= but use the same port? I think the authors of RFC 6190 didn't see a use case for MST within a sing= le RTP session -- all of the interesting MST use cases they saw involved se= parate transport flows for the separate layers, and if you're sending all t= he layers on a single transport flow, SST is significantly simpler. What requirement are you trying to achieve that's met by MST in a single se= ssion, but not by SST? -- Jonathan Lennox jonathan@vidyo.com --_000_3AD93742DBA44EDD80ADA667994ECE8Dvidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Jul 18, 2013, at 10:02 PM, Bernard Aboba <bernard_aboba@hotmail.com> wro= te:

=
Jonathan said: = ;

"I don't understand how single-session multi-source tr= ansmission will work without either a) signaling "a=3Dssrc-group DDP" decod= ing dependencies, or b) making various implementation-specific assumptions = about the structure of the SVC streams."
 
[BA] In terms of SDP = choices for expressing layering within a single m line, you can either go t= he a=3Dssrc-group:DDP route, or use distinct payload types for each layer a= nd RFC 5583 a=3Dgroup:DDP (this is what "Unified Plan" Section 4.7 appears = to advocate).  
<= br>I'm not sure how "MST within a single session" could be expressed in SDP= without BUNDLE.  Was the idea to use multiple m lines and group them = together but use the same port? =

I think the author= s of RFC 6190 didn't see a use case for MST within a single RTP session -- = all of the interesting MST use cases they saw involved separate transport f= lows for the separate layers, and if you're sending all the layers on a sin= gle transport flow, SST is significantly simpler.

= What requirement are you trying to achieve that's met by MST in a single se= ssion, but not by SST?

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_3AD93742DBA44EDD80ADA667994ECE8Dvidyocom_-- From jonathan@vidyo.com Fri Jul 19 07: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 0541B11E82B8 for ; Fri, 19 Jul 2013 07:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 wp3cKbiCyKwp for ; Fri, 19 Jul 2013 07:58:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 570D421F9D7E for ; Fri, 19 Jul 2013 07:58:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4CFF5555898; Fri, 19 Jul 2013 10:58:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D99C65555D7; Fri, 19 Jul 2013 10:58:41 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Fri, 19 Jul 2013 10:58:38 -0400 From: Jonathan Lennox To: Bernard Aboba Date: Fri, 19 Jul 2013 10:58:41 -0400 Thread-Topic: [MMUSIC] Unified Plan for SDP Handling Thread-Index: Ac6EkCQY5opzlhPtTjiBk2TQ8h2KsA== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FD522196DA2F4E0185D20A932F404A87vidyocom_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 14:59:04 -0000 --_000_FD522196DA2F4E0185D20A932F404A87vidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 18, 2013, at 10:52 PM, Bernard Aboba > wrote: Jonathan said: > > The app-id idea is useful for multiple reasons. One reason similar RTP = extensions are used today is to avoid having to parse the payload to figure= out what the stream is (e.g. looking for parameter sets or SEI NAL units). > > That sounds like an interesting idea, but unless I'm misunderstanding you= , that sounds very different from what app-id (or the correlator, in Unifie= d) is doing. Those are for identifying streams, whereas this sounds more li= ke identifying the sub-structure of a stream (i.e. which packets contain pa= rameter sets or SEIs). [BA] My understanding of the problem solved by deployed RTP extensions expr= essing layering is similar to that in: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext That is, these extensions are not used to flag packets containing parameter= sets or SEIs. Rather the desire is to allow the MANE to avoid having to decrypt the SRTP packet to f= igure out what layer it corresponds to before deciding whether to drop or forward it. In a circums= tance where the SSRC either isn't pre-declared in SDP O/A or could correspond to multiple layers= , that makes some sense. I agree what you're describing is similar to the Fineberg draft, and a comm= on mechanism (codec-independent, to the extent possible) would likely be us= eful. I don't think it's very similar to app-id, though -- unless you're assuming= MST here too, and you're trying to identify the component MST streams of a= layered encoding? -- Jonathan Lennox jonathan@vidyo.com --_000_FD522196DA2F4E0185D20A932F404A87vidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Jul 18, 2013, at 10:52 PM, Bernard Aboba <bernard_aboba@hotmail.com> wro= te:

=
Jonathan said: = ;
> > The app-id idea is useful for multiple reasons. = One reason similar RTP extensions are used today is to avoid having to pars= e the payload to figure out what the stream is (e.g. looking for parameter = sets or SEI NAL units). <= br>> 
> That sou= nds like an interesting idea, but unless I'm misunderstanding you, that sou= nds very different from what app-id (or the correlator, in Unified) is doin= g. Those are for identifying streams, whereas this sounds more like identif= ying the sub-structure of a stream (i.e. which packets contain parameter se= ts or SEIs).

[BA] My understanding of the problem solved by deployed= RTP extensions expressing layering is similar to 
that in:
http://tool= s.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext 

That is, these extensions are n= ot used to flag packets containing parameter sets or SEIs.  Rather the=
desire is to allow the MANE to avoid having to decrypt the SRTP packet = to figure out what layer it
corresponds to before deciding whether to dr= op or forward it.  In a circumstance where the SSRC
either isn't pr= e-declared in SDP O/A or could correspond to multiple layers, that makes so= me sense. 

I agree what you're describing is simila= r to the Fineberg draft, and a common mechanism (codec-independent, to the = extent possible) would likely be useful.

I don't t= hink it's very similar to app-id, though -- unless you're assuming MST here= too, and you're trying to identify the component MST streams of a layered = encoding?

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_FD522196DA2F4E0185D20A932F404A87vidyocom_-- From creslin@digium.com Thu Jul 18 14:28: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 B599F11E8217 for ; Thu, 18 Jul 2013 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 jO1V3qrDTCIZ for ; Thu, 18 Jul 2013 14:28:14 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA4A11E820B for ; Thu, 18 Jul 2013 14:28:13 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eh20so614063lab.1 for ; Thu, 18 Jul 2013 14:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=KVnlSjEPzpdK5XcfW0tRhKM5xAc92E0FxDELmUDkS4I=; b=bRZZvJe6whT3MQ7HSxan5lozGrN+vAKcEoHuXUehwMpLWOHSL+iLx3JJfoPwDSGuih D/0YSqn6UpqpeDyowLzwsuT8HfiYEH5+4vrpynqM5YnXutsLQwPchzYLBhHndnsFlQUf UbhAoTIbWpPQRyYf7XSqBDONyP0QLhftZcChOQKJOe4uKTPJxoZTW/JqYiOXdABTk0wy N3+JW6LXBzrFeHyPpclsHuf4Jb+tX0PFUfTMq/chAGn/moZZ8flXmk7BhlIGBvJoxZ80 mAbs8vjWW8fL/uQXtvohm1kPbeM7rPzYRH7M0uj9YzpqqJ5ESWJGdNHeemkGiwqf6+T9 qQjA== MIME-Version: 1.0 X-Received: by 10.152.115.194 with SMTP id jq2mr5974367lab.53.1374182892162; Thu, 18 Jul 2013 14:28:12 -0700 (PDT) Received: by 10.112.141.161 with HTTP; Thu, 18 Jul 2013 14:28:12 -0700 (PDT) In-Reply-To: <51E447C8.1000701@nostrum.com> References: <51E447C8.1000701@nostrum.com> Date: Thu, 18 Jul 2013 16:28:12 -0500 Message-ID: From: Matt Fredrickson To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3574c24dcd804e1cfe38c X-Gm-Message-State: ALoCoQnJIzVmegOk+OeEyWVqjyihbAznL+J/tC7CDZVZKII0enomzJnlyd78qTp6FYdwYQTz9GL1 X-Mailman-Approved-At: Fri, 19 Jul 2013 09:56:18 -0700 Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 21:28:18 -0000 --001a11c3574c24dcd804e1cfe38c Content-Type: text/plain; charset=ISO-8859-1 Please forgive me for coming a bit late to the discussion on this, but what types of "legacy devices" are being targeted? At least from what I have seen, most legacy equipment doesn't support ICE, definitely does not support DTLS-SRTP, most do not support SDES-SRTP, none bundling, none rtcp-mux, etc. I believe that there might be some sort of legacy interop with disabling of bundling, rtcp-mux possibly as well, and supporting SDES or non encrypted sessions. Otherwise, I don't know what legacy devices means in the context. Is there a place where a definition of a "legacy device" (as mentioned in your draft) is given in the webrtc specs? Matthew Fredrickson On Mon, Jul 15, 2013 at 2:04 PM, Adam Roach wrote: > [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] > > After significant work, Justin, Martin and I have managed to produce a > compromise plan that provides a high degree of interoperability with > existing devices (and future non-WebRTC devices) while not being > excessively onerous for WebRTC implementations or applications that use > them. It's been a tricky balancing act, but I think we've found a good mix > between the two that can form a solid basis for the working group to move > forward. > > Rather than summarize the key points of the document in this email, I > direct interested parties to section 2 of the document, which summarizes > the key aspects of the plan in eight relatively concise bullet points. > > I apologize for the late publication date of this document -- there's > actually been a lot more work put into coming up with a unified draft than > I originally anticipated, and the production of this document took at least > two weeks longer than I expected it to. > > Note that this document is intended to be a plan for the work to be done > in this area, and not a specification in itself. The intention is that its > contents are used as the basis for work in several other drafts -- some > new, some not -- that form the corpus of work necessary for RTCWEB (and > potentially CLUE) to move forward. Except in rare cases, the document does > not attempt to explicitly call out venues or documents for such work, as we > (or, at the very least, I) anticipate guidance from the various working > group chairs to assist in such decisions. > > Comments prior to Berlin would be very helpful, although this will clearly > be a point of significant discussion at the face-to-face meeting. > > Document link: > > http://www.ietf.org/id/draft-**roach-mmusic-unified-plan-00.**txt > > /a > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --001a11c3574c24dcd804e1cfe38c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please forgive me for coming a bit late to the discussion = on this, but what types of "legacy devices" are being targeted? = =A0At least from what I have seen, most legacy equipment doesn't suppor= t ICE, definitely does not support DTLS-SRTP, most do not support SDES-SRTP= , none bundling, none rtcp-mux, etc.

I believe that there might be some sort of legacy interop wi= th disabling of bundling, rtcp-mux possibly as well, and supporting SDES or= non encrypted sessions. =A0Otherwise, I don't know what legacy devices= means in the context.

Is there a place where a definition of a "legacy d= evice" (as mentioned in your draft) is given in the webrtc specs?

Matthew Fredrickson


On Mon, Jul 15, 2013 at 2:04 PM, Adam Ro= ach <adam@nostrum.com> wrote:
[Cross-posting to RTCWEB; follow-ups to MMUSIC, please]

After significant work, Justin, Martin and I have managed to produce a comp= romise plan that provides a high degree of interoperability with existing d= evices (and future non-WebRTC devices) while not being excessively onerous = for WebRTC implementations or applications that use them. It's been a t= ricky balancing act, but I think we've found a good mix between the two= that can form a solid basis for the working group to move forward.

Rather than summarize the key points of the document in this email, I direc= t interested parties to section 2 of the document, which summarizes the key= aspects of the plan in eight relatively concise bullet points.

I apologize for the late publication date of this document -- there's a= ctually been a lot more work put into coming up with a unified draft than I= originally anticipated, and the production of this document took at least = two weeks longer than I expected it to.

Note that this document is intended to be a plan for the work to be done in= this area, and not a specification in itself. The intention is that its co= ntents are used as the basis for work in several other drafts -- some new, = some not -- that form the corpus of work necessary for RTCWEB (and potentia= lly CLUE) to move forward. Except in rare cases, the document does not atte= mpt to explicitly call out venues or documents for such work, as we (or, at= the very least, I) anticipate guidance from the various working group chai= rs to assist in such decisions.

Comments prior to Berlin would be very helpful, although this will clearly = be a point of significant discussion at the face-to-face meeting.

Document link:

http://www.ietf.org/id/draft-roach-mmusic-unified-p= lan-00.txt

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

--001a11c3574c24dcd804e1cfe38c-- From christer.holmberg@ericsson.com Sat Jul 20 02:51: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 65F3A21E8085 for ; Sat, 20 Jul 2013 02:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 pnOIzdX-Kd9e for ; Sat, 20 Jul 2013 02:51:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6040321E804D for ; Sat, 20 Jul 2013 02:51:24 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-56-51ea5d99232a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2A.99.19388.99D5AE15; Sat, 20 Jul 2013 11:51:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Sat, 20 Jul 2013 11:51:21 +0200 From: Christer Holmberg To: Adam Roach , Paul Kyzivat Thread-Topic: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare Thread-Index: Ac6FLNZDJiUB1pFYSza6h1JrrPeg6w== Date: Sat, 20 Jul 2013 09:51:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3D918D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3D918DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre7M2FeBBo9WKljs+buI3WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fAlbF1YTtbwdJuxopLL94z NjBOquhi5OSQEDCR+N3QzwJhi0lcuLeerYuRi0NI4DCjxLU9rewQzmJGiRt7pgJlODjYBCwk uv9pgzSICLhLnHpwmRkkzCygLnF1cRBIWFjAReLahQXMECWuEh9W/2GFsPUk5s/4xQJSziKg KvHvDw9ImFfAV2L5+S3sIDYj0AnfT61hArGZBcQlPhy8zgxxmoDEkj3noWxRiZeP/7FC2EoS jUuesELU50v0XF/EBDFTUOLkzCcsExiFZyEZNQtJ2SwkZRBxPYkbU6ewQdjaEssWvoaq15WY 8e8QC7L4Akb2VYzsuYmZOenl5psYgVFzcMtvgx2Mm+6LHWKU5mBREufdrHcmUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVAOjuvTE9Qs6dyxYuv3rm/zgJsbitLtr1I5mxT50YOy07O4onWIo PT/5n4HL+vZjT2SmyS16HHO1UWHhvvUvE6cZHz3vJe3yJWtr2M0dfedtl0tUzz4RYrLqEOu1 1omsfy/HH28p+Rkcesnu59Zujvkl90T/GfCLbdn613NyZ9e6HfeOvvo8bcpfKSWW4oxEQy3m ouJEABwQkqxoAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 09:51:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3D918DESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I do realize that the draft does not represent the complete glare solution. Paul has raised some issues/questions, and I also have some. I'll leave the= SDP low-level ones for now, and only raise a few high-level ones. Q1: How essential part of the unified plan is having *A* working "partial o= /a" solution? TECHNICALLY, the other parts of the unified plan do not depen= d on having a "partial o/a" solution, but I would like to know whether peop= le (specially the draft authors) would be willing to move ahead with unifie= d plan even if we would not manage to specify a working "partial o/a" solut= ion. Q2a: When sending a partial offer, the draft says that only the m=3D line e= xplicitly signaled is affected. Note, however, that you will still signal i= nformation (e.g. the SDP version value, the group:BUNDLE attribute etc) whi= ch affect the whole SDP, and if you have multiple outstanding partial offer= s (for different m=3D lines) that can cause issues. Q2b: In addition, when using BUNDLE, modifying an m=3D line might implicitl= y modify other m=3D lines, and there are rules (also indicated in the draft= ) mandating identical SDP attribute values etc. So, if you have multiple ou= tstanding partial offers, you may end up with all kind of different "BUNDLE= collisions". Q3: If I send a partial offer, for a given m=3D line, can the answer only c= ontain that given m=3D line? What if the partial offer causes other m=3D li= nes to be modified? Regards, Christer L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Adam Roach L=E4hetetty: 17. hein=E4kuuta 2013 20:08 Vastaanottaja: Paul Kyzivat Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling On 7/17/13 11:38, Paul Kyzivat wrote: Adam, While I see there can be some value to extending O/A to allow for smaller c= ritical sections, I fear that it is going to be very messy to get "right". = Some messy things: - Glare between a partial O/A and a full O/A ...is glare. Resolve as normal. For SIP, that means timers. - Is a partial O/A permitted in a sip reINVITE? Can you have an offerless reINVITE where the response contains a partial offer? Or can these only be done in UPDATE? No, no, and no. In SIP, the protocol machinery would not allow INVITE or UP= DATE to complete concurrently in opposite directions for any amount of over= lap. We aren't proposing a change to SIP state machines here, only to the o= ffer/answer model. This necessarily means that we need to carry partial off= ers and partial answers in something else -- probably INFO. - In SIP, processing of concurrent reINVITEs/UPDATEs containing partial SDP updates. This seems to already be a You left this unfinished, but I *think* it was going to make the same point= I did in my response above. - How to assign version numbers to the full SDP as a result of partial updates Section 3.4.1: "... the SDP version is incremented by one..." - I'm not sure your algorithm for resolving glare when adding streams works in all cases. (More below on this.) These (and ones I haven't thought of) *may* all be resolvable. But this cer= tainly complicates the already complex O/A process - maybe to the point tha= t many get it wrong. (I don't want to write rfc6337bis!) My concern with the glare resolution algorithm is that for it to work both = sides must realize that glare occurred. And I think there are common sequen= ces when one side won't realize it. I'm not saying I didn't miss it, but I did work through as many permutation= s as I could think of, and none of them are left out by the algorithm descr= ibed in section 3.4.1. That said, I did my analysis in the context of WebRTC, and assumed a reliab= le, in-order delivery channel for messages. I recognize that we don't have = that for SIP, and that messages in the same direction can be reordered. I a= dmit that this does raise some interesting scenarios that may require addit= ional work to resolve. I'm reluctant to buy into a scheme that depends on this without knowing it = it will be implementable. I understand your reluctance, and don't want to gloss over it. This is but = one plank in the overall plan, and it represents what we think is the best = (but not only) solution to this specific requirement. If the issues prove i= ntractable, we could fall back to an alternate scheme, such as the designat= ed-offerer I describe in draft-roach-rtcweb-glareless-add-00, or the token-= passing scheme described by Ted Hardie (cf. http://www.ietf.org/mail-archiv= e/web/rtcweb/current/msg07361.html). /a --_000_7594FB04B1934943A5C02806D1A2204B1C3D918DESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

Hi,

 = ;

I do reali= ze that the draft does not represent the complete glare solution.

 = ;

Paul has r= aised some issues/questions, and I also have some. I’ll leave the SDP= low-level ones for now, and only raise a few high-level ones.

 = ;

Q1: How essential part of the= unified plan is having *A* working “partial o/a” solution? TECH= NICALLY, the other parts of the unified plan do not depend on having a R= 20;partial o/a” solution, but I would like to know whether people (sp= ecially the draft authors) would be willing to move ahead with unified plan even if we would not manage to specify a working “= partial o/a” solution.

 = ;

Q2a: When sending a partial o= ffer, the draft says that only the m=3D line explicitly signaled is affected. Note, = however, that you will still signal information (e.g. the SDP version value= , the group:BUNDLE attribute etc) which affect the whole SDP, and if you ha= ve multiple outstanding partial offers (for different m=3D lines) that can cause issues.

 = ;

Q2b: In addition, when using = BUNDLE, modifying an m=3D line might implicitly modify other m=3D lines, and there= are rules (also indicated in the draft) mandating identical SDP attribute = values etc. So, if you have multiple outstanding partial offers, you may en= d up with all kind of different “BUNDLE collisions”.

 = ;

Q3: If I send a partial offer= , for a given m=3D line, can the answer only contain that given m=3D line? What if= the partial offer causes other m=3D lines to be modified?

 = ;

 = ;

Regards,

 = ;

Christer

 = ;

 = ;

 = ;

 = ;

 = ;

L=E4h= ett=E4j=E4: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Adam Roach
L=E4hetetty: 17. hein=E4kuuta 2013 20:08
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@ietf.org
Aihe: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling=

 

On 7/17/13 11:38, Paul Kyzivat wrote:

Adam,

While I see there can be some value to extending O/A to allow for smaller c= ritical sections, I fear that it is going to be very messy to get "rig= ht". Some messy things:

- Glare between a partial O/A and a full O/A


...is glare. Resolve as normal. For SIP, that means timers.


- Is a partial O/A permitted in a sip reINVITE? Can = you have
  an offerless reINVITE where the response contains a partial offer? <= br>   Or can these only be done in UPDATE?


No, no, and no. In SIP, the protocol machinery would not allow INVITE or UP= DATE to complete concurrently in opposite directions for any amount of over= lap. We aren't proposing a change to SIP state machines here, only to the o= ffer/answer model. This necessarily means that we need to carry partial offers and partial answers in somethin= g else -- probably INFO.


- In SIP, processing of concurrent reINVITEs/UPDATEs= containing
  partial SDP updates. This seems to already be a


You left this unfinished, but I *think* it was going to make the same point= I did in my response above.


- How to assign version numbers to the full SDP as a= result
  of partial updates


Section 3.4.1: "... the SDP version is incremented by one..."



- I'm not sure your algorithm for resolving glare wh= en adding
  streams works in all cases. (More below on this.)

These (and ones I haven't thought of) *may* all be resolvable. But this cer= tainly complicates the already complex O/A process - maybe to the point tha= t many get it wrong. (I don't want to write rfc6337bis!)

My concern with the glare resolution algorithm is that for it to work both = sides must realize that glare occurred. And I think there are common sequen= ces when one side won't realize it.


I'm not saying I didn't miss it, but I did work through as many permutation= s as I could think of, and none of them are left out by the algorithm descr= ibed in section 3.4.1.

That said, I did my analysis in the context of WebRTC, and assumed a reliab= le, in-order delivery channel for messages. I recognize that we don't have = that for SIP, and that messages in the same direction can be reordered. I a= dmit that this does raise some interesting scenarios that may require additional work to resolve.


I'm reluctant to buy into a scheme that depends on t= his without knowing it it will be implementable.


I understand your reluctance, and don't want to gloss over it. This is but = one plank in the overall plan, and it represents what we think is the best = (but not only) solution to this specific requirement. If the issues prove i= ntractable, we could fall back to an alternate scheme, such as the designated-offerer I describe in draft-ro= ach-rtcweb-glareless-add-00, or the token-passing scheme described by Ted H= ardie (cf. http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html).<= br>
/a

--_000_7594FB04B1934943A5C02806D1A2204B1C3D918DESESSMB209erics_-- From emil@sip-communicator.org Sat Jul 20 06:04: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 55C9B11E80FB for ; Sat, 20 Jul 2013 06:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 2JytmtOU-2nT for ; Sat, 20 Jul 2013 06:04:38 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 235F121F894E for ; Sat, 20 Jul 2013 06:04:33 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so534025wib.0 for ; Sat, 20 Jul 2013 06:04:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=m/qsbrNDw9KWGzvmYuITM6DM6dmCBDq6DfuEnrUZ5IU=; b=WcAbUkH/hCMQpOd5frszPkVX/WlmN9AGALusCrt43O8c+zrP+GdT1nbv+6CyI9kPUb vTWbppYsI50/H/k2FgyzbBB7FcKFwu2pdDGVWhYZXB1xNwDgZ8pVariB4VNOZhNaSrNc pyadN7WRWJa6I0kAJJCcNN+QXOn2h5wqbSpvxWbIqcuxzO5RvlCR1tGaJjx0YVi2VOet cujdflAn1Pcyx/hyTGMUM14xY+Oikg4Gd9nZfIg5PkYcS+qObkMClar/i0o2x+Pn8MPM fRf1h7aOWXzZDNgL90K/Fm92+q6pFBhnAgHZL4lAPUDcpzCJgVNyWUUFAZ0ExAZ0JlUP wVbA== X-Received: by 10.180.99.67 with SMTP id eo3mr13892334wib.35.1374325473165; Sat, 20 Jul 2013 06:04:33 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:d802:b1c5:c4c4:2dd8]) by mx.google.com with ESMTPSA id a6sm28821985wib.10.2013.07.20.06.04.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jul 2013 06:04:32 -0700 (PDT) Message-ID: <51EA8AE0.9000507@jitsi.org> Date: Sat, 20 Jul 2013 15:04:32 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk9yjZ81TP6MBOS+hBbNxT4P32D8JGHNdc8c+jdi65eNMmEWIKDaBTzvu5uSlhKRG4w5Ir8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Some comments on draft-ivov-mmusic-multiple-sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 13:04:42 -0000 Hey Bernard, On 19.07.13, 04:28, Bernard Aboba wrote: > Overall, I like this draft quite a bit. Some thoughts: > > Section 1 > > Yet, Offer/Answer implementations in SIP > applications have most often used them as an envelope for a maximum > of two RTP streams (SSRCs) at a time: one in each direction. The > most common reason for this has been the fact these applications > could not meaningfully render multiple SSRCs simultaneously. > > [BA] While the above is probably true of legacy O/A implementations, video > implementations today frequently can and do render multiple SSRCs simultaneously. > In particular, implementations supporting more than "point-to-point" calls, often > go beyond "video switching" to rendering of multiple streams, all declared on > the same m-line. > > In particular, where there are multiple layers as well as multiple sources going > into a mixer, you may see multiple SSRCs coming out of the mixer. This > could happen because a single SSRC is used for all the layers from a given source > (but distinct SSRCs are used for different sources), or because you have each > layer from a given source using a distinct SSRC. I agree that this is where things seem to be headed. The text was mostly referring to "legacy" SIP devices. Most of which are probably unable to handle video at all. Many of the SIP hardphones that do handle video simply don't have the user interface that would allow showing a second flow. From what I've seen such devices often simply ignore the SSRC field which leads to weird results with multiple video flows. > Section 2 > > In cases where endpoints need to be able to detect this from the SDP > Offer/Answer they could use the "max-send-ssrc" and "max-recv-ssrc" > attributes defined in [MAX-SSRC ]. It has to be noted however that > this mechanism is still a work in progress and as such it would still > need to be extended to provide ways of distinguishing between > independent flows and complementary ones such as layered FEC and RTX. > > [BA] Keep in mind that if you don't use a single SSRC per source, then the semantics > of max-send-ssrc and max-recv-ssrc become ambiguous. So you need to be able to > express the maximum send and receive sources as well as the maximum sent and > received layers. Completely agreed. That's what the text above is actually trying to say. MAX-SSRC may need further syntax/semantics or at least text that would properly address the difference between multiple independent streams (e.g. a video conf call) from multiple related streams (e.g. layers or FEC ). > Section 5 > > Another approach could be a combination of RTCP and RTP header > extensions [RFC5285 ] in a way similar to the one employed by the > Rapid Synchronisation of RTP Flows [RFC6051 ]. While such a mechanism > is not currently defined by the IETF, specifying it could be > relatively straightforward: > > [BA] Not sure about the "straightforward" part but there are advantages to using > RTP and RTCP extensions. RTP extensions allow RTP parsing to be bypassed which > is convenient if SRTP is used (since otherwise unless SSRCs are pre-declared > you might have to decrypt and parse the RTP packet to figure out what layer > it corresponds to). Today there are commonly used RTP configurations that can't > easily be expressed in SDP (e.g. sending individual codec layers with distinct > SSRCs, but within the same RTP session) but that an RTP extension could help > with. The argument on the other side is that SDP O/A is reliable, whereas > an RTP extension or RTCP SDES would not be. However, if the endgame is WebRTC > without SDP, then I think we need to look for RTP/RTCP solutions for these issues, > rather than requiring an SDP dependency. Agreed. Emil -- https://jitsi.org From stefan.lk.hakansson@ericsson.com Sat Jul 20 23:04: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 4319821F8C4C for ; Sat, 20 Jul 2013 23:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=0.678, 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 sfQORX+t+2y3 for ; Sat, 20 Jul 2013 23:04:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A046821F8BD8 for ; Sat, 20 Jul 2013 23:04:00 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-65-51eb79ce7e84 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 89.77.19388.EC97BE15; Sun, 21 Jul 2013 08:03:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Sun, 21 Jul 2013 08:03:58 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Justin Uberti Thread-Topic: [MMUSIC] Unified Plan for SDP Handling Thread-Index: AQHOgY5x7Vyx1Crt5kGKxBJDnL9f8g== Date: Sun, 21 Jul 2013 06:03:58 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C32F998@ESESSMB209.ericsson.se> References: <51E447C8.1000701@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3182B8@ESESSMB209.ericsson.se> <51E6FD4B.3030200@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre65yteBBk/O2ljs+buI3WLrVCGL qcsfszgweyzYVOqxZMlPJo9ZO5+wBDBHcdmkpOZklqUW6dslcGVcuDCNsWCGfMWp9uNMDYzv xbsYOTkkBEwkDm5uZISwxSQu3FvP1sXIxSEkcJhRYt+FKWAJIYEljBKvJueC2GwCgRJb9y1g A7FFBNQkHs7axQpiMwu4Sfz9P4MZxBYWMJZ4/30dC0SNicTznbcYIWw9iT1zD4HVsAioSizv bwazeQV8JdYc/cMEsfgao8Sbud+YQBKMQBd9P7WGCWKBuMStJ/OZIC4VkFiy5zwzhC0q8fLx P1YIW0nix4ZLLBD1ehI3pk5hg7C1JZYtfA21TFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZ xciem5iZk15uvokRGB0Ht/w22MG46b7YIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTBuSJiQU/9Xbckr4y/LzZyjS6yn+Ii379zmJSARUfVI8ppKzlZ9ew/T+T5vOVb+ qi/o/Cp4g9O28FR7X4NVYZRTxu3cvgnL1Cy/zfx67u1HJb0wWcfcevWNPMplMT/iV+dyV0Qv /X/e69eUiqhDfOpCWtPPRNh2CExaP5Vjb8rsq8feLQ5XYVFiKc5INNRiLipOBAB7xj7WXAIA AA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unified Plan for SDP Handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 06:04:06 -0000 On 7/19/13 5:43 AM, Justin Uberti wrote:=0A= >=0A= >=0A= >=0A= > On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach > wrote:=0A= >=0A= > On 7/17/13 09:08, Stefan H=E5kansson LK wrote:=0A= >=0A= > I have a couple of specific questions/comments, coming from a ver= y=0A= > WebRTC centric (sorry for that) perspective:=0A= >=0A= > * Simulcast: In the current API model, MediaStreamTrack is about = the=0A= > lowest you can get to. And the same source (camera, microphone) c= an=0A= > source several MediaStreamTrack - and each of those can use=0A= > individual=0A= > constraints for width, height, framerate, etc. So in a WebRTC=0A= > context,=0A= > there seem to me we would not need the simulcast solution you hav= e=0A= > included. The different resolutions can be sent as different=0A= > MediaStreamTrack's - meaning they would be separate m-lines.=0A= >=0A= >=0A= > That's what we meant to convey with this (section 2, bullet 1):=0A= > "This does not preclude 'application level' simulcasting; i.e., the= =0A= > creation of multiple media stream tracks from a single source."=0A= >=0A= > It's true that we don't broach the issue of how to indicate the need= =0A= > for simulcast via a WebRTC javascript API. I think this is something= =0A= > that would be future work, probably in the W3C. I'm going to leave=0A= > any further explanation to Justin, as most of the simulcast ideas in= =0A= > the document came from him.=0A= >=0A= >=0A= > Consider the parallel with layered coding - in that case, you have=0A= > multiple dependent encodings of the track, but it's doubtful you want=0A= > the recipients to end up with multiple MediaStreamTracks and display=0A= > them all in their UI.=0A= =0A= I think it is not a good parallel. With layered encoding you need the =0A= base layer to have any use of any enhancement layer. With simulcast of =0A= the other hand every stream is a complete representation and can be used = =0A= on its own.=0A= =0A= >=0A= > This mechanism is basically a way to say that I have a single=0A= > MediaStreamTrack coming in, and while there might be multiple=0A= > independent or dependent encodings of it on the wire, the recipient=0A= > should only create and display a single MediaStreamTrack on its side.=0A= =0A= That's fine. What I was saying was that in a WebRTC context we don't =0A= really need this functionality for simulcast, and using it would require = =0A= a new set of API functionality. But I understand Adam's response as that = =0A= simulcast can be solved using 'application level' simulcasting, so there = =0A= is really no issue.=0A= =0A= >=0A= >=0A= >=0A= > * Direction attribute: The current WebRTC API is "sender"=0A= > oriented: the=0A= > application can select MediaStream(Track)'s to send. Would it=0A= > for WebRTC=0A= > make sense to have all m-lines being unidirectional (send/recvonl= y)?=0A= >=0A= >=0A= > I understand how this makes things cleaner in general. The issue I=0A= > have is that it interacts poorly with legacy uses.=0A= >=0A= >=0A= > (If=0A= > they should be sendrecv we also need to specify when a return tra= ck=0A= > should reuse an existing m-line, and when a new m-line should be= =0A= > created.)=0A= >=0A= >=0A= > I agree that this could stand to be spelled out more clearly. I do=0A= > not think that doing so will prove particularly controversial.=0A= >=0A= >=0A= > /a=0A= > _________________________________________________=0A= > mmusic mailing list=0A= > mmusic@ietf.org =0A= > https://www.ietf.org/mailman/__listinfo/mmusic=0A= > =0A= >=0A= >=0A= =0A= From christer.holmberg@ericsson.com Sun Jul 21 10:49: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 5B51521F85EB for ; Sun, 21 Jul 2013 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.614 X-Spam-Level: X-Spam-Status: No, score=-5.614 tagged_above=-999 required=5 tests=[AWL=0.635, 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 4TbHez8K23WI for ; Sun, 21 Jul 2013 10:49:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA711E80F6 for ; Sun, 21 Jul 2013 10:49:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-c7-51ec1f2db051 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1B.9C.06741.D2F1CE15; Sun, 21 Jul 2013 19:49:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sun, 21 Jul 2013 19:49:33 +0200 From: Christer Holmberg To: Emil Ivov , "Stach, Thomas" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlUX4cAgAGiawCABGabgIAAbIEAgAHtwYCAABaEAIASqbgA Date: Sun, 21 Jul 2013 17:49:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> In-Reply-To: <51DC9180.5070407@jitsi.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvra6e/JtAg1mzuSzW7JzAYjF1+WMW ixUbDrBa7Npe48Di8ff9ByaPJUt+Mnn8fxPoceP2e+YAligum5TUnMyy1CJ9uwSujCOTf7IU dHFWzHxzkb2BcQp7FyMnh4SAicTe/7MZIWwxiQv31rN1MXJxCAkcZpTYNWMrO4SzhFGi5fRX oAwHB5uAhUT3P22QBhGBCIlLDxawgtjMAr4S739OBxsqLGAs0Xy0gRmkXARowesrbhDlURLz 3i5iBwmzCKhKrHtrAhLmBersenGNBcQWErjOJPFtEthETgFNiV8Ni8EmMgKd9v3UGiaITeIS Hw5eZ4Y4WUBiyZ7zULaoxMvH/1ghbCWJxiVPoC7TkViw+xMbhK0tsWzha2aIvYISJ2c+YZnA KDYLydhZSFpmIWmZhaRlASPLKkb23MTMnPRyw02MwBg6uOW37g7GU+dEDjFKc7AoifNu0jsT KCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRJYA558cn4Rk77hV3VzFnnuwJlHwcWnhTLD5l R7Gtpw/X3+6ZkW9vzKi2vX6M856YwdOofM9JDtw9B2Jvuf5fePV6wb3TEzcuP+RWtvR563Sz sCP29ytXplqtdPaTvh4+877xXGPT8BvHLh6dWaG2NEB9sQRDxf3lL/L2cyRld+770H1xT8Zp JZbijERDLeai4kQAlEdBSG8CAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Sun, 21 Jul 2013 17:49:43 -0000 Hi, As I've been on vacation, I tried to go through this thread in one sweep. I= may have missed/misunderstood some parts, and my apologies if my comments = below have already been dealt with. First, regarding 180, no matter if we use PRACK or not, SIP requires the SD= P to be identical in all 180 responses. That means you can't add new candid= ates in subsequent 180 responses (eventhough vanilla ICE uses 180s without = PRACK, the SDP is identical in all 180s, AFAIR). Second, I get a little confused when we talk about the UAS sending INFO bef= ore it knows that the dialog is established, and that we would define some = new handling rules when an error response is received. Now, IF we want the = UAC to inform the UAS that the dialog has been established, we don't need P= RACK for that. The UAC could send an INFO when it receives the 180, and whe= n the UAS receives the INFO it knows the dialog has been established. I hav= en't thought so much about it, so I am not suggesting such mechanism at thi= s point, I am only saying that it would be a possible solution from a SIP p= rotocol perspective :) Regards, Christer From emil@sip-communicator.org Sun Jul 21 11:57: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 6658A21F8F67 for ; Sun, 21 Jul 2013 11:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 6yUVw88+UAWJ for ; Sun, 21 Jul 2013 11:57:17 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id C20DE21F8D96 for ; Sun, 21 Jul 2013 11:57:16 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so1182161wib.2 for ; Sun, 21 Jul 2013 11:56:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=S5CLYrAIs0Xrdzy2Lr8uWayAE2a5F520/5oQnG+rMyQ=; b=PNB+IR4Z1wDQIcCHbPhQ/79eVbVGK/wEFvb694UbGaRGKEb0w897VvN9vhqwuL0Api RiuVp3H/JsTt5lw2t0is+7Kic0BtLrUIa0gFaeyaTl4G7+kvEjmjZkci30bd3O5R52FW WvIKRbwesnEkmEMITt0/6CmTSrwqFhXnIbK5joXZwYnLrC+xRSvfNu2og6feJYBNzeOF CDRRwjOWjUhhPUp8mIC0Te4DNDKrOQ7F2OsDmS7rW9msIST2HN8AS6d4yD079ULP4KZd 6tiFd4lzcGXV42c6OXSIoziVnhmwfN23RkRk6hLfs9Of4hmTspzejwufqq616oVDFPkf w4sg== X-Received: by 10.180.185.74 with SMTP id fa10mr16418924wic.26.1374433019146; Sun, 21 Jul 2013 11:56:59 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:6d64:736e:915f:b59a]) by mx.google.com with ESMTPSA id mb20sm48102946wic.1.2013.07.21.11.56.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 11:56:58 -0700 (PDT) Message-ID: <51EC2EF7.1090000@jitsi.org> Date: Sun, 21 Jul 2013 20:56:55 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnvz8YHof2jF6KS7xVhS6rQtP856VPF9zrNDgfmckgeVjJwsyYQvXtWaGskmtnN82NppI7D Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Sun, 21 Jul 2013 18:57:21 -0000 Hey Christer, On 21.07.13, 19:49, Christer Holmberg wrote: > Hi, > > As I've been on vacation, Hope you had a good one! > I tried to go through this thread in one > sweep. I may have missed/misunderstood some parts, and my apologies > if my comments below have already been dealt with. > > First, regarding 180, no matter if we use PRACK or not, SIP requires > the SDP to be identical in all 180 responses. That means you can't > add new candidates in subsequent 180 responses (eventhough vanilla > ICE uses 180s without PRACK, the SDP is identical in all 180s, > AFAIR). Good point! > Second, I get a little confused when we talk about the UAS sending > INFO before it knows that the dialog is established, and that we > would define some new handling rules when an error response is > received. Now, IF we want the UAC to inform the UAS that the dialog > has been established, we don't need PRACK for that. The UAC could > send an INFO when it receives the 180, and when the UAS receives the > INFO it knows the dialog has been established. I haven't thought so > much about it, so I am not suggesting such mechanism at this point, I > am only saying that it would be a possible solution from a SIP > protocol perspective :) This could indeed work! It would also make a lot of sense in cases where both agents are doing full trickle. Of course it does mean that, especially in half trickle scenarios, we basically have one full end-to-end signalling RTT (180 + INFO) during which trickling will be completely blocked. This could take a while. Still, if we don't come up with a better alternative, the worst case (i.e. half trickle + slow signalling) shouldn't be much worse than vanilla ICE. Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Sun Jul 21 14:41: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 664DB11E80A5 for ; Sun, 21 Jul 2013 14:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=0.178, 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 ioXPPthKSBfk for ; Sun, 21 Jul 2013 14:40:59 -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 650B621F9C82 for ; Sun, 21 Jul 2013 14:40:58 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id 39Tt1m0051uE5Es559gyd0; Sun, 21 Jul 2013 21:40:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 39gy1m0083ZTu2S3c9gyGh; Sun, 21 Jul 2013 21:40:58 +0000 Message-ID: <51EC5569.60106@alum.mit.edu> Date: Sun, 21 Jul 2013 17:40:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> In-Reply-To: <51EC2EF7.1090000@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=1374442858; bh=MwUsnOM3SGDvvytk3TYvNf9JXUtUX1ktb+KcPHK5sJ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DBnDQ3CSnJ6dp662Tmkv9HEOU7jV/DZpr+H51DrHtXIc+1zyJn+WfqsgeolZM54MN z0qo59fJ+F9JgjrYCr8theEOOX56t88xDaAQUo4UF0ltTBX7nxelKnOG5a7in5JKt4 5GsmoEbg4hn1srrQuNPbmJCVRVtNElRoQUYaK2yxqKuQHtYD++tvzgI73PKLIFPkMd ly703Bztvbiyy+O5g84mCxFW5pnzH7ie08ZWh5EhgvfU70tgW1DjrLF9flkKLCxExq kTQRdaxWmsTOw+J8hC8I+nc//g0l2YIbfumv3nK7PYf4GUHNadHFq8pL9qbrCY6DWh WEwjFEYpEw5+Q== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Sun, 21 Jul 2013 21:41:05 -0000 How is this better than PRACK? Thanks, Paul On 7/21/13 2:56 PM, Emil Ivov wrote: > Hey Christer, > > On 21.07.13, 19:49, Christer Holmberg wrote: >> Hi, >> >> As I've been on vacation, > > Hope you had a good one! > >> I tried to go through this thread in one >> sweep. I may have missed/misunderstood some parts, and my apologies >> if my comments below have already been dealt with. >> >> First, regarding 180, no matter if we use PRACK or not, SIP requires >> the SDP to be identical in all 180 responses. That means you can't >> add new candidates in subsequent 180 responses (eventhough vanilla >> ICE uses 180s without PRACK, the SDP is identical in all 180s, >> AFAIR). > > Good point! > >> Second, I get a little confused when we talk about the UAS sending >> INFO before it knows that the dialog is established, and that we >> would define some new handling rules when an error response is >> received. Now, IF we want the UAC to inform the UAS that the dialog >> has been established, we don't need PRACK for that. The UAC could >> send an INFO when it receives the 180, and when the UAS receives the >> INFO it knows the dialog has been established. I haven't thought so >> much about it, so I am not suggesting such mechanism at this point, I >> am only saying that it would be a possible solution from a SIP >> protocol perspective :) > > This could indeed work! It would also make a lot of sense in cases where > both agents are doing full trickle. > > Of course it does mean that, especially in half trickle scenarios, we > basically have one full end-to-end signalling RTT (180 + INFO) during > which trickling will be completely blocked. This could take a while. > > Still, if we don't come up with a better alternative, the worst case > (i.e. half trickle + slow signalling) shouldn't be much worse than > vanilla ICE. > > Emil > From emil@sip-communicator.org Sun Jul 21 15:06: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 2CF5C21F9C32 for ; Sun, 21 Jul 2013 15:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zrh6oEgmcOj for ; Sun, 21 Jul 2013 15:06:49 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8345F21F9C3A for ; Sun, 21 Jul 2013 15:06:49 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so5372041wgh.19 for ; Sun, 21 Jul 2013 15:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=/edmOHYDSmeE6AOmtRXjv/nAEb0yUbgBc32VqccVpTM=; b=p3XLiJE9yxaqQ0puLYHrcCIB3RmL9Kc8621wzIu/JBympoKbrwvwRZLlpXTOqwlnYZ wLXreoK67t+ETZcJSV8+T/mLjEnkHB/3YgDh/3ojDLPOiPLh707Z09HuWNcCC1OVi4M3 2sGg+EHaxzAPegYMmtydLtFhioXrvCtixo9DqXP0AIHH7FrQKCxQaWX9Z6nmQ3H5lgk8 43ZOBQ4VpwQsVpRg1MXJ/iCRuh0LMZZAz5jSRWy/AkccNe4jcbioFcmn5ubGi79v2dEQ gHe06H0HGI1pGpubH5rc1toQBU2QheHW4TQVFjM8g6x/JLjTJ4FTAtH/RUFOzsJPT1T3 IwOg== X-Received: by 10.180.185.175 with SMTP id fd15mr27897772wic.34.1374444408518; Sun, 21 Jul 2013 15:06:48 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id j20sm36836628wie.7.2013.07.21.15.06.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 15:06:47 -0700 (PDT) Message-ID: <51EC5B75.1020306@jitsi.org> Date: Mon, 22 Jul 2013 00:06:45 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> In-Reply-To: <51EC5569.60106@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmWfQe+TK6A0EbJImYVMu7bhjfSr6sYpKacgxjK7n5ujiJNiH2GRXJyZoxn8TTFHWZl8cO/ Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Sun, 21 Jul 2013 22:06:59 -0000 On 21.07.13, 23:40, Paul Kyzivat wrote: > How is this better than PRACK? Well, you don't have to worry about supporting offers and answers in the PRACK (which could indeed be a pain). Emil > > Thanks, > Paul > > On 7/21/13 2:56 PM, Emil Ivov wrote: >> Hey Christer, >> >> On 21.07.13, 19:49, Christer Holmberg wrote: >>> Hi, >>> >>> As I've been on vacation, >> >> Hope you had a good one! >> >>> I tried to go through this thread in one >>> sweep. I may have missed/misunderstood some parts, and my apologies >>> if my comments below have already been dealt with. >>> >>> First, regarding 180, no matter if we use PRACK or not, SIP requires >>> the SDP to be identical in all 180 responses. That means you can't >>> add new candidates in subsequent 180 responses (eventhough vanilla >>> ICE uses 180s without PRACK, the SDP is identical in all 180s, >>> AFAIR). >> >> Good point! >> >>> Second, I get a little confused when we talk about the UAS sending >>> INFO before it knows that the dialog is established, and that we >>> would define some new handling rules when an error response is >>> received. Now, IF we want the UAC to inform the UAS that the dialog >>> has been established, we don't need PRACK for that. The UAC could >>> send an INFO when it receives the 180, and when the UAS receives the >>> INFO it knows the dialog has been established. I haven't thought so >>> much about it, so I am not suggesting such mechanism at this point, I >>> am only saying that it would be a possible solution from a SIP >>> protocol perspective :) >> >> This could indeed work! It would also make a lot of sense in cases where >> both agents are doing full trickle. >> >> Of course it does mean that, especially in half trickle scenarios, we >> basically have one full end-to-end signalling RTT (180 + INFO) during >> which trickling will be completely blocked. This could take a while. >> >> Still, if we don't come up with a better alternative, the worst case >> (i.e. half trickle + slow signalling) shouldn't be much worse than >> vanilla ICE. >> >> Emil >> > > -- https://jitsi.org From ranjit.avasarala@nsn.com Sun Jul 21 21:46:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84D821F9D8D for ; Sun, 21 Jul 2013 21:46: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_63=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 0glG12JNM6iI for ; Sun, 21 Jul 2013 21:46:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C021F8AD5 for ; Sun, 21 Jul 2013 21:46:26 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6M4kNJe032263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Jul 2013 06:46:23 +0200 Received: from SGSIHTC003.nsn-intra.net ([10.159.225.20]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6M4jFa5031306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 06:46:22 +0200 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC003.nsn-intra.net ([10.159.225.20]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 12:45:23 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" , "aurelien.sollaud@orange.com" , "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Thread-Index: AQHOgRb1T5KmjKB2G0moEz4zq2KWR5llMGQAgABEw6CAAFHowIAKYwig Date: Mon, 22 Jul 2013 04:45:24 +0000 Message-ID: References: <20130715044252.29200.10961.idtracker@ietfa.amsl.com> <25194_1373879901_51E3BE5D_25194_316_3_719DF432C01EA6418EBA5185063A16610D5F80@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6180 X-purgate-ID: 151667::1374468383-000017BA-1AC5943D/0-0/0-0 Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 04:46:31 -0000 Hi I agree of not making these parameters mandatory.=20 Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Monday, July 15, 2013 7:59 PM To: aurelien.sollaud@orange.com; Avasarala, Ranjit (NSN - IN/Bangalore); mm= usic@ietf.org Subject: RE: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt Agree with Aurelien. In addition, the draft explicitly specifies the behavi= or for the default case: When the offer or answer has G723 and the annexa parameter is absent, the offerer or answerer knows that it has implied the default "annexa=3Dyes". This is because the annexa attribute is part of the original registration of audio/G723 [RFC4856]. All implementations that support G723 understand the annexa attribute. Hence, this case MUST be considered as if the offer or answer has G723 with annexa=3Dyes. This I think should suffice to make sure implementations don't ignore it. S= o, making these optional parameters mandatory optional isn't needed (and pr= obably isn't right). Muthu |-----Original Message----- |From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] |Sent: Monday, July 15, 2013 2:48 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore); Muthu Arul Mozhi Perumal (mper= umal); mmusic@ietf.org |Subject: RE: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |Hi | |A lot of media subtypes have optional parameters, and as long as a default= value is defined, there is |no issue. |The problem here is not that annexa/annexb parameters are optional, but th= at the offer/answer |procedure was not defined for these media subtypes. | |-----Message d'origine----- |De=A0: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part= de Avasarala, Ranjit (NSN - |IN/Bangalore) |Envoy=E9=A0: lundi 15 juillet 2013 09:08 |=C0=A0: ext Muthu Arul Mozhi Perumal (mperumal); mmusic@ietf.org |Objet=A0: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |Hi Muthu | |I have following comments |1. RFC 4856 defines "annexa" and "annexb" as optional parameters. So I agr= ee there could be |misinpterpretations. |2. The proposed draft should make these parameters as mandatory, otherwise= the implementations would |continue to ignore the parameters. |3. Update RFC 4856 moving "annexa" and "annexb" parameters from "optional"= to "required". | |Regards |Ranjit | | | |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f ext Muthu Arul Mozhi |Perumal (mperumal) |Sent: Monday, July 15, 2013 10:21 AM |To: mmusic@ietf.org |Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |This updated version addresses all comments received during WGLC. | |- Muthu, Partha | |-----Original Message----- |From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= On Behalf Of internet- |drafts@ietf.org |Sent: Monday, July 15, 2013 10:13 AM |To: i-d-announce@ietf.org |Cc: mmusic@ietf.org |Subject: I-D Action: draft-ietf-mmusic-sdp-g723-g729-04.txt | |A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. | This draft is a work item of the Multiparty Multimedia Session Control Wo= rking Group of the IETF. | | Title : Offer/Answer Considerations for G723 Annex A and G729 A= nnex B | Author(s) : Muthu Arul Mozhi Perumal | Parthasarathi Ravindran | Filename : draft-ietf-mmusic-sdp-g723-g729-04.txt | Pages : 8 | Date : 2013-07-14 | |Abstract: | RFC4856 describes the annexa parameter for G723 and the annexb | parameter for G729, G729D and G729E. However, the specification does | not describe the offerer and answerer behavior when the value of the | annexa or annexb parameter does not match in the Session Description | protocol(SDP) offer and answer. This document provides the offer/ | answer considerations for these parameters and updates RFC4856. | |The IETF datatracker status page for this draft is: |https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729 | |There's also a htmlized version available at: |http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-04 | |A diff from the previous version is available at: |http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-04 | |Internet-Drafts are also available by anonymous FTP at: |ftp://ftp.ietf.org/internet-drafts/ | |_______________________________________________ |I-D-Announce mailing list |I-D-Announce@ietf.org |https://www.ietf.org/mailman/listinfo/i-d-announce |Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.i= etf.org/ietf/1shadow- |sites.txt |_______________________________________________ |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 | |__________________________________________________________________________= ____________________________ |___________________ | |Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et |ne doivent donc |pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, |veuillez le signaler |a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant |susceptibles d'alteration, |Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. | |This message and its attachments may contain confidential or privileged in= formation that may be |protected by law; |they should not be distributed, used or copied without authorisation. |If you have received this email in error, please notify the sender and del= ete this message and its |attachments. |As emails may be altered, Orange is not liable for messages that have been= modified, changed or |falsified. |Thank you. From christer.holmberg@ericsson.com Sun Jul 21 23:24: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 C695321E8089 for ; Sun, 21 Jul 2013 23:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=0.612, 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 BJBdIOCWS6ME for ; Sun, 21 Jul 2013 23:24:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EE88121E8050 for ; Sun, 21 Jul 2013 23:24:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-f3-51ecd00f681e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C2.84.05990.F00DCE15; Mon, 22 Jul 2013 08:24:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 08:24:14 +0200 From: Christer Holmberg To: Paul Kyzivat , Emil Ivov Thread-Topic: VS: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlUX4cAgAGiawCABGabgIAAbIEAgAHtwYCAABaEAIASqbgA///zoYCAAC3VgIAAstXA Date: Mon, 22 Jul 2013 06:24:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3F3644@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> In-Reply-To: <51EC5569.60106@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrS7/hTeBBntPCVms2TmBxWLq8scs Fis2HGC12LW9xoHF4+/7D0weS5b8ZPL4/ybQ48bt98wBLFFcNimpOZllqUX6dglcGdtvnWEr uMtfMeN+P2MD41qeLkZODgkBE4lHJ48xQthiEhfurWfrYuTiEBI4zChxo2UNC4SzhFFixfnl QFUcHGwCFhLd/7RBTBEBV4l5zxRBTGaBBImuf+YgY4QFzCXuvzvLBGKLABXPOt3CCFGdJ9F3 SBIkzCKgKnF2bz9YCa+Ar0THyn3MEItuMEucm7yYGSTBKaAl0XVpLxuIzQh02vdTa8AamAXE JT4cvM4McbKAxJI956FsUYmXj/+xQthKEo1LnrBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+w TGAUm4Vk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernRJkZgDB3c8lt1B+OdcyKHGKU5WJTEeTfr nQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLh+Vvy+2HYrtoaD+49JBVZd5s13eXWW083g 57PatfU3WdTubdQrOCrOHL4t0K5u5inOmCLZxNQZ3+SMju15t2WfpL/2iiMMqfcv3FW6pCQ8 fev7Sm3X901briZWLGz6z87PMO8xi7bE8+c6Ui7vmeqKwkPMdglbrHxdt93KO8jhyerc35rr vZVYijMSDbWYi4oTASkYrfxvAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 06:24:28 -0000 Hi, >How is this better than PRACK? I didn't say it's better :) Regards, Christer On 7/21/13 2:56 PM, Emil Ivov wrote: > Hey Christer, > > On 21.07.13, 19:49, Christer Holmberg wrote: >> Hi, >> >> As I've been on vacation, > > Hope you had a good one! > >> I tried to go through this thread in one sweep. I may have=20 >> missed/misunderstood some parts, and my apologies if my comments=20 >> below have already been dealt with. >> >> First, regarding 180, no matter if we use PRACK or not, SIP requires=20 >> the SDP to be identical in all 180 responses. That means you can't=20 >> add new candidates in subsequent 180 responses (eventhough vanilla=20 >> ICE uses 180s without PRACK, the SDP is identical in all 180s,=20 >> AFAIR). > > Good point! > >> Second, I get a little confused when we talk about the UAS sending=20 >> INFO before it knows that the dialog is established, and that we=20 >> would define some new handling rules when an error response is=20 >> received. Now, IF we want the UAC to inform the UAS that the dialog=20 >> has been established, we don't need PRACK for that. The UAC could=20 >> send an INFO when it receives the 180, and when the UAS receives the=20 >> INFO it knows the dialog has been established. I haven't thought so=20 >> much about it, so I am not suggesting such mechanism at this point, I=20 >> am only saying that it would be a possible solution from a SIP=20 >> protocol perspective :) > > This could indeed work! It would also make a lot of sense in cases=20 > where both agents are doing full trickle. > > Of course it does mean that, especially in half trickle scenarios, we=20 > basically have one full end-to-end signalling RTT (180 + INFO) during=20 > which trickling will be completely blocked. This could take a while. > > Still, if we don't come up with a better alternative, the worst case=20 > (i.e. half trickle + slow signalling) shouldn't be much worse than=20 > vanilla ICE. > > Emil > From christer.holmberg@ericsson.com Sun Jul 21 23:33: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 E98D621E8050 for ; Sun, 21 Jul 2013 23:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.591, 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 pBf0nqXtjY6g for ; Sun, 21 Jul 2013 23:33:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0272621F99E3 for ; Sun, 21 Jul 2013 23:33:20 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-e3-51ecd22f33b6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 58.CE.19388.F22DCE15; Mon, 22 Jul 2013 08:33:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 08:33:19 +0200 From: Christer Holmberg To: Emil Ivov , Paul Kyzivat Thread-Topic: VS: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlUX4cAgAGiawCABGabgIAAbIEAgAHtwYCAABaEAIASqbgA///zoYCAAC3VgIAABzWAgACsjQA= Date: Mon, 22 Jul 2013 06:33:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> In-Reply-To: <51EC5B75.1020306@jitsi.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvra7+pTeBBsce61ms2TmBxWLq8scs Fis2HGC12LW9xoHF4+/7D0weS5b8ZPL4/ybQ48bt98wBLFFcNimpOZllqUX6dglcGZ1nWlgK JohXTF16hqmBcZlQFyMnh4SAicSK/w8ZIWwxiQv31rN1MXJxCAkcZpT4M+kIlLOEUeL7m5Ms XYwcHGwCFhLd/7RBGkQEXCUe33jFBhJmFkiQ6PpnDhIWFjCXuP/uLBNEiYXErNMtjBB2mcSU eb9YQGwWAVWJHd3r2UFsXgFfiRMrv0Ot+s4scX3hfrAEp4CmxPSH/8GaGYGO+35qDdhQZgFx iQ8HrzNDHC0gsWTPeShbVOLl43+sELaSROOSJ6wQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcs ExjFZiEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm6+iREYRwe3/DbYwbjpvtghRmkOFiVx3s16 ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME6za9XT5/t/zP5g8tWtenITuBb2bdwUaO5y Ou36Z4GurXWsX0VrLO1OHvTd9sbPzuam/g4LB17xrx0bbcWToo9sr8mx9xDfLr+6a4JVd0iW 2kPvGq0/l2x22D2ez2U0+cbdmletL/nP1geW7RSd+cZdQDIgNrdwz0GL1RofVr2sXbzcKijq rhJLcUaioRZzUXEiACrIME9xAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 06:33:27 -0000 Hi, >> How is this better than PRACK? > > Well, you don't have to worry about supporting offers and answers in the = PRACK (which could indeed be a pain). In my years of "PRACK experience", PRACK itself (for the purpose of acknowl= edging reliable 18x responses) has never been a problem. But, I agree there= could be issues when it is used for O/A - especially if one wants to rejec= t an offer. In my experience, however, offers in PRACK are normally used e.= g. to change pre-condition state, and/or to remove codecs, so the likelihoo= d of rejection based on the SDP content should be rather small. There are also implementations that don't accept offers in PRACK to begin w= ith, but I think that goes under "bad implementation" :) Having said that, not specific to trickle ICE, if O/A is a show stopper for= the community to use PRACK, maybe that is something we need to look into o= n a more general level. Regards, Christer > On 7/21/13 2:56 PM, Emil Ivov wrote: >> Hey Christer, >> >> On 21.07.13, 19:49, Christer Holmberg wrote: >>> Hi, >>> >>> As I've been on vacation, >> >> Hope you had a good one! >> >>> I tried to go through this thread in one sweep. I may have=20 >>> missed/misunderstood some parts, and my apologies if my comments=20 >>> below have already been dealt with. >>> >>> First, regarding 180, no matter if we use PRACK or not, SIP requires=20 >>> the SDP to be identical in all 180 responses. That means you can't=20 >>> add new candidates in subsequent 180 responses (eventhough vanilla=20 >>> ICE uses 180s without PRACK, the SDP is identical in all 180s,=20 >>> AFAIR). >> >> Good point! >> >>> Second, I get a little confused when we talk about the UAS sending=20 >>> INFO before it knows that the dialog is established, and that we=20 >>> would define some new handling rules when an error response is=20 >>> received. Now, IF we want the UAC to inform the UAS that the dialog=20 >>> has been established, we don't need PRACK for that. The UAC could=20 >>> send an INFO when it receives the 180, and when the UAS receives the=20 >>> INFO it knows the dialog has been established. I haven't thought so=20 >>> much about it, so I am not suggesting such mechanism at this point,=20 >>> I am only saying that it would be a possible solution from a SIP=20 >>> protocol perspective :) >> >> This could indeed work! It would also make a lot of sense in cases=20 >> where both agents are doing full trickle. >> >> Of course it does mean that, especially in half trickle scenarios, we=20 >> basically have one full end-to-end signalling RTT (180 + INFO) during=20 >> which trickling will be completely blocked. This could take a while. >> >> Still, if we don't come up with a better alternative, the worst case=20 >> (i.e. half trickle + slow signalling) shouldn't be much worse than=20 >> vanilla ICE. >> >> Emil >> > > -- https://jitsi.org From emil@sip-communicator.org Mon Jul 22 03:44: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 3693D11E8150 for ; Mon, 22 Jul 2013 03:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 UqCp+Xn8ApbV for ; Mon, 22 Jul 2013 03:44:33 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 080DC21E80F7 for ; Mon, 22 Jul 2013 03:40:41 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so5852276wgg.20 for ; Mon, 22 Jul 2013 03:40:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=hIzTM5iDFcOdZdnY3l8vSnVrKmLoZ+7b1WT34NC1Rfc=; b=LmpQhg5B3mX3b9BqljcR+dXMm+ZeL+JDWN877e8d6KX5kVHphfo0jHEd/I78RunNEa z4TXcPFB379cxQe/q3LaRRhh9Lwe6DF9zyvl5BxFoX9ii0/JMO45RVnmRbzcSfm9sPbb ByrsnKyEEPS6vQd8xT9aWrz3mODBEx9Tq/eQop7esGYywGlIPQ3ATWYo8FCby6/zAqAI xGY0UMzspJ2OzADfZOWdZ3dax6UuZa6tBWJoq57RXbnIFrpXiT6UYmEdfSkRTM8zwGIZ PaHTm/X/i6ZTAwjcSWACbRwW0pdPI8PDlO+ZjsuC1q529DevAduSMkx1Ijj5lVw0i3py E0bg== X-Received: by 10.194.77.99 with SMTP id r3mr19124360wjw.5.1374489639774; Mon, 22 Jul 2013 03:40:39 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:515d:41fb:33a9:57de]) by mx.google.com with ESMTPSA id u9sm39700114wif.6.2013.07.22.03.40.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 03:40:38 -0700 (PDT) Message-ID: <51ED0C24.30206@jitsi.org> Date: Mon, 22 Jul 2013 12:40:36 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlkea8l8FXqP7sjn/3Pl0l3t7UwnVND7l9olIJTXOlrkvTrcwbb1d/NGA6QL+OZE85rsFkm Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 10:44:47 -0000 On 22.07.13, 08:33, Christer Holmberg wrote: > Hi, > >>> How is this better than PRACK? >> >> Well, you don't have to worry about supporting offers and answers in the PRACK (which could indeed be a pain). > > In my years of "PRACK experience", PRACK itself (for the purpose of acknowledging reliable 18x responses) has never been a problem. But, I agree there could be issues when it is used for O/A - especially if one wants to reject an offer. In my experience, however, offers in PRACK are normally used e.g. to change pre-condition state, and/or to remove codecs, so the likelihood of rejection based on the SDP content should be rather small. > > There are also implementations that don't accept offers in PRACK to begin with, but I think that goes under "bad implementation" :) > > Having said that, not specific to trickle ICE, if O/A is a show stopper for the community to use PRACK, Well, speaking as an implementor, I can completely see how many would feel uneasy about adding this to working implementations. It basically means adding some additional complexity with no actual benefit in return. > maybe that is something we need to look into on a more general level. You mean something like PRACK-lite that doesn't have offer answer? This sounds like something that could be relatively straightforward to specify. It would basically have to mimic PRACK but remove the part that talks about the additional O/A possibilities. Trickle ICE for SIP could then have a dependency on it ... Emil > > Regards, > > Christer > > > > >> On 7/21/13 2:56 PM, Emil Ivov wrote: >>> Hey Christer, >>> >>> On 21.07.13, 19:49, Christer Holmberg wrote: >>>> Hi, >>>> >>>> As I've been on vacation, >>> >>> Hope you had a good one! >>> >>>> I tried to go through this thread in one sweep. I may have >>>> missed/misunderstood some parts, and my apologies if my comments >>>> below have already been dealt with. >>>> >>>> First, regarding 180, no matter if we use PRACK or not, SIP requires >>>> the SDP to be identical in all 180 responses. That means you can't >>>> add new candidates in subsequent 180 responses (eventhough vanilla >>>> ICE uses 180s without PRACK, the SDP is identical in all 180s, >>>> AFAIR). >>> >>> Good point! >>> >>>> Second, I get a little confused when we talk about the UAS sending >>>> INFO before it knows that the dialog is established, and that we >>>> would define some new handling rules when an error response is >>>> received. Now, IF we want the UAC to inform the UAS that the dialog >>>> has been established, we don't need PRACK for that. The UAC could >>>> send an INFO when it receives the 180, and when the UAS receives the >>>> INFO it knows the dialog has been established. I haven't thought so >>>> much about it, so I am not suggesting such mechanism at this point, >>>> I am only saying that it would be a possible solution from a SIP >>>> protocol perspective :) >>> >>> This could indeed work! It would also make a lot of sense in cases >>> where both agents are doing full trickle. >>> >>> Of course it does mean that, especially in half trickle scenarios, we >>> basically have one full end-to-end signalling RTT (180 + INFO) during >>> which trickling will be completely blocked. This could take a while. >>> >>> Still, if we don't come up with a better alternative, the worst case >>> (i.e. half trickle + slow signalling) shouldn't be much worse than >>> vanilla ICE. >>> >>> Emil >>> >> >> > > -- > https://jitsi.org > -- https://jitsi.org From christer.holmberg@ericsson.com Mon Jul 22 04:11: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 9552621E8050 for ; Mon, 22 Jul 2013 04:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[AWL=-1.253, 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 4qoKGLSMXyis for ; Mon, 22 Jul 2013 04:11:47 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 816DA21F9E68 for ; Mon, 22 Jul 2013 04:11:45 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-5d-51ed136f4954 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.60.11907.F631DE15; Mon, 22 Jul 2013 13:11:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 13:11:43 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: VS: VS: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOhqVolPUjUqKG9kS+q3KtYrX/UZlwYPoAgAApXIA= Date: Mon, 22 Jul 2013 11:11:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> In-Reply-To: <51ED0C24.30206@jitsi.org> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW6+8NtAg50HlC3W7JzAYjF1+WMW ixUbDrBa7Npe48Di8ff9ByaPJUt+Mnn8fxPoceP2e+YAligum5TUnMyy1CJ9uwSujNnzXjMV LOetONcY38B4kauLkZNDQsBE4uvenUwQtpjEhXvr2boYuTiEBI4ySnzovcYE4SxhlPi0twXI 4eBgE7CQ6P6nDdIgIiAv0d22CKyZWaCNUWLhQw8QW1jAWuL5whcsEDU2Em/7jzBD2FYSCw/t AIuzCKhKtP05BBbnFfCVOHLyI9SuGywSU17MASviFFCX2PutnxHEZgS67vupNVDLxCU+HLzO DHG1gMSSPeehbFGJl4//sULYShKNS56wQtTrSCzY/YkNwtaWWLbwNdRiQYmTM5+wTGAUm4Vk 7CwkLbOQtMxC0rKAkWUVI0dxanFSbrqRwSZGYCQd3PLbYgfj5b82hxilOViUxHm36J0JFBJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cC4cwfbbSPmvZ787fFafc2pbCv7gmU/bJydcsq32mLy iQfWJXNN+s8/XbXk4eINUiJOF11VXl582BTHfjCs1y4oUWrRUy/5p9W7HhwO5wiUXmAZsGq/ 9Dt+m0ttLdwGqq8EBfPu3J440fuPfybftQPJmwuun1vcHfVivsYLnbbNMaZ8yiuEYnqVWIoz Eg21mIuKEwEwTVxncgIAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 11:11:56 -0000 Hi, >>>> How is this better than PRACK? >>> >>> Well, you don't have to worry about supporting offers and answers in th= e PRACK (which could indeed be a pain). >> >> In my years of "PRACK experience", PRACK itself (for the purpose of ackn= owledging reliable 18x responses) has never been a=20 >> problem. But, I agree there could be issues when it is used for O/A - es= pecially if one wants to reject an offer. In my experience, however,=20 >> offers in PRACK are normally used e.g. to change pre-condition state, an= d/or to remove codecs, so the likelihood of rejection based on the SDP cont= ent should be rather small. >> >> There are also implementations that don't accept offers in PRACK to=20 >> begin with, but I think that goes under "bad implementation" :) >> >> Having said that, not specific to trickle ICE, if O/A is a show=20 >> stopper for the community to use PRACK, > > Well, speaking as an implementor, I can completely see how many would fee= l uneasy about adding this to working implementations. It basically means a= dding some additional complexity with no actual benefit in return. > >> maybe that is something we need to look into on a more general level. > > You mean something like PRACK-lite that doesn't have offer answer? This s= ounds like something that could be relatively straightforward to specify. I= t would basically=20 > have to mimic PRACK but remove the part that talks about the additional O= /A possibilities. It could perhaps even be a request without a response, similar to ACK, whic= h would make it even more "lite". When the UAS receives it, it simply cease= s the transmission of the 18x. Regards, Christer From adam@nostrum.com Mon Jul 22 11:39: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 E7F3311E80D9 for ; Mon, 22 Jul 2013 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 TaYoqQCGpJnD for ; Mon, 22 Jul 2013 11:39:26 -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 28E9C21F8546 for ; Mon, 22 Jul 2013 11:39:26 -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 r6MIdKaL054951 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 13:39:21 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51ED7C53.2050400@nostrum.com> Date: Mon, 22 Jul 2013 13:39:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3D918D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3D918D@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------090908070404090609080904" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 18:39:29 -0000 This is a multi-part message in MIME format. --------------090908070404090609080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/20/13 04:51, Christer Holmberg wrote: > I do realize that the draft does not represent the complete glare > solution. Right, and I think it would be premature to dig into those details for their own sake at the moment. So, before we go into a discussion of what I believe are minutiea, we need to establish whether you're asking because it seems like an interesting problem to work on, or if you think that the approach has intractable flaws that would prevent developing it to completion. (To be clear, even though it's not phrased as a question, I would expect you to indicate which of those is the case, Christer). In the former case, I'd like to defer the discussion around what I believe are addressable open issues in the high-level sketch, and instead focus on whether the overall "partial o/a" approach satisfies the needs of those parties for whom glare reduction is an important goal. > *Q1*: How essential part of the unified plan is having **A** working > "partial o/a" solution? TECHNICALLY, the other parts of the unified > plan do not depend on having a "partial o/a" solution, but I would > like to know whether people (specially the draft authors) would be > willing to move ahead with unified plan even if we would not manage to > specify a working "partial o/a" solution. > Let's back up -- you're conflating mechanism with requirement here. The requirement is no glare in certain use cases (adding/removing streams). The proposed mechanism is partial o/a. The requirement is important to certain key participants in the working group, so I would characterize having a mechanism to address it as essential. Keeping that in mind, "having a working 'partial o/a' solution," to re-use your phrasing, is utterly nonessential, since it is only one way to skin this cat. However, like I just said, having a working story for glare *is* essential. We've seen others (as I explained to my response to Paul, earlier), and may be able to come up with yet more. > *Q2a*: When sending a partial offer, the draft says that only the m= > line explicitly signaled is affected. Note, however, that you will > still signal information (e.g. the SDP version value, the group:BUNDLE > attribute etc) which affect the whole SDP, and if you have multiple > outstanding partial offers (for different m= lines) that can cause issues. > > *Q2b*: In addition, when using BUNDLE, modifying an m= line might > implicitly modify other m= lines, and there are rules (also indicated > in the draft) mandating identical SDP attribute values etc. So, if you > have multiple outstanding partial offers, you may end up with all kind > of different "BUNDLE collisions". > > *Q3*: If I send a partial offer, for a given m= line, can the answer > only contain that given m= line? What if the partial offer causes > other m= lines to be modified? > These three points are, as far as I can discern, the natural engineers' curiosity that leads us to want to start working on fleshing out a solution as soon as we understand its skeleton. I don't think it's time for that. I have answers for these questions, but I'm 100% certain that providing them would start a highly distracting, if interesting, conversation that would delay our nailing down the other aspects of the unified plan. /a --------------090908070404090609080904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/20/13 04:51, Christer Holmberg wrote:
I do realize that the draft does not represent the complete glare solution.

Right, and I think it would be premature to dig into those details for their own sake at the moment.  So, before we go into a discussion of what I believe are minutiea, we need to establish whether you're asking because it seems like an interesting problem to work on, or if you think that the approach has intractable flaws that would prevent developing it to completion. (To be clear, even though it's not phrased as a question, I would expect you to indicate which of those is the case, Christer).

In the former case, I'd like to defer the discussion around what I believe are addressable open issues in the high-level sketch, and instead focus on whether the overall "partial o/a" approach satisfies the needs of those parties for whom glare reduction is an important goal.

 Q1: How essential part of the unified plan is having *A* working “partial o/a” solution? TECHNICALLY, the other parts of the unified plan do not depend on having a “partial o/a” solution, but I would like to know whether people (specially the draft authors) would be willing to move ahead with unified plan even if we would not manage to specify a working “partial o/a” solution.


Let's back up -- you're conflating mechanism with requirement here. The requirement is no glare in certain use cases (adding/removing streams). The proposed mechanism is partial o/a. The requirement is important to certain key participants in the working group, so I would characterize having a mechanism to address it as essential.

Keeping that in mind, "having a working 'partial o/a' solution," to re-use your phrasing, is utterly nonessential, since it is only one way to skin this cat. However, like I just said, having a working story for glare *is* essential. We've seen others (as I explained to my response to Paul, earlier), and may be able to come up with yet more.

Q2a: When sending a partial offer, the draft says that only the m= line explicitly signaled is affected. Note, however, that you will still signal information (e.g. the SDP version value, the group:BUNDLE attribute etc) which affect the whole SDP, and if you have multiple outstanding partial offers (for different m= lines) that can cause issues.

 

Q2b: In addition, when using BUNDLE, modifying an m= line might implicitly modify other m= lines, and there are rules (also indicated in the draft) mandating identical SDP attribute values etc. So, if you have multiple outstanding partial offers, you may end up with all kind of different “BUNDLE collisions”.

 

Q3: If I send a partial offer, for a given m= line, can the answer only contain that given m= line? What if the partial offer causes other m= lines to be modified?


These three points are, as far as I can discern, the natural engineers' curiosity that leads us to want to start working on fleshing out a solution as soon as we understand its skeleton. I don't think it's time for that. I have answers for these questions, but I'm 100% certain that providing them would start a highly distracting, if interesting, conversation that would delay our nailing down the other aspects of the unified plan.

/a
--------------090908070404090609080904-- From adam@nostrum.com Mon Jul 22 15:08: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 D951D11E8182 for ; Mon, 22 Jul 2013 15:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, 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 x0XB4SCowy+A for ; Mon, 22 Jul 2013 15:08:34 -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 528A911E817C for ; Mon, 22 Jul 2013 15:08:34 -0700 (PDT) Received: from orochi-2.roach.at (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 r6MM8T0Q077945 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 17:08:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EDAD58.1050407@nostrum.com> Date: Mon, 22 Jul 2013 17:08:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roni Even References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com> <00f401ce82a5$96dfff00$c49ffd00$@gmail.com> In-Reply-To: <00f401ce82a5$96dfff00$c49ffd00$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 22:08:35 -0000 On 7/16/13 23:24, Roni Even wrote: > Hi, >>> 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an >>> integer) used for correlation;" I think that it must be a byte string >>> or token not integer >> Do you have some rationale for your assertion? >> >> > [Roni Even] This is the syntax of the header extension and > extensionattributes in RFC5285. It is a byte string and not an integer > > Forgive the imprecision in the draft. What we mean to say is something along the lines of "a 16-bit identifier, expressed as an integer in the SDP, encoded in the RTP header as a two-byte byte string, in network byte order." I apologize for the confusion. I thought this much would be obvious without needing to spell it out explicitly. /a From christer.holmberg@ericsson.com Mon Jul 22 21:53: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 C401211E81F6 for ; Mon, 22 Jul 2013 21:53:00 -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 TOarMegA-vJp for ; Mon, 22 Jul 2013 21:52:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B9DCE11E81E9 for ; Mon, 22 Jul 2013 21:52:47 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-81-51ee0c1df35b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CB.EA.19388.D1C0EE15; Tue, 23 Jul 2013 06:52:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 06:52:45 +0200 From: Christer Holmberg To: Adam Roach Thread-Topic: VS: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare Thread-Index: Ac6FLNZDJiUB1pFYSza6h1JrrPeg6wBzSpSAABiPnUA= Date: Tue, 23 Jul 2013 04:52:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3FCA2B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3D918D@ESESSMB209.ericsson.se> <51ED7C53.2050400@nostrum.com> In-Reply-To: <51ED7C53.2050400@nostrum.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra4cz7tAg5d/GS32/F3EbjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyjjyZBlrwSyJikMfTzA1 ME4X7mLk5JAQMJF4unETI4QtJnHh3nq2LkYuDiGBw4wSG+c0MkI4Sxgl2t5tYO5i5OBgE7CQ 6P6nDdIgIqAo0Xb4JjOIzSzgK/FywRcwW1jAQ+LF4z0sEDWeEvu39DJD2FYSj993gtksAqoS z67/ZgEZyQvUe+GxGEhYSCBP4n/fTLBWTgFtiT3Tr4HZjEC3fT+1hglilbjEh4PXmSFuFpBY suc8lC0q8fLxP1YIW0nix4ZLLBD1ehI3pk5hg7C1JZYtfA1WzysgKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiZM9NzMxJLzffxAiMmoNbfhvsYNx0X+wQozQHi5I472a9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGBuEmVtbIpJ5y2c3vE2ZGLx13enqX29dc81j1hRPnWMcq9+x u3DeqWO68TL7plw+nTd7y7M93mvCPl9m5tIT0yrWt3188NNbtv8Vtruqyqrmn/x0b1PrdaV4 6+sH3i659u3BxPM5t7pczB3ZTzW3np1bft02SmFeZ1d+tRn33x0ebEV/BZVPBiuxFGckGmox FxUnAgBhw36xaAIAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 04:53:01 -0000 Hi, >> I do realize that the draft does not represent the complete glare soluti= on.=20 > > Right, and I think it would be premature to dig into those details for th= eir own sake at the moment.=A0 So, before we go into a discussion of what I= believe are minutiea, we=20 > need to establish whether you're asking because it seems like an interest= ing problem to work on, or if you think that the approach has intractable f= laws that would prevent=20 > developing it to completion. (To be clear, even though it's not phrased a= s a question, I would expect you to indicate which of those is the case, Ch= rister). I have always thought that one of the downsides with SDP O/A is the fact th= at you always need to include the information for all streams when you send= an Offer or Answer. Now, when you have 1 or 2 streams that is not a big is= sue. But, in the rtcweb context people have been talking about a much bigge= r number of streams, so it may become an issue. So, I definitely think it seems like an interesting problem to work on. I do think that there are issues with 'partial O/A'. But, as we both have s= aid, this is not the moment to go into detailed discussions about the mecha= nism :) > In the former case, I'd like to defer the discussion around what I believ= e are addressable open issues in the high-level sketch, and instead focus o= n=20 > whether the overall "partial o/a" approach satisfies the needs of those p= arties for whom glare reduction is an important goal. > >> Q1: How essential part of the unified plan is having *A* working "partia= l o/a" solution? TECHNICALLY, the other parts of the unified plan do not de= pend=20 >> on having a "partial o/a" solution, but I would like to know whether peo= ple (specially the draft authors) would be willing to move ahead with unifi= ed plan >> even if we would not manage to specify a working "partial o/a" solution. > > Let's back up -- you're conflating mechanism with requirement here. The r= equirement is no glare in certain use cases (adding/removing streams). The draft also talks about modifying streams (section 3.4.2). Are there spe= cific modification use cases where no glare is important, or is it about be= ing able to modify streams in general and avoid glare? > The proposed mechanism is partial o/a. Correct. > The requirement is important to certain key participants in the working g= roup, so I would characterize having a mechanism to address it as essential= . Ok. > Keeping that in mind, "having a working 'partial o/a' solution," to re-us= e your phrasing, is utterly nonessential, since it is only one way to skin = this cat. However, like > I just said, having a working story for glare *is* essential. We've seen = others (as I explained to my response to Paul, earlier), and may be able to= come up with yet more. So, moving ahead with unified plan basically means adopting the requirement= to solve glare, but we may also look at other mechanisms? Thanks for the clarification! Regards, Christer From adam@nostrum.com Mon Jul 22 22:21: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 A181111E8117 for ; Mon, 22 Jul 2013 22:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 IsNblW1swFe0 for ; Mon, 22 Jul 2013 22:21:18 -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 220B111E8140 for ; Mon, 22 Jul 2013 22:21:17 -0700 (PDT) Received: from orochi-2.roach.at (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 r6N5LAeV026489 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 00:21:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EE12C0.5080803@nostrum.com> Date: Tue, 23 Jul 2013 00:21:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C3D918D@ESESSMB209.ericsson.se> <51ED7C53.2050400@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C3FCA2B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3FCA2B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling - Glare X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:21:18 -0000 On 7/22/13 23:52, Christer Holmberg wrote: > The draft also talks about modifying streams (section 3.4.2). Are there specific modification use cases where no glare is important, or is it about being able to modify streams in general and avoid glare? I was a matter of realizing that our design allows, with very little additional effort, significant reduction in the probability of glare for stream modification in general. As this seemed like very low hanging fruit, it seems to be sensible to include it as part of the design. So, to answer you question directly: it's not driven by specific use cases; it's just general glare probability reduction. > So, moving ahead with unified plan basically means adopting the > requirement to solve glare, but we may also look at other mechanisms? It is my understanding that making glare impossible or nearly impossible for the add/remove stream case is an important requirement for any plan (a, b, unified, or anything else). At the moment, the proposal in the unified plan document is the best that the authors can come up with. I think we're all open to the prospect of alternate designs that achieve the same goal, although I would hope we don't spend too much time exploring the solution space. /a From roman@telurix.com Tue Jul 23 09:22: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 4042211E82E1 for ; Tue, 23 Jul 2013 09:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 q1BZs3hZ83uH for ; Tue, 23 Jul 2013 09:22:16 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBC11E82DF for ; Tue, 23 Jul 2013 09:22:13 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3249203wiv.11 for ; Tue, 23 Jul 2013 09:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KDXiQGsi99e89ta9X69/x5ScHrL7ElnWC+oZ8hX+VbQ=; b=nzcH09JB8wdFIqM7gAm2HnLWymGo0Q9h4UNsqReNerPcTmVbwlQbOYxWj3l7YAQkda vAje9FWkuyS71vgJCASJ6qXr3ALpUYCkfAqevanm0Y6Md1FPMIXtu47Cqm1swKxAwmwB rIhxQ1fydUzZMCc+yEhPK7ww9KlnYRde7apMa0jVDkaXNgGwBsMUzG81njiD4XXrhbkx BS15p+3EH5FT2htoduXhhXgSeVcOqvATnPEEt/uNN4QQ9gnjslPjjavXwqIJP1mn6YUh OsTmyvZN6utlbjOUv+RYQ4ArQ7yhxeD5saSTZYyfbdTRDo7hBx1YkQJYVbxq5SrYRNLz fcJg== X-Received: by 10.180.182.229 with SMTP id eh5mr22387475wic.63.1374596532636; Tue, 23 Jul 2013 09:22:12 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [2a00:1450:400c:c03::22a]) by mx.google.com with ESMTPSA id r8sm7042117wiz.5.2013.07.23.09.22.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 09:22:12 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so1167994wes.1 for ; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr33344187wiz.47.1374596530407; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) Date: Tue, 23 Jul 2013 12:22:10 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d0442808ee7904104e2303130 X-Gm-Message-State: ALoCoQmE6WUdVL08xBlC7SwDOa7uENRt/tZT2f8N4Ejiau/WgbG9dQYo+HQ/v36jV1Uyfzk0S0Ia Cc: rtcweb@ietf.org, mmusic@ietf.org, tim panton Subject: [MMUSIC] Unified plan IPR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:22:21 -0000 --f46d0442808ee7904104e2303130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing the title and the mailing list to the more appropriate. The situation would be a bit clearer if patent holders were to provide the licensing policy regarding this IPR release. Given that Ericsson is actively involved in this working group, I think it would be reasonable to ask them for this. Regards, _____________ Roman Shpount On Tue, Jul 23, 2013 at 11:51 AM, Adam Roach wrote: > On 7/23/13 09:20, tim panton wrote: > > On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK wrote: > > > On 7/23/13 5:03 AM, Justin Uberti wrote: > > With the compromise reached in the Unified Plan document, > > Presumably http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > I'll draw folks attention to this IPR claim > https://datatracker.ietf.org/ipr/2141/ > > What does that mean in practice? > > > > In practice, it has very little effect. > > For those of you unfamiliar with IETF IPR policy, it is documented in RFC > 3979: > > http://www.ietf.org/rfc/rfc3979.txt > > The disclosure Tim points to is made pursuant to section 6.1.3 of that > document. During the course of developing the unified plan, the > applications that are mentioned in that disclosure were brought to my > attention. > > The reason it has little effect in practice is that the independent claim= s > would appear to cover every plan proposal to date (plan a, plan b, unifie= d > plan, and even all of the "no plan" variations). Consequently, it does no= t > benefit any one approach over the others. > > /a > --f46d0442808ee7904104e2303130 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing the title and the mailing list to the more appropriate.

The= situation would be a bit clearer if patent holders were to provide the lic= ensing policy regarding this IPR release.=A0Given that Ericsson is actively= involved in this working group, I think it would be reasonable to ask them= for this.

Regards,
_____________
Roman Shpount


On Tue, Jul 23, 2013 at 11:51 AM, Adam R= oach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/23/13 09:20, tim panton wrote:
On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK <stefan.lk.hakanss=
on@ericsson.com> wrote:


On 7/23/13 5:03 AM, Justin Uberti wrote:

With the compromise reached in the Unified Plan document,

Presumably http://www.ietf.org/id/draft-roach=
-mmusic-unified-plan-00.txt

I'll draw folks attention to this IPR claim

https:=
//datatracker.ietf.org/ipr/2141/

What does that mean in practice?

In practice, it has very little effect.

For those of you unfamiliar with IETF IPR policy, it is documented in RFC 3979:

=20 http:= //www.ietf.org/rfc/rfc3979.txt

The disclosure Tim points to is made pursuant to section 6.1.3 of that document. During the course of developing the unified plan, the applications that are mentioned in that disclosure were brought to my attention.

The reason it has little effect in practice is that the independent claims would appear to cover every plan proposal to date (plan a, plan b, unified plan, and even all of the "no plan" variation= s). Consequently, it does not benefit any one approach over the others.

/a

--f46d0442808ee7904104e2303130-- From adam@nostrum.com Tue Jul 23 09:52: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 6E8D811E82E7; Tue, 23 Jul 2013 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 UydYF1hC0llp; Tue, 23 Jul 2013 09:52:00 -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 3871711E82D9; Tue, 23 Jul 2013 09:51:41 -0700 (PDT) Received: from orochi-2.roach.at (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 r6NGpcLT010652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 11:51:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EEB495.4070404@nostrum.com> Date: Tue, 23 Jul 2013 11:51:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org, mmusic@ietf.org, tim panton Subject: Re: [MMUSIC] Unified plan IPR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 16:52:00 -0000 On 7/23/13 11:22, Roman Shpount wrote: > The situation would be a bit clearer if patent holders were to provide > the licensing policy regarding this IPR release. Given that Ericsson > is actively involved in this working group, I think it would be > reasonable to ask them for this. If process has been properly followed, the IPR holder has already been notified by the IETF executive director. See http://www.ietf.org/rfc/rfc4879.txt (section 1 paragraph 1) I doubt agitating for action on these mailing lists is likely to produce useful results. /a From emil@sip-communicator.org Tue Jul 23 10:06: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 E91B211E8228 for ; Tue, 23 Jul 2013 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=1.450, 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 ulGR-5fM2znu for ; Tue, 23 Jul 2013 10:06:21 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id ED77411E82CE for ; Tue, 23 Jul 2013 10:06:20 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z12so2133158wgg.34 for ; Tue, 23 Jul 2013 10:06:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=c/EBGYyJQ0acW2oHg+DAig1j5nCE0a6wt3TmYCIxw1k=; b=iFHQZjrmNDDjQtfmXbsAVcqBeIsFAXEMqdzmH2YBG6QXokf756og+iYIqrHtG+jiIQ oxWt4fLMlbrvd5XHfr0o/cQ54IpLYJv4z4nzFNpHfNg0CZGYwl6Nvp8OflX6ZOIRzNdp sYhyNJJC3+XyYq9WFLVB3QXVxPtMN2S8m6IDyNC4UVoM5nSaev1u9S3pIZvn8dAutzoJ kr3WHkpt4b6D7LcEXCFysn4OHH913Uw8jdTk3Eylze+rDek/0rLZNgKum3+nZToJ3EEo fW89ak+2GceET18ryjbiSuCZodGkzJYFC9OV6lZHypyi4q6+IZZukxGkrZfL08RYVLLC 46EQ== X-Received: by 10.180.38.102 with SMTP id f6mr22508654wik.12.1374599178770; Tue, 23 Jul 2013 10:06:18 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:70aa:c965:caa2:ddb]) by mx.google.com with ESMTPSA id li9sm7337813wic.2.2013.07.23.10.06.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 10:06:17 -0700 (PDT) Message-ID: <51EEB807.6010704@jitsi.org> Date: Tue, 23 Jul 2013 19:06:15 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlGm8geQe0yYsNnB1kJCVZlDIPV+prbehCLVHhVXFrK2F4pi/q0/DTHouvlhl2Nuj2mQuL0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Tue, 23 Jul 2013 17:06:26 -0000 On 22.07.13, 13:11, Christer Holmberg wrote: > Hi, > >>>>> How is this better than PRACK? >>>> >>>> Well, you don't have to worry about supporting offers and answers in the PRACK (which could indeed be a pain). >>> >>> In my years of "PRACK experience", PRACK itself (for the purpose of acknowledging reliable 18x responses) has never been a >>> problem. But, I agree there could be issues when it is used for O/A - especially if one wants to reject an offer. In my experience, however, >>> offers in PRACK are normally used e.g. to change pre-condition state, and/or to remove codecs, so the likelihood of rejection based on the SDP content should be rather small. >>> >>> There are also implementations that don't accept offers in PRACK to >>> begin with, but I think that goes under "bad implementation" :) >>> >>> Having said that, not specific to trickle ICE, if O/A is a show >>> stopper for the community to use PRACK, >> >> Well, speaking as an implementor, I can completely see how many would feel uneasy about adding this to working implementations. It basically means adding some additional complexity with no actual benefit in return. >> >>> maybe that is something we need to look into on a more general level. >> >> You mean something like PRACK-lite that doesn't have offer answer? This sounds like something that could be relatively straightforward to specify. It would basically >> have to mimic PRACK but remove the part that talks about the additional O/A possibilities. > > It could perhaps even be a request without a response, similar to ACK, which would make it even more "lite". When the UAS receives it, it simply ceases the transmission of the 18x. Hmm ... this sounds like something that would make a lot of proxies and SIP stacks unhappy. I actually think we could pull this off with simple PRACKs. Only, rather than using the "100rel" tag we go for something like "100rel-lite" which could be defined to indicate that a UA supports PRACK but only for reliability (and PRACK bodies are not allowed). Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Tue Jul 23 11:00: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 08CCC21E80D2 for ; Tue, 23 Jul 2013 11:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=0.234, 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 KVeYIaZuEl2t for ; Tue, 23 Jul 2013 11:00:10 -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 0F5F911E8322 for ; Tue, 23 Jul 2013 11:00:09 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3suT1m0041ei1Bg55u09zK; Tue, 23 Jul 2013 18:00:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 3u081m0163ZTu2S3ku08Vx; Tue, 23 Jul 2013 18:00:08 +0000 Message-ID: <51EEC4A8.9050108@alum.mit.edu> Date: Tue, 23 Jul 2013 14:00:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF MMUSIC WG 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=1374602409; bh=CVUOBO1MRy8+euFy9lNlow2m3YRsBs5QcU0hYrAodLI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fsFWgtjMKRUY1jtHrOQ8dITH95V4fn+6S8ll3u9LnXpNY3ek2sNOLk1VrDMXHiOZu aq6MNsSsm5l3OJA8HSAgTV+54C6O1AaTfP72YvOH/sL5Rbf+OcHwZFAQGpdSbUYay1 KMyE+s5khJmHQsb9aJVRliYoR7pa0S0FotQrIGRfcENXnpRKDhYVDg8Z3/XCAz70TD WPWEBpWkwdf+/XgJo4P3zGyLr04dGZOQNJIQR635sAeQ0NiK/YtMZBGb80yHNgqWyN ZAjIx+ewoPgT49EqsDPb08ma+zsYp54dLEisIWmToKKlAHuIY8wyThOYuY7+5VlPMH JdNQEZTcezRSA== Subject: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Jul 2013 18:00:16 -0000 I just reviewed this new version. I have a number of comments: * Section 5: You don't go into the details of the O/A rules. But I infer you assume that the answer will be a subset of the offer, with the priorities possibly changed. This is a common strategy with SDP O/A, but it is limiting because it doesn't allow the answerer to indicate capabilities it has that weren't mentioned by the offerer. Knowing that could be useful, especially if a mismatch is going to result in recruiting a relay service. I suggest that answer allow the answerer to indicate all of its capabilities and preferences, and at the same time indicate choices made. (If a choice was made.) * Section 7.1: Instead of humanintlang-send and humanintlang-recv, how about just giving the lang tag and a send/recv/sendrecv parameter with it? This would be more concise when sendrecv can be used. Suggest using a parameter (q) to indicate relative preference for languages, rather than ordering. This can show degree of preference, and can show when multiple languages have the same preference. Example: a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 To accommodate my comment about section 5, perhaps the answer can "mark" the alternative(s) that have been chosen for use, if any. (I'm not sure I like this, but for now, lets assume a "*" suffix on the direction in the answer.) E.g., assuming the offer above, then an answer like: a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 Also in this section, the following: Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag indicates a request for a supplemental video stream to see the speaker. might be ambiguous in the presence of many streams. It might be good to define a grouping framework (RFC 5888) usage to group an audio stream with a video stream that contains the speaker(s) of the audio. Also in this section, the following: Clients acting on behalf of end users are expected to set one or both 'humintlang-send' and 'humintlang-recv' attributes on each media stream in an offer when placing an outgoing session but ignore the attributes when receiving incoming calls. Systems acting on behalf of call centers and PSAPs are expected to take into account the values when processing inbound calls. Are you intending to exclude clients taking a more active role? (E.g., Isn't it possible that a client receiving an incoming call in a language it doesn't support might bridge in a relay service?) Should a client that can't do anything useful with the language info still indicate its language preferences in the answer? I would think this would still be helpful. It might allow the caller, or a middlebox, to compensate in some way. What I suggest above allows that. * Section 7.2 (Advisory vs Required): Rather than "*" suffix, would be cleaner to have a separate indicator. And it seems like this should not be on a particular language tag. If you speak both Spanish and English, you may want the call to succeed if the callee can do one or the other, and otherwise fail. A tag per language doesn't do that. Need more discussion for how to denote this. Thanks, Paul From christer.holmberg@ericsson.com Tue Jul 23 12:23: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 9A7AD11E838A for ; Tue, 23 Jul 2013 12:23:58 -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 8iO9Bzc0Bx+u for ; Tue, 23 Jul 2013 12:23:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6684A11E8382 for ; Tue, 23 Jul 2013 12:23:51 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-83-51eed8468642 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.68.05990.648DEE15; Tue, 23 Jul 2013 21:23:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 21:23:49 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOhsxOmoY6im5NjkKbz0BNRi4Q7ZlyXsGAgABH9/0= Date: Tue, 23 Jul 2013 19:23:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C404166@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se>, <51EEB807.6010704@jitsi.org> In-Reply-To: <51EEB807.6010704@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C404166ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvra7bjXeBBjv2CVis2TmBxWLq8scs Fis2HGC12LW9xoHF4+/7D0weS5b8ZPL4/ybQ48bt98wBLFFcNimpOZllqUX6dglcGY/7LzEV PLOoOPt5AXsD4xP9LkZODgkBE4kpDyexQthiEhfurWfrYuTiEBI4zCgx+2kbC0hCSGAJo8Td 17ZdjBwcbAIWEt3/tEHCIgLyEt1ti5hA6pkFWhglmr63gg0SFjCWeHiskQmkXgRowesrbhD1 VhLHH+1gB7FZBFQljqxpYgEp4RXwlXjVXgKxdierROfuS2A1nAKaEhP6jzGD2IxAt30/tYYJ xGYWEJe49WQ+E8TNAhJL9pxnhrBFJV4+/scKUZMv8eL9AbAaXgFBiZMzn7BMYBSZhaR9FpKy WUjKIOJ6EjemTmGDsLUlli18zQxh60rM+HeIBVl8ASP7Kkb23MTMnPRyo02MwOg6uOW36g7G O+dEDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxsTP70v2l00zXTf8n tfrqe9lF6m0vGdNPMp6OWhL55zUfC0PeaoHlXfus1i/X5bMz5BTZ+STqveqPtYss78fMeBai sdjitI3GQ6njV5Rd+V3tKp1NbOZqCroc6t9iPWsm28xT5WVc+qq5Px9Nm/m9/vjTWhPrTWJv olvNTEIKjRavmpwcvvSiEktxRqKhFnNRcSIATcn+hnwCAAA= Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Tue, 23 Jul 2013 19:23:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C404166ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, You are right that sending a request, without a response, would cause probl= ems. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Emil Ivov [emcho@jitsi.org] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Paul Kyzivat [pkyzivat@alum.mit.edu]; Stach, Thomas [thomas.stach@sieme= ns-enterprise.com]; mmusic@ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions On 22.07.13, 13:11, Christer Holmberg wrote: > Hi, > >>>>> How is this better than PRACK? >>>> >>>> Well, you don't have to worry about supporting offers and answers in t= he PRACK (which could indeed be a pain). >>> >>> In my years of "PRACK experience", PRACK itself (for the purpose of ack= nowledging reliable 18x responses) has never been a >>> problem. But, I agree there could be issues when it is used for O/A - e= specially if one wants to reject an offer. In my experience, however, >>> offers in PRACK are normally used e.g. to change pre-condition state, a= nd/or to remove codecs, so the likelihood of rejection based on the SDP con= tent should be rather small. >>> >>> There are also implementations that don't accept offers in PRACK to >>> begin with, but I think that goes under "bad implementation" :) >>> >>> Having said that, not specific to trickle ICE, if O/A is a show >>> stopper for the community to use PRACK, >> >> Well, speaking as an implementor, I can completely see how many would fe= el uneasy about adding this to working implementations. It basically means = adding some additional complexity with no actual benefit in return. >> >>> maybe that is something we need to look into on a more general level. >> >> You mean something like PRACK-lite that doesn't have offer answer? This = sounds like something that could be relatively straightforward to specify. = It would basically >> have to mimic PRACK but remove the part that talks about the additional = O/A possibilities. > > It could perhaps even be a request without a response, similar to ACK, wh= ich would make it even more "lite". When the UAS receives it, it simply cea= ses the transmission of the 18x. Hmm ... this sounds like something that would make a lot of proxies and SIP stacks unhappy. I actually think we could pull this off with simple PRACKs. Only, rather than using the "100rel" tag we go for something like "100rel-lite" which could be defined to indicate that a UA supports PRACK but only for reliability (and PRACK bodies are not allowed). Emil -- https://jitsi.org --_000_7594FB04B1934943A5C02806D1A2204B1C404166ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
You are right that sending a request, without a= response, would cause problems.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [emcho@jitsi.org]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Paul Kyzivat [pkyzivat@alum.mit.edu]; Stach, Thomas [thomas.stac= h@siemens-enterprise.com]; mmusic@ietf.org [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions


On 22.07.13, 13:11, Christer Holmberg wrote:
> Hi,
>
>>>>> How is this better than PRACK?
>>>>
>>>> Well, you don't have to worry about supporting offers and = answers in the PRACK (which could indeed be a pain).
>>>
>>> In my years of "PRACK experience", PRACK itself (for= the purpose of acknowledging reliable 18x responses) has never been a
>>> problem. But, I agree there could be issues when it is used fo= r O/A - especially if one wants to reject an offer. In my experience, howev= er,
>>> offers in PRACK are normally used e.g. to change pre-condition= state, and/or to remove codecs, so the likelihood of rejection based on th= e SDP content should be rather small.
>>>
>>> There are also implementations that don't accept offers in PRA= CK to
>>> begin with, but I think that goes under "bad implementati= on" :)
>>>
>>> Having said that, not specific to trickle ICE, if O/A is a sho= w
>>> stopper for the community to use PRACK,
>>
>> Well, speaking as an implementor, I can completely see how many wo= uld feel uneasy about adding this to working implementations. It basically = means adding some additional complexity with no actual benefit in return. >>
>>> maybe that is something we need to look into on a more general= level.
>>
>> You mean something like PRACK-lite that doesn't have offer answer?= This sounds like something that could be relatively straightforward to spe= cify. It would basically
>> have to mimic PRACK but remove the part that talks about the addit= ional O/A possibilities.
>
> It could perhaps even be a request without a response, similar to ACK,= which would make it even more "lite". When the UAS receives it, = it simply ceases the transmission of the 18x.

Hmm ... this sounds like something that would make a lot of proxies and SIP stacks unhappy.

I actually think we could pull this off with simple PRACKs. Only, rather than using the "100rel" tag we go for something like "100rel= -lite" which
could be defined to indicate that a UA supports PRACK but only for
reliability (and PRACK bodies are not allowed).

Emil


--
https://jitsi.org
 --_000_7594FB04B1934943A5C02806D1A2204B1C404166ESESSMB209erics_-- From matthew.kaufman@skype.net Tue Jul 23 13:19: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 63B5111E8130; Tue, 23 Jul 2013 13:19: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] 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 b7lT+PsoaZlh; Tue, 23 Jul 2013 13:19:25 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6192D11E8112; Tue, 23 Jul 2013 13:19:22 -0700 (PDT) Received: from mail150-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Tue, 23 Jul 2013 20:19:21 +0000 Received: from mail150-db9 (localhost [127.0.0.1]) by mail150-db9-R.bigfish.com (Postfix) with ESMTP id D36ABA0170; Tue, 23 Jul 2013 20:19:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzda00h1432Idc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail150-db9: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail150-db9 (localhost.localdomain [127.0.0.1]) by mail150-db9 (MessageSwitch) id 1374610759456070_25553; Tue, 23 Jul 2013 20:19:19 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.231]) by mail150-db9.bigfish.com (Postfix) with ESMTP id 5CAA71E0046; Tue, 23 Jul 2013 20:19:19 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 23 Jul 2013 20:19:16 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 23 Jul 2013 20:18:39 +0000 From: "Matthew Kaufman (SKYPE)" To: Adam Roach , Roman Shpount Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOh8DVjWlPWg1wtE6LFph3rvjdWJlyekSAgAA5pXA= Date: Tue, 23 Jul 2013 20:18:39 +0000 Message-ID: References: <51EEB495.4070404@nostrum.com> In-Reply-To: <51EEB495.4070404@nostrum.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skype.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , tim panton Subject: Re: [MMUSIC] [rtcweb] Unified plan IPR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 20:19:31 -0000 Adam Roach: > > I doubt agitating for action on these mailing lists is likely to produce = useful > results. This appears to be generally true, yes. One wonders why we have them. Matthew Kaufman From gunnar.hellstrom@omnitor.se Tue Jul 23 15:37: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 3C5CE11E813F for ; Tue, 23 Jul 2013 15:37:02 -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 ZlObMd7j4RjB for ; Tue, 23 Jul 2013 15:36:56 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 1B2FC11E8150 for ; Tue, 23 Jul 2013 15:36:40 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 24 Jul 2013 00:35:50 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id D66BD3A169 for ; Wed, 24 Jul 2013 00:35:50 +0200 (CEST) Message-ID: <51EF0546.6000604@omnitor.se> Date: Wed, 24 Jul 2013 00:35:50 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EEC4A8.9050108@alum.mit.edu> In-Reply-To: <51EEC4A8.9050108@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Jul 2013 22:37:02 -0000 On 2013-07-23 20:00, Paul Kyzivat wrote: > I just reviewed this new version. I have a number of comments: Good comments Paul, > > * Section 5: > > You don't go into the details of the O/A rules. But I infer you assume > that the answer will be a subset of the offer, with the priorities > possibly changed. This is a common strategy with SDP O/A, but it is > limiting because it doesn't allow the answerer to indicate > capabilities it has that weren't mentioned by the offerer. Knowing > that could be useful, especially if a mismatch is going to result in > recruiting a relay service. > > I suggest that answer allow the answerer to indicate all of its > capabilities and preferences, and at the same time indicate choices > made. (If a choice was made.) Yes, very useful to indicate all. > > * Section 7.1: > > Instead of humanintlang-send and humanintlang-recv, how about just > giving the lang tag and a send/recv/sendrecv parameter with it? This > would be more concise when sendrecv can be used. > > Suggest using a parameter (q) to indicate relative preference for > languages, rather than ordering. This can show degree of preference, > and can show when multiple languages have the same preference. > Have you seen my request for an indication of level of preference between the different modalities? A possiblility to indicate for example that British Sign Language is highly preferred, but English text possible. The q values could be used for coding of such relative level of preference even between modalities. a q=1 for BSL in video, and a q=0.1 for English in text. Right? > Example: > > a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 > > To accommodate my comment about section 5, perhaps the answer can > "mark" the alternative(s) that have been chosen for use, if any. (I'm > not sure I like this, but for now, lets assume a "*" suffix on the > direction in the answer.) E.g., assuming the offer above, then an > answer like: > > a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 > > Also in this section, the following: > > Note that while signed language tags are used with a video stream to > indicate sign language, a spoken language tag for a video stream in > parallel with an audio stream with the same spoken language tag > indicates a request for a supplemental video stream to see the > speaker. > > might be ambiguous in the presence of many streams. It might be good > to define a grouping framework (RFC 5888) usage to group an audio > stream with a video stream that contains the speaker(s) of the audio. This is both a threat and a solution. There are already other reasons to group media in SDP. We have a risk of ending up in a very complex coding in SDP to get this correctly specified in an environment where there are also other reasons to group m-lines. This is why I am still hesitating if the whole thing would not fit better as tags on the SIP level. > > Also in this section, the following: > > Clients acting on behalf of end users are expected to set one or both > 'humintlang-send' and 'humintlang-recv' attributes on each media > stream in an offer when placing an outgoing session but ignore the > attributes when receiving incoming calls. Systems acting on behalf > of call centers and PSAPs are expected to take into account the > values when processing inbound calls. > > Are you intending to exclude clients taking a more active role? (E.g., > Isn't it possible that a client receiving an incoming call in a > language it doesn't support might bridge in a relay service?) I have asked for deletion of this limiting paragraph. > > Should a client that can't do anything useful with the language info > still indicate its language preferences in the answer? I would think > this would still be helpful. It might allow the caller, or a > middlebox, to compensate in some way. What I suggest above allows that. Yes, I prefer that view. The answering part shall answer if it can. middleboxes or the offering part may do the invocation of services to cover the gaps. > > * Section 7.2 (Advisory vs Required): > > Rather than "*" suffix, would be cleaner to have a separate indicator. > And it seems like this should not be on a particular language tag. If > you speak both Spanish and English, you may want the call to succeed > if the callee can do one or the other, and otherwise fail. A tag per > language doesn't do that. Yes, tricky. I am getting a feeling that we should start a draft describing usage in parallel to this one, so that use cases can be verified. > > Need more discussion for how to denote this. > > Thanks, > Paul > Gunnar > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Jul 23 17:05: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 25D7C11E8195 for ; Tue, 23 Jul 2013 17:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.242, 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 hfYgxfKS2BoQ for ; Tue, 23 Jul 2013 17:05:43 -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 7D32111E8193 for ; Tue, 23 Jul 2013 17:05:42 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3znR1m00116LCl05505hgz; Wed, 24 Jul 2013 00:05:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 405h1m01H3ZTu2S3S05hax; Wed, 24 Jul 2013 00:05:41 +0000 Message-ID: <51EF1A54.2070302@alum.mit.edu> Date: Tue, 23 Jul 2013 20:05:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> In-Reply-To: <51EF0546.6000604@omnitor.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=1374624341; bh=mviMsZn/pYCjFQotc1NxGecAdVy5Unh9iH0GzsR/m0A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WRhA8v8QErn8xLrqF1pzAd3KgIhlE1KuZib74BC69SqjkMItxTD12y6JModaLKmbT hTrRQOgCWYu/4F0Tb6TrC9KJY2aeKRja+Z4cN+G0J8GPBlbErOcophlWGr9WcdPW6Z oqDzcb6P8Pb3ubmsmAkzBSjVRzDe0H2Qks5i1PLcpi8UxQkxDhcpPxpRjxMyDNifH+ BU9dD4pS9FpDyVwcT/08XFDYXLOyYTVj3UYht4emiji3JY3VkwPbBLwL6hIjJA4+/N F1QEyejeMn7l8BNdYvMDyt03asz15I38tilsD67U5ioB122LehfjgKht+jhV3eIS8d bu5o9NgeXVwvw== Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Jul 2013 00:05:49 -0000 On 7/23/13 6:35 PM, Gunnar Hellstrom wrote: > > On 2013-07-23 20:00, Paul Kyzivat wrote: >> I just reviewed this new version. I have a number of comments: > Good comments Paul, >> >> * Section 5: >> >> You don't go into the details of the O/A rules. But I infer you assume >> that the answer will be a subset of the offer, with the priorities >> possibly changed. This is a common strategy with SDP O/A, but it is >> limiting because it doesn't allow the answerer to indicate >> capabilities it has that weren't mentioned by the offerer. Knowing >> that could be useful, especially if a mismatch is going to result in >> recruiting a relay service. >> >> I suggest that answer allow the answerer to indicate all of its >> capabilities and preferences, and at the same time indicate choices >> made. (If a choice was made.) > Yes, very useful to indicate all. >> >> * Section 7.1: >> >> Instead of humanintlang-send and humanintlang-recv, how about just >> giving the lang tag and a send/recv/sendrecv parameter with it? This >> would be more concise when sendrecv can be used. >> >> Suggest using a parameter (q) to indicate relative preference for >> languages, rather than ordering. This can show degree of preference, >> and can show when multiple languages have the same preference. >> > Have you seen my request for an indication of level of preference > between the different modalities? A possiblility to indicate for example > that British Sign Language is highly preferred, but English text possible. > The q values could be used for coding of such relative level of > preference even between modalities. a q=1 for BSL in video, and a q=0.1 > for English in text. Right? That would work within a single medium. But I don't think we can use that mechanism to trade off between different media. For that I think some other, more complex, mechanism would be needed. Or else we would need a more complex definition of which things are being prioritized against one another in order to use the q-values. >> Example: >> >> a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 >> >> To accommodate my comment about section 5, perhaps the answer can >> "mark" the alternative(s) that have been chosen for use, if any. (I'm >> not sure I like this, but for now, lets assume a "*" suffix on the >> direction in the answer.) E.g., assuming the offer above, then an >> answer like: >> >> a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 >> >> Also in this section, the following: >> >> Note that while signed language tags are used with a video stream to >> indicate sign language, a spoken language tag for a video stream in >> parallel with an audio stream with the same spoken language tag >> indicates a request for a supplemental video stream to see the >> speaker. >> >> might be ambiguous in the presence of many streams. It might be good >> to define a grouping framework (RFC 5888) usage to group an audio >> stream with a video stream that contains the speaker(s) of the audio. > This is both a threat and a solution. There are already other > reasons to group media in SDP. We have a risk of ending up in a very > complex coding in SDP to get this correctly specified in an environment > where there are also other reasons to group m-lines. This is why I am > still hesitating if the whole thing would not fit better as tags on the > SIP level. I notice Henning just asked about this today, in a different forum. Perhaps some things are better done at the sip level, and others at the SDP level. Its also possible that correlations between different media streams should be left to other mechanisms. E.g., CLUE could signal better correlations between audio and video. Thanks, Paul >> >> Also in this section, the following: >> >> Clients acting on behalf of end users are expected to set one or both >> 'humintlang-send' and 'humintlang-recv' attributes on each media >> stream in an offer when placing an outgoing session but ignore the >> attributes when receiving incoming calls. Systems acting on behalf >> of call centers and PSAPs are expected to take into account the >> values when processing inbound calls. >> >> Are you intending to exclude clients taking a more active role? (E.g., >> Isn't it possible that a client receiving an incoming call in a >> language it doesn't support might bridge in a relay service?) > I have asked for deletion of this limiting paragraph. >> >> Should a client that can't do anything useful with the language info >> still indicate its language preferences in the answer? I would think >> this would still be helpful. It might allow the caller, or a >> middlebox, to compensate in some way. What I suggest above allows that. > Yes, I prefer that view. The answering part shall answer if it can. > middleboxes or the offering part may do the invocation of services to > cover the gaps. >> >> * Section 7.2 (Advisory vs Required): >> >> Rather than "*" suffix, would be cleaner to have a separate indicator. >> And it seems like this should not be on a particular language tag. If >> you speak both Spanish and English, you may want the call to succeed >> if the callee can do one or the other, and otherwise fail. A tag per >> language doesn't do that. > > Yes, tricky. I am getting a feeling that we should start a draft > describing usage in parallel to this one, so that use cases can be > verified. > >> >> Need more discussion for how to denote this. >> >> Thanks, >> Paul >> > Gunnar >> _______________________________________________ >> 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 Tue Jul 23 20:29: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 D394211E81CE for ; Tue, 23 Jul 2013 20:29:03 -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 W2wxhiy1eLc9 for ; Tue, 23 Jul 2013 20:28: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 EE8A511E81C7 for ; Tue, 23 Jul 2013 20:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3343; q=dns/txt; s=iport; t=1374636539; x=1375846139; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4gHWefjD8horLG6sx2XThc33VIfC/k0tJ2CX0Pe/1w4=; b=dCc6uCXH9ZBG1Bjo+Hc6UrtBZ2OYA/W/vwAm1J8LH4cOop+whNBfko+a XtQbkvtIkh5zixhDPr3XdjxfY9eJ+KfWm4+f75r4S4p5hekIvVnj2WNpo KDuKyjq83oIH7fdU05eM+PH92zPu2dWQsTGtSBOJk+edlSPv1SfGV+HyA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAN9I71GtJV2a/2dsb2JhbABbgwY1UMB/gRQWdIIkAQEBAwEBAQE3NBALAgEIDhQUECcLJQIEARIIE4dvBgy4EwSOOoENAjiDEm4DlAiVJIMUgio X-IronPort-AV: E=Sophos;i="4.89,732,1367971200"; d="scan'208";a="238578750" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2013 03:28:53 +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 r6O3Sqoc014949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 03:28:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 22:28:53 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov , MMUSIC IETF WG Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOiB3rsesO7v/XCUiNMNrfupXiAQ== Date: Wed, 24 Jul 2013 03:28:52 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> In-Reply-To: <51D43186.2010907@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <35DC141406D221448ED275169DFD4FC2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 03:29:03 -0000 I prefer the 180 resend approach and all the right things are already looki= ng at them. I have always objected to mandating use of PRACK. Obviously I'= m fine with things that have PRACK can use it but I want some solution for = things that don't.=20 One small note, the SDP in the 180 can change as long as the to-tag is also= changed.=20 On Jul 3, 2013, at 8:13 AM, Emil Ivov wrote: > Hey all, >=20 > Christer, Enrico and I are preparing the next version of Trickle ICE for = SIP. Now that discussions on BUNDLE and the plans seem to be winding down, = we wanted to run a few questions by the working group. >=20 > Q1: Making reliable provisional responses and PRACK mandatory. Obviously = this would be nice to avoid, so the question is: is there a reasonable mech= anism to achieve this (and by reasonable, we mean something that wouldn't b= e harder than implementing support for PRACK). >=20 > There was some discussion about this back in April and there was a sugges= tion for implementing a 5245-style hack where the answerer basically resend= s the 180 until it knows that it has been received. >=20 > 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions= when the first connectivity check is received) but we don't have that opti= on here since the 180 may contain either none or only host candidates so th= ere are strong chances that no binding request would be received on them. >=20 > Thomas also suggested a second option which would be to also use INFO req= uests with trickled candidates as an indication that 180 was received. This= however wouldn't work with half trickle so we are basically back to vanill= a ICE for all (non-re) INVITEs. >=20 > Another option would be to mandate an INFO request with "end-of-candidate= s" in response to the 180, but that would be just the same as mandating PRA= CK support. >=20 > Thomas also suggested that the answerer can start sending INFOs right aft= er it sends its answer in the 180 and then it can just resend the 180 if th= e INFOs result in a 481 response. >=20 > Personally I think this could potentially be made to work, but it would i= mply a level of complexity that considerably exceeds PRACK support. >=20 > Opinions? >=20 > Q2: How do we send INFOs? Are they blocking or do we just send them in pa= rallel? If the latter, then what happens when an INFO fails because it is r= eceived out of order? Do we just tell the application to resend the candida= tes asap? >=20 > This also leads to the following question: >=20 > Q3: What exactly do we send in INFOs? Just the latest batch of freshly le= arned candidates or all candidates we've learned so far? Dale suggested tha= t if we do this cumulatively we wouldn't need to worry about the case with = the out-of-order INFOs from Q2 since the information gets resent anyway. A = drawback here would obviously be that this adds more complexity for trickle= ICE users (WebRTC applications specifically) >=20 > A third option would be to allow both and leave it to the application. >=20 > Comments are most welcome! >=20 > Emil >=20 > --=20 > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gunnar.hellstrom@omnitor.se Tue Jul 23 23:48: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 3829811E8395 for ; Tue, 23 Jul 2013 23:48: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] 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 ap8b9WmmqxZY for ; Tue, 23 Jul 2013 23:48:54 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 5FF5E11E80E3 for ; Tue, 23 Jul 2013 23:48:53 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 24 Jul 2013 08:48:41 +0200 (CEST) Received: from [192.168.50.33] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id C14583A165 for ; Wed, 24 Jul 2013 08:48:41 +0200 (CEST) Message-ID: <51EF78CA.6040202@omnitor.se> Date: Wed, 24 Jul 2013 08:48:42 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu> In-Reply-To: <51EF1A54.2070302@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Jul 2013 06:48:59 -0000 On 2013-07-24 02:05, Paul Kyzivat wrote: > On 7/23/13 6:35 PM, Gunnar Hellstrom wrote: >> >> On 2013-07-23 20:00, Paul Kyzivat wrote: >>> I just reviewed this new version. I have a number of comments: >> Good comments Paul, >>> >>> * Section 5: >>> >>> You don't go into the details of the O/A rules. But I infer you assume >>> that the answer will be a subset of the offer, with the priorities >>> possibly changed. This is a common strategy with SDP O/A, but it is >>> limiting because it doesn't allow the answerer to indicate >>> capabilities it has that weren't mentioned by the offerer. Knowing >>> that could be useful, especially if a mismatch is going to result in >>> recruiting a relay service. >>> >>> I suggest that answer allow the answerer to indicate all of its >>> capabilities and preferences, and at the same time indicate choices >>> made. (If a choice was made.) >> Yes, very useful to indicate all. >>> >>> * Section 7.1: >>> >>> Instead of humanintlang-send and humanintlang-recv, how about just >>> giving the lang tag and a send/recv/sendrecv parameter with it? This >>> would be more concise when sendrecv can be used. >>> >>> Suggest using a parameter (q) to indicate relative preference for >>> languages, rather than ordering. This can show degree of preference, >>> and can show when multiple languages have the same preference. >>> >> Have you seen my request for an indication of level of preference >> between the different modalities? A possiblility to indicate for example >> that British Sign Language is highly preferred, but English text >> possible. >> The q values could be used for coding of such relative level of >> preference even between modalities. a q=1 for BSL in video, and a q=0.1 >> for English in text. Right? > > That would work within a single medium. > > But I don't think we can use that mechanism to trade off between > different media. For that I think some other, more complex, mechanism > would be needed. > > Or else we would need a more complex definition of which things are > being prioritized against one another in order to use the q-values. I proposed a simpler mechanism in a recent mail. It was to insert at the end of the humintlang tag a character a "!" for highly preferred, nothing for manageable and "#" for a non-preferred but possible fall-back language and modality. I think it will be very important for most users to have a chance to indicate this three-level preference order between different media as well as between different languages within one medium. I am hesitating a bit for the type of coding I proposed, and saw your proposal of q-value as something cleaner. When coding, you could make sure that the last resort medium gets q-values under 0.4, the strongly preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6. You can see the earlier motivation for the preference between modalities in the archive at: http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html > >>> Example: >>> >>> a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5 >>> >>> To accommodate my comment about section 5, perhaps the answer can >>> "mark" the alternative(s) that have been chosen for use, if any. (I'm >>> not sure I like this, but for now, lets assume a "*" suffix on the >>> direction in the answer.) E.g., assuming the offer above, then an >>> answer like: >>> >>> a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5 >>> >>> Also in this section, the following: >>> >>> Note that while signed language tags are used with a video stream to >>> indicate sign language, a spoken language tag for a video stream in >>> parallel with an audio stream with the same spoken language tag >>> indicates a request for a supplemental video stream to see the >>> speaker. >>> >>> might be ambiguous in the presence of many streams. It might be good >>> to define a grouping framework (RFC 5888) usage to group an audio >>> stream with a video stream that contains the speaker(s) of the audio. >> This is both a threat and a solution. There are already other >> reasons to group media in SDP. We have a risk of ending up in a very >> complex coding in SDP to get this correctly specified in an environment >> where there are also other reasons to group m-lines. This is why I am >> still hesitating if the whole thing would not fit better as tags on the >> SIP level. > > I notice Henning just asked about this today, in a different forum. > > Perhaps some things are better done at the sip level, and others at > the SDP level. > > Its also possible that correlations between different media streams > should be left to other mechanisms. E.g., CLUE could signal better > correlations between audio and video. Yes, but here we have three media. video, audio and text. CLUE need to take text on board. But you are right, if this mechanism is moved to SIP level, then we get the complex task to point out to what m-lines with the same medium do the humintlang-tags for that medium relate to. Simplifications need to be taken, so that we do not end up in specifying another CLUE. I think that part of the background for this draft is that the mechanism shall be usable in 3GPP Multimedia Telephony . That might be a reason why it ended up specified in SDP. Gunnar > > Thanks, > Paul > >>> >>> Also in this section, the following: >>> >>> Clients acting on behalf of end users are expected to set one or >>> both >>> 'humintlang-send' and 'humintlang-recv' attributes on each media >>> stream in an offer when placing an outgoing session but ignore the >>> attributes when receiving incoming calls. Systems acting on behalf >>> of call centers and PSAPs are expected to take into account the >>> values when processing inbound calls. >>> >>> Are you intending to exclude clients taking a more active role? (E.g., >>> Isn't it possible that a client receiving an incoming call in a >>> language it doesn't support might bridge in a relay service?) >> I have asked for deletion of this limiting paragraph. >>> >>> Should a client that can't do anything useful with the language info >>> still indicate its language preferences in the answer? I would think >>> this would still be helpful. It might allow the caller, or a >>> middlebox, to compensate in some way. What I suggest above allows that. >> Yes, I prefer that view. The answering part shall answer if it can. >> middleboxes or the offering part may do the invocation of services to >> cover the gaps. >>> >>> * Section 7.2 (Advisory vs Required): >>> >>> Rather than "*" suffix, would be cleaner to have a separate indicator. >>> And it seems like this should not be on a particular language tag. If >>> you speak both Spanish and English, you may want the call to succeed >>> if the callee can do one or the other, and otherwise fail. A tag per >>> language doesn't do that. >> >> Yes, tricky. I am getting a feeling that we should start a draft >> describing usage in parallel to this one, so that use cases can be >> verified. >> >>> >>> Need more discussion for how to denote this. >>> >>> Thanks, >>> Paul >>> >> Gunnar >>> _______________________________________________ >>> 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 stefan.lk.hakansson@ericsson.com Wed Jul 24 02:22: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 7E3AE11E83EF; Wed, 24 Jul 2013 02:22:20 -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 RS5h71U2NKaE; Wed, 24 Jul 2013 02:22:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5411E83E7; Wed, 24 Jul 2013 02:22:11 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-76-51ef9cc21603 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.42.19388.2CC9FE15; Wed, 24 Jul 2013 11:22:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 11:22:09 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOh8DTWQouOaWKZ069iwy97wHFxg== Date: Wed, 24 Jul 2013 09:22:09 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C336254@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre6hOe8DDRa8kLfY83cRu8XU5Y9Z LGZcmMpssfZfO7vFuvfHWBxYPZYs+cnkMWvnExaPW1MKPC5O288UwBLFZZOSmpNZllqkb5fA lfFw8UvWgkuCFcde7GRrYPzO28XIySEhYCJx8cEBJghbTOLCvfVsXYxcHEIChxklFm34A+Us YZT4MfsKM0gVm0CgxNZ9C9hAbBEBVYm/3yczgRQxC/QxSsy70wJWJCygJrG9vYsJokhdonf+ KnYIW0/iZdsCxi5GDg4WoOaP58pAwrwCvhLrn04AKxESCJA48ec62HxGoIu+n1oDNoZZQFzi 1pP5UJcKSCzZc54ZwhaVePn4HyuErSTRuOQJK0S9nsSNqVPYIGxtiWULXzND7BKUODnzCcsE RtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXm29iBEbPwS2/DXYwbrovdohRmoNFSZx3s96Z QCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MatVuc9xCy9levTJLUtepXpvfpFnob3GR4e5F vl77DPfYSX826f//VKGdxDTb05i1dhuTKntc+MmdHnP+VjenqU/yunybXa7q3+N7e0oXXLpu +p/njvCngtK9MomHdrlFRLHM5verqthyMt3c5sNeOU2LVZuqzG7sFO+ITLpxeLb8uZdFcj1K LMUZiYZazEXFiQCbQT+UbAIAAA== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , tim panton Subject: Re: [MMUSIC] [rtcweb] Unified plan IPR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 09:22:20 -0000 FYI,=0A= =0A= I've asked internally in my company for advice on what needs to be done =0A= (if anything) from our side. IPRs and handling of them is outside my =0A= competence.=0A= =0A= Stefan=0A= =0A= =0A= On 7/23/13 6:22 PM, Roman Shpount wrote:=0A= > Changing the title and the mailing list to the more appropriate.=0A= >=0A= > The situation would be a bit clearer if patent holders were to provide=0A= > the licensing policy regarding this IPR release. Given that Ericsson is= =0A= > actively involved in this working group, I think it would be reasonable= =0A= > to ask them for this.=0A= >=0A= > Regards,=0A= > _____________=0A= > Roman Shpount=0A= >=0A= >=0A= > On Tue, Jul 23, 2013 at 11:51 AM, Adam Roach > wrote:=0A= >=0A= > On 7/23/13 09:20, tim panton wrote:=0A= >> On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK wrote:=0A= >>=0A= >>> On 7/23/13 5:03 AM, Justin Uberti wrote:=0A= >>>> With the compromise reached in the Unified Plan document,=0A= >>> Presumablyhttp://www.ietf.org/id/draft-roach-mmusic-unified-plan-00= .txt=0A= >> I'll draw folks attention to this IPR claim=0A= >>=0A= >> https://datatracker.ietf.org/ipr/2141/=0A= >>=0A= >> What does that mean in practice?=0A= >>=0A= >=0A= > In practice, it has very little effect.=0A= >=0A= > For those of you unfamiliar with IETF IPR policy, it is documented=0A= > in RFC 3979:=0A= >=0A= > http://www.ietf.org/rfc/rfc3979.txt=0A= >=0A= > The disclosure Tim points to is made pursuant to section 6.1.3 of=0A= > that document. During the course of developing the unified plan, the= =0A= > applications that are mentioned in that disclosure were brought to=0A= > my attention.=0A= >=0A= > The reason it has little effect in practice is that the independent= =0A= > claims would appear to cover every plan proposal to date (plan a,=0A= > plan b, unified plan, and even all of the "no plan" variations).=0A= > Consequently, it does not benefit any one approach over the others.= =0A= >=0A= > /a=0A= >=0A= >=0A= =0A= From alan.b.johnston@gmail.com Wed Jul 24 02:45: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 70CA911E839B for ; Wed, 24 Jul 2013 02:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7Dxax70r5gh1 for ; Wed, 24 Jul 2013 02:45:49 -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 0FBBC11E8156 for ; Wed, 24 Jul 2013 02:45:48 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so2708770wgh.3 for ; Wed, 24 Jul 2013 02:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f/XHVKlhvp8rhsUsWeMTixnTSjmHfi4mckrGoyajwnk=; b=l1xIBmCmU82p4fPT5exqYFCEjPmJ2+zbqA0I5LXkeL10xJ0nL8Bntjzbj4EvAIXB8/ 9ITh14Vc7ceZB1vHKHxh+eyXMAse3bytf0+vzG3E3KBszMgArQFyvgv068HBVnsJtnSM qg0fcoXtYZEbVC9ihFrjfIQtl7vCN1RhVyjWxgsi5OYWUSonyV5ER93cLLX4R4LD5Exh u5tDL3w4Fd+t/7890+MCaD6AuwcFuSwuT0tidtFum4iRy/MWFoYV0l7sUdaGsB6W2wAT OcztwtjgztBtJiAgmH2Sr/mTryPzeuSyLGnLh5kPGlBCFSSIkeOZiPOdfADtOOJQgY5D Frqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f/XHVKlhvp8rhsUsWeMTixnTSjmHfi4mckrGoyajwnk=; b=kx1ID3WhredSKn/d11HCOJ6LUhfNk3N6MBjqbkY1b6bOVJJxBhtx30yh+K0lP0Z+kh NiFPnxrErVlvWUgV7pvQyzC1ohUm6V9cLjnMyPbpv4VaytIOlk5Vkh1fe7s0nEq0zFFM 8ak/T4DNJykx/fqkcqi8Y10EBBZIk90wnxbGmf9d7554QpuSxvkLMDlDSSmv0ilhdWZ6 VEt69LGnI/P1++bYt78q1k+VzNsJsjIjWlgFPfhnlJvndKl13PAYz8/2PHB6UfOe2Dll m/RiEtGaS3fF7GVg2+91WZq2tMQiUgj9EtUhodzkwq4sD8th9JQWUjHlZukfdh8EYIYe W9TA== MIME-Version: 1.0 X-Received: by 10.180.73.103 with SMTP id k7mr1833014wiv.24.1374659148167; Wed, 24 Jul 2013 02:45:48 -0700 (PDT) Received: by 10.216.83.205 with HTTP; Wed, 24 Jul 2013 02:45:48 -0700 (PDT) In-Reply-To: References: <51D43186.2010907@jitsi.org> Date: Wed, 24 Jul 2013 05:45:48 -0400 Message-ID: From: Alan Johnston To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=f46d043c815e36bfcc04e23ec6fa Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 09:45:50 -0000 --f46d043c815e36bfcc04e23ec6fa Content-Type: text/plain; charset=ISO-8859-1 Agree with Cullen - if there is a reasonable approach (such as retransmitting 180) that avoids PRACK, then we should use this approach. - Alan - On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) wrote: > > I prefer the 180 resend approach and all the right things are already > looking at them. I have always objected to mandating use of PRACK. > Obviously I'm fine with things that have PRACK can use it but I want some > solution for things that don't. > > One small note, the SDP in the 180 can change as long as the to-tag is > also changed. > > > > On Jul 3, 2013, at 8:13 AM, Emil Ivov wrote: > > > Hey all, > > > > Christer, Enrico and I are preparing the next version of Trickle ICE for > SIP. Now that discussions on BUNDLE and the plans seem to be winding down, > we wanted to run a few questions by the working group. > > > > Q1: Making reliable provisional responses and PRACK mandatory. Obviously > this would be nice to avoid, so the question is: is there a reasonable > mechanism to achieve this (and by reasonable, we mean something that > wouldn't be harder than implementing support for PRACK). > > > > There was some discussion about this back in April and there was a > suggestion for implementing a 5245-style hack where the answerer basically > resends the 180 until it knows that it has been received. > > > > 5245 uses connectivity checks for this (i.e. it stops 180 > retransmissions when the first connectivity check is received) but we don't > have that option here since the 180 may contain either none or only host > candidates so there are strong chances that no binding request would be > received on them. > > > > Thomas also suggested a second option which would be to also use INFO > requests with trickled candidates as an indication that 180 was received. > This however wouldn't work with half trickle so we are basically back to > vanilla ICE for all (non-re) INVITEs. > > > > Another option would be to mandate an INFO request with > "end-of-candidates" in response to the 180, but that would be just the same > as mandating PRACK support. > > > > Thomas also suggested that the answerer can start sending INFOs right > after it sends its answer in the 180 and then it can just resend the 180 if > the INFOs result in a 481 response. > > > > Personally I think this could potentially be made to work, but it would > imply a level of complexity that considerably exceeds PRACK support. > > > > Opinions? > > > > Q2: How do we send INFOs? Are they blocking or do we just send them in > parallel? If the latter, then what happens when an INFO fails because it is > received out of order? Do we just tell the application to resend the > candidates asap? > > > > This also leads to the following question: > > > > Q3: What exactly do we send in INFOs? Just the latest batch of freshly > learned candidates or all candidates we've learned so far? Dale suggested > that if we do this cumulatively we wouldn't need to worry about the case > with the out-of-order INFOs from Q2 since the information gets resent > anyway. A drawback here would obviously be that this adds more complexity > for trickle ICE users (WebRTC applications specifically) > > > > A third option would be to allow both and leave it to the application. > > > > Comments are most welcome! > > > > Emil > > > > -- > > https://jitsi.org > > _______________________________________________ > > 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 > --f46d043c815e36bfcc04e23ec6fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with Cullen - if there is a reasonable approach (suc= h as retransmitting 180) that avoids PRACK, then we should use this approac= h.

- Alan -

On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jenning= s (fluffy) <fluffy@cisco.com> wrote:

I prefer the 180 resend approach and all the right things are already looki= ng at them. =A0I have always objected to mandating use of PRACK. Obviously = I'm fine with things that have PRACK can use it but I want some solutio= n for things that don't.

One small note, the SDP in the 180 can change as long as the to-tag is also= changed.



On Jul 3, 2013, at 8:13 AM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey all,
>
> Christer, Enrico and I are preparing the next version of Trickle ICE f= or SIP. Now that discussions on BUNDLE and the plans seem to be winding dow= n, we wanted to run a few questions by the working group.
>
> Q1: Making reliable provisional responses and PRACK mandatory. Obvious= ly this would be nice to avoid, so the question is: is there a reasonable m= echanism to achieve this (and by reasonable, we mean something that wouldn&= #39;t be harder than implementing support for PRACK).
>
> There was some discussion about this back in April and there was a sug= gestion for implementing a 5245-style hack where the answerer basically res= ends the 180 until it knows that it has been received.
>
> 5245 uses connectivity checks for this (i.e. it stops 180 retransmissi= ons when the first connectivity check is received) but we don't have th= at option here since the 180 may contain either none or only host candidate= s so there are strong chances that no binding request would be received on = them.
>
> Thomas also suggested a second option which would be to also use INFO = requests with trickled candidates as an indication that 180 was received. T= his however wouldn't work with half trickle so we are basically back to= vanilla ICE for all (non-re) INVITEs.
>
> Another option would be to mandate an INFO request with "end-of-c= andidates" in response to the 180, but that would be just the same as = mandating PRACK support.
>
> Thomas also suggested that the answerer can start sending INFOs right = after it sends its answer in the 180 and then it can just resend the 180 if= the INFOs result in a 481 response.
>
> Personally I think this could potentially be made to work, but it woul= d imply a level of complexity that considerably exceeds PRACK support.
>
> Opinions?
>
> Q2: How do we send INFOs? Are they blocking or do we just send them in= parallel? If the latter, then what happens when an INFO fails because it i= s received out of order? Do we just tell the application to resend the cand= idates asap?
>
> This also leads to the following question:
>
> Q3: What exactly do we send in INFOs? Just the latest batch of freshly= learned candidates or all candidates we've learned so far? Dale sugges= ted that if we do this cumulatively we wouldn't need to worry about the= case with the out-of-order INFOs from Q2 since the information gets resent= anyway. A drawback here would obviously be that this adds more complexity = for trickle ICE users (WebRTC applications specifically)
>
> A third option would be to allow both and leave it to the application.=
>
> Comments are most welcome!
>
> Emil
>
> --
> https://jitsi.org<= br> > _______________________________________________
> 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

--f46d043c815e36bfcc04e23ec6fa-- From emil@sip-communicator.org Wed Jul 24 03:01: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 5E33111E839C for ; Wed, 24 Jul 2013 03:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 GpPbOZgOLc5v for ; Wed, 24 Jul 2013 03:01:10 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2511E8156 for ; Wed, 24 Jul 2013 03:01:05 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so3692248wes.32 for ; Wed, 24 Jul 2013 03:01:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=CuSLwpyVut/vXCd/dixXIn8vKHSpRNA2qZTYSPpDj0w=; b=GVBoBtr5qSgPbPS1gQ5h2DyetU4WbGrFyLa1u7WCuT5LyQUGgqr2rsKCTAT1CcLXEJ aH7Vuvspx8fDhVq4iXK21cY3oXIT+Q8cyX9avRlWUSWogflAStxv64a61MEn1qdH70K4 fYirB6x7iZicrKHNbJbR80zB3ltXDufaMTjf0jYyGYnhyRWial+b+bAmMceLHiemQDVk tKsldufiNzqC1ZE0mwZigwrXgdpdZru+QtEJ9QLaGdK/Dqgc8ZGovUtygJ5lQwBKOzF9 4qGCaPBnRmdgUKTbZJB9RWveTjKue6IIhVEWwaBKNOz149e08JF/7nXr87yENy39f98l b8IQ== X-Received: by 10.194.19.130 with SMTP id f2mr25766276wje.22.1374660063705; Wed, 24 Jul 2013 03:01:03 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:fdc6:f480:f605:7d26]) by mx.google.com with ESMTPSA id w4sm4024588wia.9.2013.07.24.03.01.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 03:01:02 -0700 (PDT) Message-ID: <51EFA5DD.3000805@jitsi.org> Date: Wed, 24 Jul 2013 12:01:01 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alan Johnston References: <51D43186.2010907@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmMKLYhVdQT5M9yUBYBgUK7JxDw2pbSDdavTl2ZhQFpUTULyN2cH1H/blOzWl/p7m0eFyIu Cc: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 10:01:14 -0000 Hey Alan, Cullen, On 24.07.13, 11:45, Alan Johnston wrote: > Agree with Cullen - if there is a reasonable approach (such as > retransmitting 180) that avoids PRACK, then we should use this approach. There is one and it comes down to requiring the remote side to send an INFO request as soon as it gets it. The INFO request could contain trickled candidates (in the case of full trickle) or just end-of-candidates (in the case of half-trickle). This could work and, personally, I have no issue with it. I believe the suggestion that Christer made was: given how the above basically works as a PRACK minus the O/A and given how the O/A in PRACKs seems to be a deal breaker for many, then we might want to generalize the above mechanism so that other specs can also use it. Cheers, Emil > - Alan - > > > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) > > wrote: > > > I prefer the 180 resend approach and all the right things are > already looking at them. I have always objected to mandating use of > PRACK. Obviously I'm fine with things that have PRACK can use it but > I want some solution for things that don't. > > One small note, the SDP in the 180 can change as long as the to-tag > is also changed. > > > > On Jul 3, 2013, at 8:13 AM, Emil Ivov > wrote: > > > Hey all, > > > > Christer, Enrico and I are preparing the next version of Trickle > ICE for SIP. Now that discussions on BUNDLE and the plans seem to be > winding down, we wanted to run a few questions by the working group. > > > > Q1: Making reliable provisional responses and PRACK mandatory. > Obviously this would be nice to avoid, so the question is: is there > a reasonable mechanism to achieve this (and by reasonable, we mean > something that wouldn't be harder than implementing support for PRACK). > > > > There was some discussion about this back in April and there was > a suggestion for implementing a 5245-style hack where the answerer > basically resends the 180 until it knows that it has been received. > > > > 5245 uses connectivity checks for this (i.e. it stops 180 > retransmissions when the first connectivity check is received) but > we don't have that option here since the 180 may contain either none > or only host candidates so there are strong chances that no binding > request would be received on them. > > > > Thomas also suggested a second option which would be to also use > INFO requests with trickled candidates as an indication that 180 was > received. This however wouldn't work with half trickle so we are > basically back to vanilla ICE for all (non-re) INVITEs. > > > > Another option would be to mandate an INFO request with > "end-of-candidates" in response to the 180, but that would be just > the same as mandating PRACK support. > > > > Thomas also suggested that the answerer can start sending INFOs > right after it sends its answer in the 180 and then it can just > resend the 180 if the INFOs result in a 481 response. > > > > Personally I think this could potentially be made to work, but it > would imply a level of complexity that considerably exceeds PRACK > support. > > > > Opinions? > > > > Q2: How do we send INFOs? Are they blocking or do we just send > them in parallel? If the latter, then what happens when an INFO > fails because it is received out of order? Do we just tell the > application to resend the candidates asap? > > > > This also leads to the following question: > > > > Q3: What exactly do we send in INFOs? Just the latest batch of > freshly learned candidates or all candidates we've learned so far? > Dale suggested that if we do this cumulatively we wouldn't need to > worry about the case with the out-of-order INFOs from Q2 since the > information gets resent anyway. A drawback here would obviously be > that this adds more complexity for trickle ICE users (WebRTC > applications specifically) > > > > A third option would be to allow both and leave it to the > application. > > > > Comments are most welcome! > > > > Emil > > > > -- > > https://jitsi.org > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Wed Jul 24 07:58:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7560021F9C37 for ; Wed, 24 Jul 2013 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.220, 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 HDjlKI6iLSFi for ; Wed, 24 Jul 2013 07:58:38 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 8B65D21F9D4C for ; Wed, 24 Jul 2013 07:57:57 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id 4Ahn1m0030mv7h05FExMFC; Wed, 24 Jul 2013 14:57:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 4ExM1m00L3ZTu2S3XExMAG; Wed, 24 Jul 2013 14:57:21 +0000 Message-ID: <51EFEB51.5020107@alum.mit.edu> Date: Wed, 24 Jul 2013 10:57:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF MMUSIC WG , Emil Ivov 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=1374677841; bh=hA0XkPkFVGHu6fj2lOHH2nzx1wCOh9RhYEUfKuBMLfY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rkT8JF31LJbk8xA5dEQV3M91TvURFFX5I5uJPB1LaRZGMW/Z25t4gmjKb6rEITibG sa6nA2SYhibEfmp3kkzMozjwJ0zpaOdoycq4Pc3nIv5lfLkt0v1z+1j/6OH0N6W6WY yDtttSMVa+hZGe8Ca5vacnnqK/cvmbCzs6lr9Tz9vo96tIUGq9UwmpI/alNyL9U4in fEXNlAuVgP0LbxStP10HIWRvyZHXVk8TQhJGjsTD9J11Y83C6BxCGRY/98j65OL8SO bEgoVrzzaJVtDzJpxb0uHFO2eMEX4t2BQZMxHaMHTIQsLCf66I8yeJnRrWK2rH4h3m my4jVc1wZHAdg== Subject: [MMUSIC] draft-ivov-mmusic-multiple-sources-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 Jul 2013 14:58:44 -0000 I have one question about this draft: Section 2.1 says: Unless an endpoint detects the corresponding max-ssrc or upper level protocol indicators that a remote peer can actually handle multiple streams within a single "m=" line, it MUST assume that such support is unavailable. But the example in section 2 only uses max-ssrc for video, not audio. Does that mean that only one audio stream should be used in the example? Thanks, Paul From emil@sip-communicator.org Wed Jul 24 08:03: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 DBEF111E8142 for ; Wed, 24 Jul 2013 08:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 I6VnfrTqvpWg for ; Wed, 24 Jul 2013 08:03:52 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id EE51F11E81DD for ; Wed, 24 Jul 2013 08:03:39 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so517430wgh.17 for ; Wed, 24 Jul 2013 08:02:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=mKOW0crlgbL9g5qq+IBWcgYXXRI1UQKZ/n0tBnZNx5k=; b=ALlVEFK2ZtX/abuhwpoua2LkLKX9lL8TEW6UuNR8XR9Sg6C1i1tvbs6LwPhFcuOvdq JVUhibmxF30q2ugj86qjOOuBW5+HXLBp5S3Sx0HeVghhXm8ZgrfQ6aFPaatbSz0XW9eD UMKirOv6krOEi1a650GvCBEmlP4QLyqCs1udd8hf9wDMrRqHxt+Yb2L34Qk3vYKWt5hE IeZWjvWBmN5lcOV5+DiAVYesW+CWGN9xorpCfIigP5rl2naPceCeDczQv/ZAKCLbjZPr RuhP28WyD/OS26JpHtZ9RmGG3V8FcRqZOiBGE6vKDOfOQzhX1qASeXJ3fNu6noSfxmHe 3CDQ== X-Received: by 10.180.11.6 with SMTP id m6mr5688098wib.0.1374678178277; Wed, 24 Jul 2013 08:02:58 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:380d:4ea3:f10b:7b17]) by mx.google.com with ESMTPSA id eu1sm5880032wib.8.2013.07.24.08.02.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 08:02:57 -0700 (PDT) Message-ID: <51EFEC9F.40006@jitsi.org> Date: Wed, 24 Jul 2013 17:02:55 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51EFEB51.5020107@alum.mit.edu> In-Reply-To: <51EFEB51.5020107@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm/gVF0iopnWBibyAs+FkrVhP0u/+SOnHfyq8rXjRWjfk2Zuk0bzsDgJPmEnBd4J4sMj53F Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ivov-mmusic-multiple-sources-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 Jul 2013 15:03:57 -0000 On 24.07.13, 16:57, Paul Kyzivat wrote: > I have one question about this draft: > > Section 2.1 says: > > Unless an endpoint detects the corresponding max-ssrc or upper level > protocol indicators that a remote peer can actually handle multiple > streams within a single "m=" line, it MUST assume that such support > is unavailable. > > But the example in section 2 only uses max-ssrc for video, not audio. > Does that mean that only one audio stream should be used in the example? Good question. The lack of max-ssrc for audio was not intentional but I think it would be legal and it would indeed mean that a maximum of one SSRC is allowed for that "m=" line. Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Wed Jul 24 08:55: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 4B69011E8101 for ; Wed, 24 Jul 2013 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=0.202, 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 forORdL7xhZU for ; Wed, 24 Jul 2013 08:55:15 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA311E80AE for ; Wed, 24 Jul 2013 08:55:13 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id 4BHE1m0020Fqzac5AFvDeP; Wed, 24 Jul 2013 15:55:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 4FvC1m01H3ZTu2S3UFvC2R; Wed, 24 Jul 2013 15:55:13 +0000 Message-ID: <51EFF8E0.6010203@alum.mit.edu> Date: Wed, 24 Jul 2013 11:55:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF MMUSIC WG , Adam Roach 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=1374681313; bh=CEcFrZVyqT23rlP2+q6zwaYCpkdpV7ET8AmVyHSPu1g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LvVQAl2BGIj7ZKQBJFngpUxfWOdvuB0eGi2DpxIWcuaVyxcPssBusa32VAy9ZBFj+ /4SKZ6f9kjAQ29aaKRz9s36Dpqz2j7EvXQlUK4yPc/s9QgPBwNfKIO3MUbd3zTe9RU m4ygwv+gZyn2T+kcqYhFksC0ytDrZQIyCrkxG+71/MuYyy7g2TdYtX9y1rjDstPbCE 4kCRJjQ26aWCguBtpxFYVDmbujhzCm26IgWRUVzN55eW3E+YLaFynUxkthhUpDJjEA bWDUjj9ekfRHlktRlQVtrj0Rv2Pb/FxBdwasZsFfyyq8xis3UhPy/ywt0rDdg22tDj 7+K9dsMnnB70Q== Subject: [MMUSIC] draft-roach-mmusic-unified-plan-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 Jul 2013 15:55:22 -0000 Some comments after carefully rereading this draft: Section 3.2.1 says: A different problem can arise when interoperating with legacy equipment. A number of circumstances can lead to the inability of a legacy endpoint to include SSRC information in its SDP. For example, in a system that decomposes signaling and media into different network devices, the protocol used to communicate between the boxes frequently will not include SSRC information, making it impossible to include in the SDP. If these devices choose to implement bundling, correlation of media streams to m-lines requires an alternate correlator. These cases (and possibly other similar situations) can be ameliorated by using information in the media stream itself as a correlator to the SDP offer. If a packet arrives with an SSRC that is not yet associated with an m-line, we would ideally have some means of correlating it prior to the arrival of the answer. The authors reiterate and emphasize that this technique is used solely for the purposes of correlation of an RTP stream to an SDP m-line after that stream has already been demultiplexed. Demultiplexing of multiple streams on a single transport address continues to be based on SSRC values. This suggests that it is only a problem with legacy devices, but I think that is not so. E.g., media can outrun the answer in all cases. It also seems to exclude the possibility that in some cases we might *want* a particular SSRC to be associated with different m-lines over time. This is a case that actually comes up in CLUE: We have an MCU that is providing multiple capture-encodings to a consumer for rendering. I think that with the unified plan CLUE would map a capture-encoding (conceptually similar to a media stream track) to an m-line, and that this would then be rendered to a particular device or window. But the captures being delivered by the MCU may be "switched". For instance, one capture-encoding might represent the image of the loudest speaker, and another an image of the 2nd loudest speaker. When a particular speaker moves from being loudest speaker to 2nd loudest, the MCU will want to move the SSRC for the image of that speaker from one capture-encoding to another - and hence from one m-line to another. This seems to be excluded, except by sending a new O/A every time the speaker switches, which isn't feasible. If this means that CLUE can't represent capture-encodings as m-lines, then there is no benefit to CLUE for the unified plan over No Plan (Emil's multiple-sources draft). Section 3.2.2/3.2.3: IMO the primary justification for the various multiple-m-line approaches is that then one can presume to first associate a packet to an m-line, and then transitively associate all the attributes of that m-line with that packet. What you describe here is a special case of that. The unified plan has a spin on this. You preferentially use the SSRC to associate a packet to an m-line, and only use other properties of a packet if the SSRC-m-line association isn't yet known. But as mentioned above, that is a limitation. Section 3.3: This falls back to dependency on signaling specific SSRCs. I don't see how the other correlation mechanisms mentioned earlier can be employed with these features. That can mean confusion for media received before the answer. Thanks, Paul From adam@nostrum.com Wed Jul 24 09:03: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 D7A8511E812A for ; Wed, 24 Jul 2013 09:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 d4lXzEzTiPSi for ; Wed, 24 Jul 2013 09:03:33 -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 3F53F11E80DF for ; Wed, 24 Jul 2013 09:03:33 -0700 (PDT) Received: from orochi-2.roach.at (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 r6OG3UiU071898 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 11:03:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EFFACD.7040905@nostrum.com> Date: Wed, 24 Jul 2013 11:03:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51EFF8E0.6010203@alum.mit.edu> In-Reply-To: <51EFF8E0.6010203@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-roach-mmusic-unified-plan-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 Jul 2013 16:03:34 -0000 On 7/24/13 10:55, Paul Kyzivat wrote: > This seems to be excluded, except by sending a new O/A every time the > speaker switches, which isn't feasible. If this means that CLUE can't > represent capture-encodings as m-lines, then there is no benefit to > CLUE for the unified plan over No Plan (Emil's multiple-sources draft). That's interesting. I wonder whether we should simply move to the RTP header extension described in section 3.2.1.1 as the primary means of correlation. It would seem to address the case you describe. /a From emil@sip-communicator.org Wed Jul 24 09:09: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 DEC2911E812A for ; Wed, 24 Jul 2013 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_15=0.6, 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 46e52XVUTzf5 for ; Wed, 24 Jul 2013 09:09:52 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5C21F848E for ; Wed, 24 Jul 2013 09:09:51 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so1792315wev.22 for ; Wed, 24 Jul 2013 09:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=nhh6SELKvZOP3Mh86LHNPIHlYtusETJmoFHbfL3BUNg=; b=HD1z3gmsVrtrsbcbFt5E5KvwfHPhAUivpkafwu7FSeIGFr6iuqGpPYOpOs97G2jx6h aGpNNNC0gstLYs5r36Wdm216gakkep8hapv5IpNHDq/yXGT4scmdimSrkGhvoVy9/gD8 HFpBWRZFUs7wORYep3CaIi5on+gJhun/c/QJbEQMe/n5xYAvQ9qhs6fD+3PGPCGrboCQ lYMY/xlhuZ9f086uxIf7qcp6gRTmJGdVhWsCbrS5u9AD6p2LDS4FGsN5GqQg9/PxBPhO zk0S9tjhrjhxxOvi+g+yxjdvffP3Eeg/bwwfjJYmAhfL0qEz+VnFfcXPv0xL7FUY+GQO 54hA== X-Received: by 10.194.63.46 with SMTP id d14mr28018813wjs.81.1374682189723; Wed, 24 Jul 2013 09:09:49 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:380d:4ea3:f10b:7b17]) by mx.google.com with ESMTPSA id i1sm6303387wiz.6.2013.07.24.09.09.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:09:48 -0700 (PDT) Message-ID: <51EFFC49.80305@jitsi.org> Date: Wed, 24 Jul 2013 18:09:45 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl0GVam2wkPph+LUzdLCW8iR1XvG5RzOyUouqieRUPdQs4w/C9/D/2xOFJb9d0q6s2Pkp2u Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 16:09:57 -0000 (redirecting to mmusic) On 24.07.13, 16:29, Eric Rescorla wrote: > > > > On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo > wrote: > > Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, an= d > my browser receives a session invitation from a conference server, = and > there are 8 audio participants in the conference. > > So the SDP I receive has 8 "m=3Daudio" lines, maybe with different = audio > codecs in each line. And following SDP O/A rules my browser will > generate SDP answer that will also contain 8 "m=3Daudio" lines. > > Now, where it is supposed my browser will send my single audio trac= k > to the conference server? What does it mean that I receive 8 "m=3Da= udio" > lines while I'm just able to send a single audio track? which m=3Da= udio > line should I use for sending RTP? > > > One of them will be a=3Dsendrecv. The others will be a=3Dsendonly. > The sendrecv line is the one you use to send media. I have a few questions here but before that, could you please clarify=20 the following: Are you saying that the above is going to be the case on the offer that=20 the callee receives? In other words, the caller "knew" that the callee=20 intended to only send one stream so it preset all directions accordingly?= Emil --=20 https://jitsi.org From partha@parthasarathi.co.in Wed Jul 24 09: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 CD3CD11E824D for ; Wed, 24 Jul 2013 09:56:02 -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 rM8FTOpLkBPS for ; Wed, 24 Jul 2013 09:55:54 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2B85521F85EB for ; Wed, 24 Jul 2013 09:55:18 -0700 (PDT) Received: from userPC (unknown [122.172.183.104]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 3A7AA868516; Wed, 24 Jul 2013 16:55:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374684916; bh=m20QrY/PugXqrpmydpkqyCWuzl+foHIszwCwamQublw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RXyxjavn7AwCD7HHiAE5F9XavlsqMqt/wwS6tJ9+QrIEAPYr8ujbwYVDPzT+MOaZk TP/2ZepcZ1jF5XQcE7rZ8avP2kmaCGYtdgezkFV+w2vkXUWOfqQ3xglZJz78MvBPfJ HC1w8ROvFwxheCDoivXdH0QCRtXBQE7/dL0HGD0Q= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Alan Johnston'" References: <51D43186.2010907@jitsi.org> <51EFA5DD.3000805@jitsi.org> In-Reply-To: <51EFA5DD.3000805@jitsi.org> Date: Wed, 24 Jul 2013 22:25:05 +0530 Message-ID: <014f01ce888e$90aec730$b20c5590$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6IVL9kKxufjhnySUWgBp7dmYko2AAOOWjg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51F006F4.004C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.153 Cc: "'Cullen Jennings \(fluffy\)'" , 'MMUSIC IETF WG' Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 16:56:27 -0000 Hi Emil, As Cullen suggested in case 180 with different to-tag is used by UAS then INFO package itself is not required right? Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Wednesday, July 24, 2013 3:31 PM > To: Alan Johnston > Cc: Cullen Jennings (fluffy); MMUSIC IETF WG > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > Hey Alan, Cullen, > > On 24.07.13, 11:45, Alan Johnston wrote: > > Agree with Cullen - if there is a reasonable approach (such as > > retransmitting 180) that avoids PRACK, then we should use this > approach. > > There is one and it comes down to requiring the remote side to send an > INFO request as soon as it gets it. The INFO request could contain > trickled candidates (in the case of full trickle) or just > end-of-candidates (in the case of half-trickle). > > This could work and, personally, I have no issue with it. > > I believe the suggestion that Christer made was: given how the above > basically works as a PRACK minus the O/A and given how the O/A in > PRACKs > seems to be a deal breaker for many, then we might want to generalize > the above mechanism so that other specs can also use it. > > Cheers, > Emil > > > > - Alan - > > > > > > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) > > > wrote: > > > > > > I prefer the 180 resend approach and all the right things are > > already looking at them. I have always objected to mandating use > of > > PRACK. Obviously I'm fine with things that have PRACK can use it > but > > I want some solution for things that don't. > > > > One small note, the SDP in the 180 can change as long as the to- > tag > > is also changed. > > > > > > > > On Jul 3, 2013, at 8:13 AM, Emil Ivov > > wrote: > > > > > Hey all, > > > > > > Christer, Enrico and I are preparing the next version of > Trickle > > ICE for SIP. Now that discussions on BUNDLE and the plans seem to > be > > winding down, we wanted to run a few questions by the working > group. > > > > > > Q1: Making reliable provisional responses and PRACK mandatory. > > Obviously this would be nice to avoid, so the question is: is > there > > a reasonable mechanism to achieve this (and by reasonable, we > mean > > something that wouldn't be harder than implementing support for > PRACK). > > > > > > There was some discussion about this back in April and there > was > > a suggestion for implementing a 5245-style hack where the > answerer > > basically resends the 180 until it knows that it has been > received. > > > > > > 5245 uses connectivity checks for this (i.e. it stops 180 > > retransmissions when the first connectivity check is received) > but > > we don't have that option here since the 180 may contain either > none > > or only host candidates so there are strong chances that no > binding > > request would be received on them. > > > > > > Thomas also suggested a second option which would be to also > use > > INFO requests with trickled candidates as an indication that 180 > was > > received. This however wouldn't work with half trickle so we are > > basically back to vanilla ICE for all (non-re) INVITEs. > > > > > > Another option would be to mandate an INFO request with > > "end-of-candidates" in response to the 180, but that would be > just > > the same as mandating PRACK support. > > > > > > Thomas also suggested that the answerer can start sending > INFOs > > right after it sends its answer in the 180 and then it can just > > resend the 180 if the INFOs result in a 481 response. > > > > > > Personally I think this could potentially be made to work, but > it > > would imply a level of complexity that considerably exceeds PRACK > > support. > > > > > > Opinions? > > > > > > Q2: How do we send INFOs? Are they blocking or do we just send > > them in parallel? If the latter, then what happens when an INFO > > fails because it is received out of order? Do we just tell the > > application to resend the candidates asap? > > > > > > This also leads to the following question: > > > > > > Q3: What exactly do we send in INFOs? Just the latest batch of > > freshly learned candidates or all candidates we've learned so > far? > > Dale suggested that if we do this cumulatively we wouldn't need > to > > worry about the case with the out-of-order INFOs from Q2 since > the > > information gets resent anyway. A drawback here would obviously > be > > that this adds more complexity for trickle ICE users (WebRTC > > applications specifically) > > > > > > A third option would be to allow both and leave it to the > > application. > > > > > > Comments are most welcome! > > > > > > Emil > > > > > > -- > > > https://jitsi.org > > > _______________________________________________ > > > 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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From suhasietf@gmail.com Wed Jul 24 11:14: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 145FD11E8110 for ; Wed, 24 Jul 2013 11:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 mGcdeqnSpiC4 for ; Wed, 24 Jul 2013 11:14:38 -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 A6D0C11E8125 for ; Wed, 24 Jul 2013 11:14:37 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so741933wgh.30 for ; Wed, 24 Jul 2013 11:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WhkWZWLOd3/ktWj51dF/oQspYGxslQ/FjSfsYtW8GNA=; b=EuMjyTZvtVz8MvoP0EYl4OEjtflpVDUjZtyL1uXHj1bh95pCCyr2RPa5R7bho5Ekse Z3LCASNALMHR+SG8qW86XhhzK608b65k6w2zV4t1/0BeNBXdvQK6A7XjWme5qZ0cP7e8 5/wwdStIcjoIkmFKCnuYLfFkqwIpfyp4dvwJ5XwZnw9FNJDAwUF7laeHvgc8pI4FbF2C UCB4lhW4VisuJyYwEBIeB4UEas8Y4kMCV/D37cP4UUb/Pw2xKErb4l7JjGFXQWk6k/6p dPX2hswuzk+6rRePQCsqL2q5bWjZfBsnWcoBCQ4cpLlnfMFu2jLRrIMCI2q5PqfdvSnu ZkEw== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr28215695wjc.30.1374689676776; Wed, 24 Jul 2013 11:14:36 -0700 (PDT) Received: by 10.194.9.9 with HTTP; Wed, 24 Jul 2013 11:14:36 -0700 (PDT) In-Reply-To: <51EFFC49.80305@jitsi.org> References: <51EFFC49.80305@jitsi.org> Date: Wed, 24 Jul 2013 11:14:36 -0700 Message-ID: From: Suhas Nandakumar To: Emil Ivov Content-Type: multipart/alternative; boundary=089e0122f0fedc706604e245e18a Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 18:14:39 -0000 --089e0122f0fedc706604e245e18a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Offerer has all sendrecv , the answerer has one sendrecv (since he can send only one audio track) and rest recvonly so the answerer is ok to receive all the audio tracks sent by the offerer, and he is sending only one from his side (marked as sendrecv) On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov wrote: > (redirecting to mmusic) > > > On 24.07.13, 16:29, Eric Rescorla wrote: > >> >> >> >> On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo > > wrote: >> >> Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, and >> my browser receives a session invitation from a conference server, a= nd >> there are 8 audio participants in the conference. >> >> So the SDP I receive has 8 "m=3Daudio" lines, maybe with different a= udio >> codecs in each line. And following SDP O/A rules my browser will >> generate SDP answer that will also contain 8 "m=3Daudio" lines. >> >> Now, where it is supposed my browser will send my single audio track >> to the conference server? What does it mean that I receive 8 "m=3Dau= dio" >> lines while I'm just able to send a single audio track? which m=3Dau= dio >> line should I use for sending RTP? >> >> >> One of them will be a=3Dsendrecv. The others will be a=3Dsendonly. >> The sendrecv line is the one you use to send media. >> > > I have a few questions here but before that, could you please clarify the > following: > > Are you saying that the above is going to be the case on the offer that > the callee receives? In other words, the caller "knew" that the callee > intended to only send one stream so it preset all directions accordingly? > > Emil > > > > -- > https://jitsi.org > > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --089e0122f0fedc706604e245e18a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Offerer has all sendrecv , the answerer has one sendrecv (since he can send= only one audio track) and rest recvonly

so the answerer= is ok to receive all the audio tracks sent by the offerer, and he is sendi= ng only one from his side (marked as sendrecv)


On Wed, Jul 24, 2013 at = 9:09 AM, Emil Ivov <emcho@jitsi.org> wrote:
(redirecting to mmusic)


On 24.07.13, 16:29, Eric Rescorla wrote:



On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo <ibc@aliax.net
<mailto:ibc@aliax.net= >> wrote:

=A0 =A0 Hi, let's suppose WebRTC 1.0 borns with "Unified Plan"= ; built-in, and
=A0 =A0 my browser receives a session invitation from a conference server, = and
=A0 =A0 there are 8 audio participants in the conference.

=A0 =A0 So the SDP I receive has 8 "m=3Daudio" lines, maybe with = different audio
=A0 =A0 codecs in each line. And following SDP O/A rules my browser will =A0 =A0 generate SDP answer that will also contain 8 "m=3Daudio" = lines.

=A0 =A0 Now, where it is supposed my browser will send my single audio trac= k
=A0 =A0 to the conference server? What does it mean that I receive 8 "= m=3Daudio"
=A0 =A0 lines while I'm just able to send a single audio track? which m= =3Daudio
=A0 =A0 line should I use for sending RTP?


One of them will be a=3Dsendrecv. The others will be a=3Dsendonly.
The sendrecv line is the one you use to send media.

I have a few questions here but before that, could you please clarify the f= ollowing:

Are you saying that the above is going to be the case on the offer that the= callee receives? In other words, the caller "knew" that the call= ee intended to only send one stream so it preset all directions accordingly= ?

Emil



--
https://jitsi.org

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

--089e0122f0fedc706604e245e18a-- From vimandav@cisco.com Wed Jul 24 11:22: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 32F7D11E8221 for ; Wed, 24 Jul 2013 11:22:47 -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 hKuUMhpCqbHE for ; Wed, 24 Jul 2013 11:22:42 -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 1A79111E8258 for ; Wed, 24 Jul 2013 11:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6499; q=dns/txt; s=iport; t=1374690156; x=1375899756; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f1LCrcLZUxXrfHzx/tuIhsyHLxmzMUPC/Qevt9zd0Ms=; b=kzGkWf7YH5CIA0y36k7AvJ/kt+4Y3DCOuO9XapoJv22ep5F3OUHwQUgN dc/A0iM4Z8ovm5sA6op2L00J9CLbF175yf6RC+kX9kPH4IZitDNToB3Cq 5/MWhVW2huSmnceJ6Qt+EgWI87wpgEwDnGiznXGimQetXbouNmS0Enjzg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAC8a8FGtJV2Y/2dsb2JhbABagwY1UL1jgRYWdIIkAQEBBAEBATc0CwwGAQgRBAEBAQoUCS4LFAkIAgQBDQUIE4d1DLkRBI49gQ8xBwaDDG4DlAiVJIMUgio X-IronPort-AV: E=Sophos;i="4.89,736,1367971200"; d="scan'208";a="238945592" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2013 18:22:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6OIMMeJ030251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 18:22:22 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.216]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 13:22:22 -0500 From: "Vijaya Mandava (vimandav)" To: Parthasarathi R , "'Emil Ivov'" , "'Alan Johnston'" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSaLa5Hh3VhE64hO3afq874plzn7gAgABpUQCAAARAgIAAc7CA///VUwA= Date: Wed, 24 Jul 2013 18:22:21 +0000 Message-ID: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> In-Reply-To: <014f01ce888e$90aec730$b20c5590$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.173.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DC9BC94B5D68945B4F9F6F4C7C14575@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , 'MMUSIC IETF WG' Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 18:22:47 -0000 180 with different to-tag would mean call is forked. If uac side do not support call forking, then we cannot use this 180 response to collect trickled candidates. As Emil said, I think INFO is the right way to go here. Thanks, Vijaya On 7/24/13 12:55 PM, "Parthasarathi R" wrote: >Hi Emil, > >As Cullen suggested in case 180 with different to-tag is used by UAS then >INFO package itself is not required right? > >Thanks >Partha > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Emil Ivov >> Sent: Wednesday, July 24, 2013 3:31 PM >> To: Alan Johnston >> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >>=20 >> Hey Alan, Cullen, >>=20 >> On 24.07.13, 11:45, Alan Johnston wrote: >> > Agree with Cullen - if there is a reasonable approach (such as >> > retransmitting 180) that avoids PRACK, then we should use this >> approach. >>=20 >> There is one and it comes down to requiring the remote side to send an >> INFO request as soon as it gets it. The INFO request could contain >> trickled candidates (in the case of full trickle) or just >> end-of-candidates (in the case of half-trickle). >>=20 >> This could work and, personally, I have no issue with it. >>=20 >> I believe the suggestion that Christer made was: given how the above >> basically works as a PRACK minus the O/A and given how the O/A in >> PRACKs >> seems to be a deal breaker for many, then we might want to generalize >> the above mechanism so that other specs can also use it. >>=20 >> Cheers, >> Emil >>=20 >>=20 >> > - Alan - >> > >> > >> > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) >> > > wrote: >> > >> > >> > I prefer the 180 resend approach and all the right things are >> > already looking at them. I have always objected to mandating use >> of >> > PRACK. Obviously I'm fine with things that have PRACK can use it >> but >> > I want some solution for things that don't. >> > >> > One small note, the SDP in the 180 can change as long as the to- >> tag >> > is also changed. >> > >> > >> > >> > On Jul 3, 2013, at 8:13 AM, Emil Ivov > > > wrote: >> > >> > > Hey all, >> > > >> > > Christer, Enrico and I are preparing the next version of >> Trickle >> > ICE for SIP. Now that discussions on BUNDLE and the plans seem to >> be >> > winding down, we wanted to run a few questions by the working >> group. >> > > >> > > Q1: Making reliable provisional responses and PRACK mandatory. >> > Obviously this would be nice to avoid, so the question is: is >> there >> > a reasonable mechanism to achieve this (and by reasonable, we >> mean >> > something that wouldn't be harder than implementing support for >> PRACK). >> > > >> > > There was some discussion about this back in April and there >> was >> > a suggestion for implementing a 5245-style hack where the >> answerer >> > basically resends the 180 until it knows that it has been >> received. >> > > >> > > 5245 uses connectivity checks for this (i.e. it stops 180 >> > retransmissions when the first connectivity check is received) >> but >> > we don't have that option here since the 180 may contain either >> none >> > or only host candidates so there are strong chances that no >> binding >> > request would be received on them. >> > > >> > > Thomas also suggested a second option which would be to also >> use >> > INFO requests with trickled candidates as an indication that 180 >> was >> > received. This however wouldn't work with half trickle so we are >> > basically back to vanilla ICE for all (non-re) INVITEs. >> > > >> > > Another option would be to mandate an INFO request with >> > "end-of-candidates" in response to the 180, but that would be >> just >> > the same as mandating PRACK support. >> > > >> > > Thomas also suggested that the answerer can start sending >> INFOs >> > right after it sends its answer in the 180 and then it can just >> > resend the 180 if the INFOs result in a 481 response. >> > > >> > > Personally I think this could potentially be made to work, but >> it >> > would imply a level of complexity that considerably exceeds PRACK >> > support. >> > > >> > > Opinions? >> > > >> > > Q2: How do we send INFOs? Are they blocking or do we just send >> > them in parallel? If the latter, then what happens when an INFO >> > fails because it is received out of order? Do we just tell the >> > application to resend the candidates asap? >> > > >> > > This also leads to the following question: >> > > >> > > Q3: What exactly do we send in INFOs? Just the latest batch of >> > freshly learned candidates or all candidates we've learned so >> far? >> > Dale suggested that if we do this cumulatively we wouldn't need >> to >> > worry about the case with the out-of-order INFOs from Q2 since >> the >> > information gets resent anyway. A drawback here would obviously >> be >> > that this adds more complexity for trickle ICE users (WebRTC >> > applications specifically) >> > > >> > > A third option would be to allow both and leave it to the >> > application. >> > > >> > > Comments are most welcome! >> > > >> > > Emil >> > > >> > > -- >> > > https://jitsi.org >> > > _______________________________________________ >> > > mmusic mailing list >> > > mmusic@ietf.org >> > > https://www.ietf.org/mailman/listinfo/mmusic >> > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> > >> > >>=20 >> -- >> https://jitsi.org >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From ekr@rtfm.com Wed Jul 24 11:31: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 3DE2811E8236 for ; Wed, 24 Jul 2013 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 AIL80xyJzAOJ for ; Wed, 24 Jul 2013 11:31:52 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id E19A011E8258 for ; Wed, 24 Jul 2013 11:31:43 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so120856qab.4 for ; Wed, 24 Jul 2013 11:31:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=+1/GY9TFk5Kc37Nf87V9M0PQAERTF6SxPbvn8a+ee3k=; b=Op2ICOWRX8J89vWo+mV7NCH9InTgjS3f16UWulsi9JCn/61Bpbjpssh7fP44s+uTek sClYAvJBfFp2gdnG3DVlnNgHf/R2s+cPsanx62y0fzAfkRlvyRRm2nesZoeJcqRUQpgs pgA1Pzfk3mCXF5wQHN8TU08K+8pzkFrSQBo+Yz6mE9sEz2JCjYe5IZr+O2XnpTQdjegR J/8LTcaYHdVPKoe0wolA9UedpLlIXuw8DTs1cb9x00toVinqF4X6VbnmgUgRlsLS8Fgq yMLmUH+IEM5ZDa/6lZ+YWFjpBffX3RWTiCfO/sJg69K5xyuBD+9mulSQlYJhGkJRTBzg 3VBg== X-Received: by 10.224.4.202 with SMTP id 10mr46550348qas.1.1374690702090; Wed, 24 Jul 2013 11:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 24 Jul 2013 11:31:01 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <51EFFC49.80305@jitsi.org> References: <51EFFC49.80305@jitsi.org> From: Eric Rescorla Date: Wed, 24 Jul 2013 11:31:01 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c20dfef9733004e2461e62 X-Gm-Message-State: ALoCoQmrskGD/ssY4KNEyL8oOCpA4+PHQIpk2DFuNkOiY4ZTyZVJ6ZVm/hOoPa3ay6SzelVGaU7O Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 18:31:58 -0000 --001a11c20dfef9733004e2461e62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov wrote: > (redirecting to mmusic) > > > On 24.07.13, 16:29, Eric Rescorla wrote: > >> >> >> >> On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo > > wrote: >> >> Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, and >> my browser receives a session invitation from a conference server, a= nd >> there are 8 audio participants in the conference. >> >> So the SDP I receive has 8 "m=3Daudio" lines, maybe with different a= udio >> codecs in each line. And following SDP O/A rules my browser will >> generate SDP answer that will also contain 8 "m=3Daudio" lines. >> >> Now, where it is supposed my browser will send my single audio track >> to the conference server? What does it mean that I receive 8 "m=3Dau= dio" >> lines while I'm just able to send a single audio track? which m=3Dau= dio >> line should I use for sending RTP? >> >> >> One of them will be a=3Dsendrecv. The others will be a=3Dsendonly. >> The sendrecv line is the one you use to send media. >> > > I have a few questions here but before that, could you please clarify the > following: > > Are you saying that the above is going to be the case on the offer that > the callee receives? In other words, the caller "knew" that the callee > intended to only send one stream so it preset all directions accordingly? It depends on the context obviously. But in the case of (for instance) a Hangouts like system if the conference bridge were the offerer, it would send a pile of m-lines with only one being sendrecv (or maybe even recvonly) for the user's media and the rest being sendonly. -Ekr --001a11c20dfef9733004e2461e62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov <emcho@jitsi.org><= /span> wrote:
(redirecting to mmusic)

On 24.07.13, 16:29, Eric Rescorla wrote:



On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo <ibc@aliax.net
<mailto:ibc@aliax.net= >> wrote:

=A0 =A0 Hi, let's suppose WebRTC 1.0 borns with "Unified Plan"= ; built-in, and
=A0 =A0 my browser receives a session invitation from a conference server, = and
=A0 =A0 there are 8 audio participants in the conference.

=A0 =A0 So the SDP I receive has 8 "m=3Daudio" lines, maybe with = different audio
=A0 =A0 codecs in each line. And following SDP O/A rules my browser will =A0 =A0 generate SDP answer that will also contain 8 "m=3Daudio" = lines.

=A0 =A0 Now, where it is supposed my browser will send my single audio trac= k
=A0 =A0 to the conference server? What does it mean that I receive 8 "= m=3Daudio"
=A0 =A0 lines while I'm just able to send a single audio track? which m= =3Daudio
=A0 =A0 line should I use for sending RTP?


One of them will be a=3Dsendrecv. The others will be a=3Dsendonly.
The sendrecv line is the one you use to send media.

I have a few questions here but before that, could you please clarify the f= ollowing:

Are you saying that the above is going to be the case on the offer that the= callee receives? In other words, the caller "knew" that the call= ee intended to only send one stream so it preset all directions accordingly= ?

It depends on the context obviously. But in the case of= (for instance) a Hangouts
like system if the conference bridge w= ere the offerer, it would send a pile of
m-lines with only one be= ing sendrecv (or maybe even recvonly) for the
user's media and the rest being sendonly.

-Ekr

--001a11c20dfef9733004e2461e62-- From christer.holmberg@ericsson.com Wed Jul 24 12:47: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 8360911E821B for ; Wed, 24 Jul 2013 12:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.028, 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 s8KE1Ng08Dmb for ; Wed, 24 Jul 2013 12:47:04 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 467E611E820E for ; Wed, 24 Jul 2013 12:47:03 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-d2-51f02f367729 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E7.FB.19388.63F20F15; Wed, 24 Jul 2013 21:47:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 21:47:01 +0200 From: Christer Holmberg To: "Vijaya Mandava (vimandav)" , Parthasarathi R , 'Emil Ivov' , 'Alan Johnston' Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlzKl8AgABpUQCAAARAgIAAc7GAgAAYYYCAADkwJg== Date: Wed, 24 Jul 2013 19:47:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C405F55@ESESSMB209.ericsson.se> References: <014f01ce888e$90aec730$b20c5590$@co.in>, <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> In-Reply-To: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C405F55ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvra6Z/odAgxWTJSxmtrayWKzZOYHF omMym8XU5Y9ZLCZ/6mO1aJ52gsWBzWPK742sHjtn3WX3WLLkJ5PH/zeBHh/mf2EPYI3isklJ zcksSy3St0vgyni0aBVrweLFjBW328+xNDDO7WDsYuTgkBAwkbj8L7WLkRPIFJO4cG89Wxcj F4eQwGFGib+H7zFDOEsYJVZ8fMEG0sAmYCHR/U8bJC4isIlR4uvtc8wg3cwC4RKTH81jB7GF BYwlHh5rZAKpFwFa8PqKG4QZJtF/LhGkgkVAVaJjUT8biM0r4Ctxr7UTbIqQQJHEqgWLwKZw CnhL3Hz4kgXEZgS67fupNUwQm8Qlbj2ZzwRxs4DEkj3nmSFsUYmXj/+xQtTkS0y9uYEJYr6g xMmZT1gmMIrMQtI+C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUje25iZk56 ufkmRmD0Hdzy22AH46b7YocYpTlYlMR5N+udCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA KN7Z/GfLhCOW55dXWFvJnXPV6GpoEdq32WFDzvtYpnJeBo24nOZu/V1RXNxPxea95NimeILt eH61QL5G1RXF1L4Z58z4Gz9mSuotna7z/KIB2537v59O3vOosOumVfybC1W53lONs3KWJ01e LHBQt//HkuDZxkJB0fqf3z+eeLc2/0RH4wQmJZbijERDLeai4kQAWvtZYYwCAAA= Cc: "Cullen Jennings \(fluffy\)" , 'MMUSIC IETF WG' Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 19:47:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C405F55ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Keep in mind that, no matter if we use PRACK, PRACK-lite, INFO, or simply r= e-transmission, the SDP can not change from one 180 to another (for the sam= e To tag, that is). Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Vijaya Mandava (vimandav) [vimandav@cisco.com] To: Parthasarathi R [partha@parthasarathi.co.in]; 'Emil Ivov' [em= cho@jitsi.org]; 'Alan Johnston' [alan.b.johnston@gmail.com] CC: Cullen Jennings (fluffy) [fluffy@cisco.com]; 'MMUSIC IETF WG'= [mmusic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions 180 with different to-tag would mean call is forked. If uac side do not support call forking, then we cannot use this 180 response to collect trickled candidates. As Emil said, I think INFO is the right way to go here. Thanks, Vijaya On 7/24/13 12:55 PM, "Parthasarathi R" wrote: >Hi Emil, > >As Cullen suggested in case 180 with different to-tag is used by UAS then >INFO package itself is not required right? > >Thanks >Partha > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Emil Ivov >> Sent: Wednesday, July 24, 2013 3:31 PM >> To: Alan Johnston >> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >> >> Hey Alan, Cullen, >> >> On 24.07.13, 11:45, Alan Johnston wrote: >> > Agree with Cullen - if there is a reasonable approach (such as >> > retransmitting 180) that avoids PRACK, then we should use this >> approach. >> >> There is one and it comes down to requiring the remote side to send an >> INFO request as soon as it gets it. The INFO request could contain >> trickled candidates (in the case of full trickle) or just >> end-of-candidates (in the case of half-trickle). >> >> This could work and, personally, I have no issue with it. >> >> I believe the suggestion that Christer made was: given how the above >> basically works as a PRACK minus the O/A and given how the O/A in >> PRACKs >> seems to be a deal breaker for many, then we might want to generalize >> the above mechanism so that other specs can also use it. >> >> Cheers, >> Emil >> >> >> > - Alan - >> > >> > >> > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) >> > > wrote: >> > >> > >> > I prefer the 180 resend approach and all the right things are >> > already looking at them. I have always objected to mandating use >> of >> > PRACK. Obviously I'm fine with things that have PRACK can use it >> but >> > I want some solution for things that don't. >> > >> > One small note, the SDP in the 180 can change as long as the to- >> tag >> > is also changed. >> > >> > >> > >> > On Jul 3, 2013, at 8:13 AM, Emil Ivov > > > wrote: >> > >> > > Hey all, >> > > >> > > Christer, Enrico and I are preparing the next version of >> Trickle >> > ICE for SIP. Now that discussions on BUNDLE and the plans seem to >> be >> > winding down, we wanted to run a few questions by the working >> group. >> > > >> > > Q1: Making reliable provisional responses and PRACK mandatory. >> > Obviously this would be nice to avoid, so the question is: is >> there >> > a reasonable mechanism to achieve this (and by reasonable, we >> mean >> > something that wouldn't be harder than implementing support for >> PRACK). >> > > >> > > There was some discussion about this back in April and there >> was >> > a suggestion for implementing a 5245-style hack where the >> answerer >> > basically resends the 180 until it knows that it has been >> received. >> > > >> > > 5245 uses connectivity checks for this (i.e. it stops 180 >> > retransmissions when the first connectivity check is received) >> but >> > we don't have that option here since the 180 may contain either >> none >> > or only host candidates so there are strong chances that no >> binding >> > request would be received on them. >> > > >> > > Thomas also suggested a second option which would be to also >> use >> > INFO requests with trickled candidates as an indication that 180 >> was >> > received. This however wouldn't work with half trickle so we are >> > basically back to vanilla ICE for all (non-re) INVITEs. >> > > >> > > Another option would be to mandate an INFO request with >> > "end-of-candidates" in response to the 180, but that would be >> just >> > the same as mandating PRACK support. >> > > >> > > Thomas also suggested that the answerer can start sending >> INFOs >> > right after it sends its answer in the 180 and then it can just >> > resend the 180 if the INFOs result in a 481 response. >> > > >> > > Personally I think this could potentially be made to work, but >> it >> > would imply a level of complexity that considerably exceeds PRACK >> > support. >> > > >> > > Opinions? >> > > >> > > Q2: How do we send INFOs? Are they blocking or do we just send >> > them in parallel? If the latter, then what happens when an INFO >> > fails because it is received out of order? Do we just tell the >> > application to resend the candidates asap? >> > > >> > > This also leads to the following question: >> > > >> > > Q3: What exactly do we send in INFOs? Just the latest batch of >> > freshly learned candidates or all candidates we've learned so >> far? >> > Dale suggested that if we do this cumulatively we wouldn't need >> to >> > worry about the case with the out-of-order INFOs from Q2 since >> the >> > information gets resent anyway. A drawback here would obviously >> be >> > that this adds more complexity for trickle ICE users (WebRTC >> > applications specifically) >> > > >> > > A third option would be to allow both and leave it to the >> > application. >> > > >> > > Comments are most welcome! >> > > >> > > Emil >> > > >> > > -- >> > > https://jitsi.org >> > > _______________________________________________ >> > > 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 >> _______________________________________________ >> 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 --_000_7594FB04B1934943A5C02806D1A2204B1C405F55ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Keep in mind that, no matter if we use PRACK, P= RACK-lite, INFO, or simply re-transmission, the SDP can not change from one= 180 to another (for the same To tag, that is).
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Vijaya Mandava (vimandav) [vimandav@cisco.com]
To: Parthasarathi R [partha@parthasarathi.co.in]; &apos;Emil Ivo= v&apos; [emcho@jitsi.org]; &apos;Alan Johnston&apos; [alan.b.jo= hnston@gmail.com]
CC: Cullen Jennings (fluffy) [fluffy@cisco.com]; &apos;MMUSIC IE= TF WG&apos; [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
180 with different to-tag would mean call is forke= d.
If uac side do not support call forking, then we cannot use this 180
response to collect trickled candidates.

As Emil said, I think INFO is the right way to go here.

Thanks,
Vijaya

On 7/24/13 12:55 PM, "Parthasarathi R" <partha@parthasarathi.c= o.in> wrote:

>Hi Emil,
>
>As Cullen suggested in case 180 with different to-tag is used by UAS th= en
>INFO package itself is not required right?
>
>Thanks
>Partha
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Emil Ivov
>> Sent: Wednesday, July 24, 2013 3:31 PM
>> To: Alan Johnston
>> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG
>> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
>>
>> Hey Alan, Cullen,
>>
>> On 24.07.13, 11:45, Alan Johnston wrote:
>> > Agree with Cullen - if there is a reasonable approach (such a= s
>> > retransmitting 180) that avoids PRACK, then we should use thi= s
>> approach.
>>
>> There is one and it comes down to requiring the remote side to sen= d an
>> INFO request as soon as it gets it. The INFO request could contain=
>> trickled candidates (in the case of full trickle) or just
>> end-of-candidates (in the case of half-trickle).
>>
>> This could work and, personally, I have no issue with it.
>>
>> I believe the suggestion that Christer made was: given how the abo= ve
>> basically works as a PRACK minus the O/A and given how the O/A in<= br> >> PRACKs
>> seems to be a deal breaker for many, then we might want to general= ize
>> the above mechanism so that other specs can also use it.
>>
>> Cheers,
>> Emil
>>
>>
>> > - Alan -
>> >
>> >
>> > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) >> > <fluffy@cisco.com <= mailto:fluffy@cisco.com>> wrote:
>> >
>> >
>> >     I prefer the 180 resend approach and = all the right things are
>> >     already looking at them.  I have= always objected to mandating use
>> of
>> >     PRACK. Obviously I'm fine with things= that have PRACK can use it
>> but
>> >     I want some solution for things that = don't.
>> >
>> >     One small note, the SDP in the 180 ca= n change as long as the to-
>> tag
>> >     is also changed.
>> >
>> >
>> >
>> >     On Jul 3, 2013, at 8:13 AM, Emil Ivov= <emcho@jitsi.org
>> >     <mailto:emcho@jitsi.org>> wrote:
>> >
>> >      > Hey all,
>> >      >
>> >      > Christer, Enrico and I are= preparing the next version of
>> Trickle
>> >     ICE for SIP. Now that discussions on = BUNDLE and the plans seem to
>> be
>> >     winding down, we wanted to run a few = questions by the working
>> group.
>> >      >
>> >      > Q1: Making reliable provis= ional responses and PRACK mandatory.
>> >     Obviously this would be nice to avoid= , so the question is: is
>> there
>> >     a reasonable mechanism to achieve thi= s (and by reasonable, we
>> mean
>> >     something that wouldn't be harder tha= n implementing support for
>> PRACK).
>> >      >
>> >      > There was some discussion = about this back in April and there
>> was
>> >     a suggestion for implementing a 5245-= style hack where the
>> answerer
>> >     basically resends the 180 until it kn= ows that it has been
>> received.
>> >      >
>> >      > 5245 uses connectivity che= cks for this (i.e. it stops 180
>> >     retransmissions when the first connec= tivity check is received)
>> but
>> >     we don't have that option here since = the 180 may contain either
>> none
>> >     or only host candidates so there are = strong chances that no
>> binding
>> >     request would be received on them. >> >      >
>> >      > Thomas also suggested a se= cond option which would be to also
>> use
>> >     INFO requests with trickled candidate= s as an indication that 180
>> was
>> >     received. This however wouldn't work = with half trickle so we are
>> >     basically back to vanilla ICE for all= (non-re) INVITEs.
>> >      >
>> >      > Another option would be to= mandate an INFO request with
>> >     "end-of-candidates" in resp= onse to the 180, but that would be
>> just
>> >     the same as mandating PRACK support.<= br> >> >      >
>> >      > Thomas also suggested that= the answerer can start sending
>> INFOs
>> >     right after it sends its answer in th= e 180 and then it can just
>> >     resend the 180 if the INFOs result in= a 481 response.
>> >      >
>> >      > Personally I think this co= uld potentially be made to work, but
>> it
>> >     would imply a level of complexity tha= t considerably exceeds PRACK
>> >     support.
>> >      >
>> >      > Opinions?
>> >      >
>> >      > Q2: How do we send INFOs? = Are they blocking or do we just send
>> >     them in parallel? If the latter, then= what happens when an INFO
>> >     fails because it is received out of o= rder? Do we just tell the
>> >     application to resend the candidates = asap?
>> >      >
>> >      > This also leads to the fol= lowing question:
>> >      >
>> >      > Q3: What exactly do we sen= d in INFOs? Just the latest batch of
>> >     freshly learned candidates or all can= didates we've learned so
>> far?
>> >     Dale suggested that if we do this cum= ulatively we wouldn't need
>> to
>> >     worry about the case with the out-of-= order INFOs from Q2 since
>> the
>> >     information gets resent anyway. A dra= wback here would obviously
>> be
>> >     that this adds more complexity for tr= ickle ICE users (WebRTC
>> >     applications specifically)
>> >      >
>> >      > A third option would be to= allow both and leave it to the
>> >     application.
>> >      >
>> >      > Comments are most welcome!=
>> >      >
>> >      > Emil
>> >      >
>> >      > --
>> >      > https://jitsi.org
>> >      > __________________________= _____________________
>> >      > mmusic mailing list
>> >      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>> >      > https://www.ietf.org/mailman/listinfo/mmusic=
>> >
>> >     _____________________________________= __________
>> >     mmusic mailing list
>> >     mmusic@ietf.org <mailto:mmusic@ietf.org>
>> >     https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> >
>>
>> --
>> https://jitsi.org
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ie= tf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C405F55ESESSMB209erics_-- From fluffy@cisco.com Wed Jul 24 12:56:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01121F847C for ; Wed, 24 Jul 2013 12:56:25 -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 9uI6OHBQfxgz for ; Wed, 24 Jul 2013 12:56:20 -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 BE61821F841B for ; Wed, 24 Jul 2013 12:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=328; q=dns/txt; s=iport; t=1374695780; x=1375905380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AvjYwY5iHEXVIhR5fBnPaP9ey1xRxdYER86DZAUr84A=; b=mmg7mPuFOmFKQZShdU3HrBkllSG4QpDls7LvD33hd/lo0jsS/1hTvim8 p1xWJPcKbj6FKAA0eJIJ0ORH3pELL3KnCuoRAnt3FSJkOezkuMMPkJKdw iJkb/y8M2YBluFQlH8yLLdr41z+N8dOLdBUU3AX6WL8akUlDetzGrCGxn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAHYw8FGtJXHA/2dsb2JhbABagwZ5DIJCuyWBFhZ0giQBAQEDATo/BQsCAQgiFBAyJQIEDgUIiAIGuW2PSgIxB4MSbgOpLIMUgio X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="238964669" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jul 2013 19:56:19 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6OJuJZs027223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 19:56:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 14:56:19 -0500 From: "Cullen Jennings (fluffy)" To: "Vijaya Mandava (vimandav)" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOiKfcSVOSvmOQIEyFWeTagsf8fQ== Date: Wed, 24 Jul 2013 19:56:17 +0000 Message-ID: References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> In-Reply-To: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alan Johnston , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 19:56:25 -0000 On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) wrote: > 180 with different to-tag would mean call is forked. > If uac side do not support call forking, then we cannot use this 180 > response to collect trickled candidates. If it is a UAC, it supports this so I don't see the problem. From christer.holmberg@ericsson.com Wed Jul 24 13:34: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 981E911E819B for ; Wed, 24 Jul 2013 13:34:48 -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.019, 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 JEBkEwOmgWUb for ; Wed, 24 Jul 2013 13:34:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 317AA11E8268 for ; Wed, 24 Jul 2013 13:34:40 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-5a-51f03a5e5f68 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.5D.05990.E5A30F15; Wed, 24 Jul 2013 22:34:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 22:34:38 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , "Vijaya Mandava (vimandav)" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlzKl8AgABpUQCAAARAgIAAc7GAgAAYYYCAABo/gIAALD5g Date: Wed, 24 Jul 2013 20:34:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4083B4@ESESSMB209.ericsson.se> References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4083B4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvrW6c1YdAg78LjSxmtrayWHRMZrOY uvwxi0XztBMsDiweU35vZPXYOesuu8eSJT+ZApijuGxSUnMyy1KL9O0SuDLaO1+yFMyUrph3 bSVzA+Mj8S5GTg4JAROJu5c/M0PYYhIX7q1nA7GFBA4zShy8E9nFyAVkL2GUeLXgHFARBweb gIVE9z9tEFNEIFXi7CEzkHJmgUCJ4+d/MILYwgLGEg+PNTJBlJhIvL7iBhIWEYiSeL7iFjuI zSKgKrHv0S6wrbwCvhKdq28yQWzqZpR4dP8eC0iCEyhx4f4csAZGoNO+n1rDBLFLXOLWk/lM ECcLSCzZcx7qfFGJl4//sULU5Eu8eH2PDWKBoMTJmU9YJjCKzELSPgtJ2SwkZRBxHYkFuz+x QdjaEssWvmaGsc8ceMyELL6AkX0VI3tuYmZOernRJkZgTB3c8lt1B+OdcyKHGKU5WJTEeTfr nQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBhQaLvn00XTU/+MP0ddl4zrOV54rTbouO39 oikW4XVHEp/s279wQvV9wwuHO4M/an8+8Pd7XERXz7nFKpZOP+xDHcME7vCly0dXCmsxWfTe 4JkTGcb8pVfF8FuWd+b3d8G/nVhdWjZkFGvaJYYw2Z/4nVN8552ATJPzt1vfNG33n9wYc+lP hxJLcUaioRZzUXEiABuo5/p3AgAA Cc: Alan Johnston , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 20:34:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4083B4ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Wouldn't the UAC need to know that the 180s come from the same UAS? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Cullen Jennings (fluffy) [fluffy@cisco.com] To: Vijaya Mandava (vimandav) [vimandav@cisco.com] CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusic@ietf.= org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) wrote: > 180 with different to-tag would mean call is forked. > If uac side do not support call forking, then we cannot use this 180 > response to collect trickled candidates. If it is a UAC, it supports this so I don't see the problem. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C4083B4ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Wouldn't the UAC need to know that the 180s com= e from the same UAS?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Cullen Jennings (fluffy) [fluffy@cisco.com]
To: Vijaya Mandava (vimandav) [vimandav@cisco.com]
CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusi= c@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) <vimandav@cisco.= com> wrote:

> 180 with different to-tag would mean call is forked.
> If uac side do not support call forking, then we cannot use this 180 > response to collect trickled candidates.

If it is a UAC, it supports this so I don't see the problem.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C4083B4ESESSMB209erics_-- From emil@sip-communicator.org Wed Jul 24 13:49: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 233DE11E8137 for ; Wed, 24 Jul 2013 13:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 gTvRmwRmoHIz for ; Wed, 24 Jul 2013 13:49:18 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69211E8241 for ; Wed, 24 Jul 2013 13:49:16 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so4819456wes.16 for ; Wed, 24 Jul 2013 13:49:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=1xtRkDoy12mHZc6x9hvIMSBQirMwH5BhSsopEBGTVaY=; b=jRP5WMjAHkjtHwn05tkYXY7pJULqV7CuMWAYQujnUSLJ/MBp/YtJahQtitzQxo2S1m 4NbV2TEPIiZQmMTLwji4YtpKGlDAa7vClxkHekhJ6HMCyku4th9OfmZ7dBvRXbfnYCTU WYN5KtuZWAOj7bak4dmgE0PHCF4zwDmPywAxCxgHcKHQswK5FTEYi47D0eAzc6bMwE8a dH2YOc0+JhNe71KAyP5CF4R3us2LVLidwLLQaqEW85xr8O71I1wlZP67q9RNnCIFXv/9 McIBRs8L4AFqGuZuA5L1/ErYDFyusKLtavSNuRAhR1OycnlF0Kv/e5fmt9AHxosmZ51B xgEQ== X-Received: by 10.194.78.42 with SMTP id y10mr27717601wjw.93.1374698955412; Wed, 24 Jul 2013 13:49:15 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:dd4c:7a03:b3a7:c01c]) by mx.google.com with ESMTPSA id iz8sm7927545wic.3.2013.07.24.13.49.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:49:14 -0700 (PDT) Message-ID: <51F03DC8.70908@jitsi.org> Date: Wed, 24 Jul 2013 22:49:12 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm3KcRhGBRwcJiYZVjkDUW2UKZWoPnFkQLPvFAjxoaU7uewietTYnV3BQ1XeJLvytXL10Cr Cc: Alan Johnston , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 20:49:23 -0000 On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > > On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) wrote: > >> 180 with different to-tag would mean call is forked. >> If uac side do not support call forking, then we cannot use this 180 >> response to collect trickled candidates. > > If it is a UAC, it supports this so I don't see the problem. One problem is that the UAC could support it to the extent of making it visible to the user: "Your contact is being alerted on these N locations" And of course there's also the fact that we would be creating several dialogs per call, that we'd then need to clean and garbage collect. Why would we want to go there? Emil -- https://jitsi.org From christer.holmberg@ericsson.com Wed Jul 24 13:58: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 370E411E8240 for ; Wed, 24 Jul 2013 13:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.014, 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 Kh1MDdvv-3pC for ; Wed, 24 Jul 2013 13:57:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A671811E80FF for ; Wed, 24 Jul 2013 13:57:32 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-9f-51f03fb7d3a2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 60.BE.19388.7BF30F15; Wed, 24 Jul 2013 22:57:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 22:57:27 +0200 From: Christer Holmberg To: Emil Ivov , "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlzKl8AgABpUQCAAARAgIAAc7GAgAAYYYCAABo/gIAADskAgAAj1ag= Date: Wed, 24 Jul 2013 20:57:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C408585@ESESSMB209.ericsson.se> References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> , <51F03DC8.70908@jitsi.org> In-Reply-To: <51F03DC8.70908@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C408585ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre52+w+BBi8OG1nMbG1lsVizcwKL RcdkNoupyx+zOLB4TPm9kdVj56y77B5Llvxk8vj/JjCAJYrLJiU1J7MstUjfLoEr4/yc/6wF vUoVl+4uY29gnCvbxcjJISFgInH0dys7hC0mceHeerYuRi4OIYHDjBILd15lgnCWMEp8XdEP VMXBwSZgIdH9TxukQUTAT6Jp4k5mEJtZIFDi+PkfjCC2sICxxMNjjUwg5SJAC15fcYMoT5K4 PeMjWDmLgKpE1/5dbCA2r4CvRM/W26wQq1YwSmxrvQd2EKeAusTW2W/BZjICHff91BomiF3i EreezGeCOFpAYsme88wQtqjEy8f/WCFq8iUWPVnPBLFAUOLkzCcsExhFZiFpn4WkbBaSMoi4 jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdx8EyMwvg5u+W2wg3HTfbFDjNIc LErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHRhYH0z18jOtqL2luKVkmePT+vu nK649Siz2kSpiVoqaQ1ajbv7Q9PYXm++s6HgTkPMlInNAffnZcY21HwpsWL/YXl7wtpc2Z8m T5w3lE7NlGB8K5MsFC4RwB48xUrmVcIWzpua+3KWLjmjGXzumWHQ4q7kI/ULKrxesL63+rgi ZtOs/plHq5RYijMSDbWYi4oTAWbwywB9AgAA Cc: Alan Johnston , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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 Jul 2013 20:58:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C408585ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a very nice, easy and lightweight mechanism for cleaning: 199 :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Emil Ivov [emcho@jitsi.org] To: Cullen Jennings (fluffy) [fluffy@cisco.com] CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusic@ietf.= org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > > On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) wrote: > >> 180 with different to-tag would mean call is forked. >> If uac side do not support call forking, then we cannot use this 180 >> response to collect trickled candidates. > > If it is a UAC, it supports this so I don't see the problem. One problem is that the UAC could support it to the extent of making it visible to the user: "Your contact is being alerted on these N locations" And of course there's also the fact that we would be creating several dialogs per call, that we'd then need to clean and garbage collect. Why would we want to go there? Emil -- https://jitsi.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C408585ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is a very nice, easy and lightweight mecha= nism for cleaning: 199 :)
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [emcho@jitsi.org]
To: Cullen Jennings (fluffy) [fluffy@cisco.com]
CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusi= c@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions


On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote:
>
> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) <vimandav@c= isco.com> wrote:
>
>> 180 with different to-tag would mean call is forked.
>> If uac side do not support call forking, then we cannot use this 1= 80
>> response to collect trickled candidates.
>
> If it is a UAC, it supports this so I don't see the problem.

One problem is that the UAC could support it to the extent of making it visible to the user:

   "Your contact is being alerted on these N locations"=

And of course there's also the fact that we would be creating several
dialogs per call, that we'd then need to clean and garbage collect.

Why would we want to go there?

Emil

--
https://jitsi.org
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C408585ESESSMB209erics_-- From pkyzivat@alum.mit.edu Wed Jul 24 14:01: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 98E3211E811E for ; Wed, 24 Jul 2013 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, 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 enzmSh+LrPcE for ; Wed, 24 Jul 2013 14:01:29 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5519411E810B for ; Wed, 24 Jul 2013 14:01:29 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id 4Lg51m0090cZkys5FM1Uw1; Wed, 24 Jul 2013 21:01:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 4M1U1m00H3ZTu2S3WM1UCG; Wed, 24 Jul 2013 21:01:28 +0000 Message-ID: <51F040A8.6010807@alum.mit.edu> Date: Wed, 24 Jul 2013 17:01:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF MMUSIC WG , "Christer.Holmberg@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=1374699688; bh=5E3Z4FVFJ65CJu8mFL5qL7aLH2ufjN+kqTrLuNtwU/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=foP+Mxbk7ggmeH5UWjr2kduU6pNX3swo4o5ue3kcPh+uAdy+F9DfJ22JQsQ5lqpF3 gG0skUBd9ldbhOdbKjgbUxfLS00vOV8Z/BORi1SLrBcQgtzz61meJWzvkLAPL/nCvt MmtHYjSuOaY/Mjb2gdqKWbZlXOXR4F+vBW2Hp9UI5lndq5HS3yy+Pin8b+PCvqC2Ly ldaJSt+S5/9l3+3mueS1LxiopVAm1eh/f0aCEjZ7cvkEI/e3r3prpX7ickEMUL9DU0 ci7sf39QDZv5mzUG8cpilFUF5lhmPf0xfSXZ9OhZEfm39S2fMWX5T/d88gEuJ4SMRs 1rEz9YmNtWfXQ== Subject: [MMUSIC] 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 Jul 2013 21:01:36 -0000 Christer, Here are some points I encountered while reviewing this version in prep for the meeting: I trust that the requirement for identical c= values may be met by putting one c= at session level. Might be good to say that somewhere. It ought to be obvious, but some people make strange assumptions when things aren't explicit. Open Issue #1: AFAIK grouping semantics requires the answer to include the same, or a subset, of the mids in the offer. So I think the only question here is whether it can be a subset. IMO the answer to that is YES, it can be a subset. Some may be dropped due to having been refused (port zero), and others just because there is a desire to have those particular ones unbundled. Open Issue #2: I don't understand the issue. Why is this any different? Just follow the rules for establishing a new bundle. Open Issue #3: Why not? Of course will need to supply a unique addr/port for each m-line, but that is nothing special. I also see no reason why you can't retain the bundle while assigning unique addr/port to each m-line, thus restarting the bundle negotiation. While I don't know why you might want to do that I see no reason to forbid it. (One reason to do that might be a 3pcc transfer.) Section 6.3 should mention the possibility of accepting the bundle but omitting some of the m-lines from it. Thanks, Paul From emil@sip-communicator.org Wed Jul 24 14:17: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 A268B11E80F5 for ; Wed, 24 Jul 2013 14:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_66=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 3WM2W6sMD+4A for ; Wed, 24 Jul 2013 14:17:45 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id CBFEA11E80FF for ; Wed, 24 Jul 2013 14:17:44 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so2625803wes.35 for ; Wed, 24 Jul 2013 14:17:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=x834L0pvmAQwaMj/i9h9LIv79Asm/zFSnYKH7OQnPQs=; b=C6cMqYRirB3ah3qDYtOCuZNtZ3fU6+Z940fKrjPU4GRpJC5oUu3zTYemuWdBU/LjeA z0oj3UkBz3J2oqChEm1AoArLEsX8XPe3gDV+L4NP+iFs0WWbd0SYDFTnYUOIAGSvBNQi Rmy+gMiOTO3ttqeBDg540EXDsvejXda1pbjuRGJ+YxyllMYXzvDiImayMOqZW3chfESj DBBG8cu/Xo826zEGYciCLd73KvRZ5BlKoL/LMs8G3S8cJ2Xc0uablFCo8fhjAIpvdHJJ w5+Nws+q+9IH7sUIJmgbiCoQt/0RDIHvpZL/BggIN6Zgkhns1v0oACXuSFsqYV3goVLJ ivNw== X-Received: by 10.194.81.39 with SMTP id w7mr6765889wjx.51.1374700662439; Wed, 24 Jul 2013 14:17:42 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:dd4c:7a03:b3a7:c01c]) by mx.google.com with ESMTPSA id s19sm8030822wik.11.2013.07.24.14.17.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 14:17:41 -0700 (PDT) Message-ID: <51F04473.5020401@jitsi.org> Date: Wed, 24 Jul 2013 23:17:39 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eric Rescorla References: <51EFFC49.80305@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQka4ft4j3mj5TpiB/OnokDoTzIB6QBSKnmWtBtxzRjW+SnDF0kh0EtYnURlGZYDZRrfSsgR Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 21:17:50 -0000 On 24.07.13, 20:31, Eric Rescorla wrote: > > > > On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov > wrote: > > (redirecting to mmusic) > > > On 24.07.13, 16:29, Eric Rescorla wrote: > > > > > On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo > > >> wrote: > > Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" > built-in, and > my browser receives a session invitation from a conference= > server, and > there are 8 audio participants in the conference. > > So the SDP I receive has 8 "m=3Daudio" lines, maybe with > different audio > codecs in each line. And following SDP O/A rules my browse= r > will > generate SDP answer that will also contain 8 "m=3Daudio" l= ines. > > Now, where it is supposed my browser will send my single > audio track > to the conference server? What does it mean that I receive= > 8 "m=3Daudio" > lines while I'm just able to send a single audio track? > which m=3Daudio > line should I use for sending RTP? > > > One of them will be a=3Dsendrecv. The others will be a=3Dsendon= ly. > The sendrecv line is the one you use to send media. > > > I have a few questions here but before that, could you please > clarify the following: > > Are you saying that the above is going to be the case on the offer > that the callee receives? In other words, the caller "knew" that th= e > callee intended to only send one stream so it preset all directions= > accordingly? > > > It depends on the context obviously. But in the case of (for instance) = a > Hangouts > like system if the conference bridge were the offerer, it would send a > pile of > m-lines with only one being sendrecv (or maybe even recvonly) for the > user's media and the rest being sendonly. Sorry, I am still not getting it. How does it know exactly how many "m=3D= "=20 lines to place in a=3Dsendrecv? How does it know if the callee is plannin= g=20 on sending a webcam, or two, or webcam+slides? Or maybe 8 other streams=20 because the callee turns out to be another MCU? When you say that this depends on the context, do you mean that it has=20 to be hardcoded/pre-provisioned or handled by app-specific signalling? Emil --=20 https://jitsi.org From adam@nostrum.com Wed Jul 24 14:27: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 493BD11E811E for ; Wed, 24 Jul 2013 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, 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 U6G1rwNou4Mo for ; Wed, 24 Jul 2013 14:27:16 -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 BAC6211E8100 for ; Wed, 24 Jul 2013 14:27:16 -0700 (PDT) Received: from orochi-2.roach.at (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 r6OLRAlQ008909 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 16:27:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51F046A9.5010207@nostrum.com> Date: Wed, 24 Jul 2013 16:27:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> In-Reply-To: <51F04473.5020401@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 21:27:17 -0000 On 7/24/13 16:17, Emil Ivov wrote: > > > On 24.07.13, 20:31, Eric Rescorla wrote: >> >> It depends on the context obviously. But in the case of (for instance) a >> Hangouts >> like system if the conference bridge were the offerer, it would send a >> pile of >> m-lines with only one being sendrecv (or maybe even recvonly) for the >> user's media and the rest being sendonly. > > Sorry, I am still not getting it. How does it know exactly how many > "m=" lines to place in a=sendrecv? I think you need to re-read and meditate on section 5.1 of RFC 3264. This stuff is actually pretty well defined, and I'm not sure having an on-list tutorial is ideal. Your follow-up questions are likely answered in section 6.1 of that same document. /a From christer.holmberg@ericsson.com Wed Jul 24 14:43: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 7997F11E81DD for ; Wed, 24 Jul 2013 14:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.013, 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 j-cUlGgBw6cb for ; Wed, 24 Jul 2013 14:43:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DBE4A11E810B for ; Wed, 24 Jul 2013 14:43:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-9e-51f04a89bc5a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3A.B4.00725.98A40F15; Wed, 24 Jul 2013 23:43:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 23:43:37 +0200 From: Christer Holmberg To: Paul Kyzivat , IETF MMUSIC WG Thread-Topic: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: AQHOiLD4FmHb/5mzNECSzAe1zBPGZ5l0XFMO Date: Wed, 24 Jul 2013 21:43:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C408670@ESESSMB209.ericsson.se> References: <51F040A8.6010807@alum.mit.edu> In-Reply-To: <51F040A8.6010807@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C408670ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW6X14dAg64/LBZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxum8bU8FrrYo1dzYxNzB+Vu5i5OSQEDCR 6Prcywphi0lcuLeerYuRi0NI4DCjxO/FfawQzhJGifO7djB1MXJwsAlYSHT/0wZpEBHwkjjx 9zQbiC0MFL5y7hIjRNxSYvHh31C2kcT1o50sIDaLgKrElPkt7CA2r4CvRMPu+WC9QgLaEh8e XmIGsTkFdCQWr/zDBGIzAh30/dQaMJtZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rRE2+xNyT LYwQ8wUlTs58wjKBUXgWkvZZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyr GNlzEzNz0ssNNzECY+Tglt+6OxhPnRM5xCjNwaIkzrtJ70ygkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkbR81Jhwu+Zv/P0rXsrvfiaNYfo7eiEDMVHxteyuydY/+F9VTmzKTk9UHdZyvPN k93VdkcFvP59yNMhb8Jmz3PPP8xnumX17uY/bQXr9p1M6yay5pufZ43oKnC83HprOrPXqYjV pvGtk7oYY/SeFh1+4vWp6U1vcvCuE/mpdT5nHd89W/43dJkSS3FGoqEWc1FxIgCwqxKcXwIA AA== Subject: Re: [MMUSIC] 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 Jul 2013 21:43:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C408670ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, I will look at your e-mail later, but I just want to make sure it is based = on version -04, as the subject refers to -03 :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: IETF MMUSIC WG [mmusic@ietf.org]; Christer Holmberg [christer.holmberg@= ericsson.com] Subject: draft-ietf-mmusic-sdp-bundle-negotiation-03 Christer, Here are some points I encountered while reviewing this version in prep for the meeting: I trust that the requirement for identical c=3D values may be met by putting one c=3D at session level. Might be good to say that somewhere. It ought to be obvious, but some people make strange assumptions when things aren't explicit. Open Issue #1: AFAIK grouping semantics requires the answer to include the same, or a subset, of the mids in the offer. So I think the only question here is whether it can be a subset. IMO the answer to that is YES, it can be a subset. Some may be dropped due to having been refused (port zero), and others just because there is a desire to have those particular ones unbundled. Open Issue #2: I don't understand the issue. Why is this any different? Just follow the rules for establishing a new bundle. Open Issue #3: Why not? Of course will need to supply a unique addr/port for each m-line, but that is nothing special. I also see no reason why you can't retain the bundle while assigning unique addr/port to each m-line, thus restarting the bundle negotiation. While I don't know why you might want to do that I see no reason to forbid it. (One reason to do that might be a 3pcc transfer.) Section 6.3 should mention the possibility of accepting the bundle but omitting some of the m-lines from it. Thanks, Paul --_000_7594FB04B1934943A5C02806D1A2204B1C408670ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Paul,
 
I will look at your e-mail later, but I just wa= nt to make sure it is based on version -04, as the subject refers to -03 :)=
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: IETF MMUSIC WG [mmusic@ietf.org]; Christer Holmberg [christer.ho= lmberg@ericsson.com]
Subject: draft-ietf-mmusic-sdp-bundle-negotiation-03
Christer,

Here are some points I encountered while reviewing this version in prep for the meeting:

I trust that the requirement for identical c=3D values may be met by
putting one c=3D at session level. Might be good to say that somewhere. It =
ought to be obvious, but some people make strange assumptions when
things aren't explicit.

Open Issue #1: AFAIK grouping semantics requires the answer to include
the same, or a subset, of the mids in the offer. So I think the only
question here is whether it can be a subset. IMO the answer to that is
YES, it can be a subset. Some may be dropped due to having been refused (port zero), and others just because there is a desire to have those
particular ones unbundled.

Open Issue #2: I don't understand the issue. Why is this any different? Just follow the rules for establishing a new bundle.

Open Issue #3: Why not? Of course will need to supply a unique addr/port for each m-line, but that is nothing special. I also see no reason why
you can't retain the bundle while assigning unique addr/port to each
m-line, thus restarting the bundle negotiation. While I don't know why
you might want to do that I see no reason to forbid it. (One reason to
do that might be a 3pcc transfer.)

Section 6.3 should mention the possibility of accepting the bundle but
omitting some of the m-lines from it.

        Thanks,
        Paul
 --_000_7594FB04B1934943A5C02806D1A2204B1C408670ESESSMB209erics_-- From pkyzivat@alum.mit.edu Wed Jul 24 14:48: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 39A3D11E8213 for ; Wed, 24 Jul 2013 14:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=0.173, 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 ZBkwYHJKt2st for ; Wed, 24 Jul 2013 14:48:36 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 256C811E80E1 for ; Wed, 24 Jul 2013 14:48:35 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id 4CUu1m0051YDfWL54MobxF; Wed, 24 Jul 2013 21:48:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 4Mob1m00A3ZTu2S3gMobHa; Wed, 24 Jul 2013 21:48:35 +0000 Message-ID: <51F04BB2.1060903@alum.mit.edu> Date: Wed, 24 Jul 2013 17:48:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51F040A8.6010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408670@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C408670@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=1374702515; bh=k6vOcUjs3LqjrDyKIHhuncsqJYUA3Hq3ZzdVHj4GqUg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mWiCLibXMeLKb8U8PwaWxm5NQmhnf//UUx85D4VKUZEkTlCWyUTlWmAy0qVHBARCR tPILTwOuwLPbD5wthUcb3NNGj/j1/bSHpwYSybAvOmQk8i4MWXZEnn9pfaGcDTtIBD eunRMk9+3wEeu2+wBqM6JibCihWiZRH4O/pLMzxLh/VhJ5dViVDvH28+6gMkTAc19y 9udVuGeWgthtTQ/Ne9tchg/VG0fvtzxvTqPddI8SuHZE2zeJW5jsKMJ/YxeK13otw9 TVWu1n6cfaZWpWGEGI/7FKoAh8AJ8+nl2aqSY5YqD/tOM20OQ+UDxI9WidHXrS3Lf3 cluylnjKv3nLA== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] 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 Jul 2013 21:48:41 -0000 On 7/24/13 5:43 PM, Christer Holmberg wrote: > Hi Paul, > I will look at your e-mail later, but I just want to make sure it is > based on version -04, as the subject refers to -03 :) Sorry. Yes, I reviewed -04 and just gave the wrong number. I was looking at a diff, and probably copied the number from the wrong pane. Sorry, Paul > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *To:* IETF MMUSIC WG [mmusic@ietf.org]; Christer Holmberg > [christer.holmberg@ericsson.com] > *Subject:* draft-ietf-mmusic-sdp-bundle-negotiation-03 > Christer, > > Here are some points I encountered while reviewing this version in prep > for the meeting: > > I trust that the requirement for identical c= values may be met by > putting one c= at session level. Might be good to say that somewhere. It > ought to be obvious, but some people make strange assumptions when > things aren't explicit. > > Open Issue #1: AFAIK grouping semantics requires the answer to include > the same, or a subset, of the mids in the offer. So I think the only > question here is whether it can be a subset. IMO the answer to that is > YES, it can be a subset. Some may be dropped due to having been refused > (port zero), and others just because there is a desire to have those > particular ones unbundled. > > Open Issue #2: I don't understand the issue. Why is this any different? > Just follow the rules for establishing a new bundle. > > Open Issue #3: Why not? Of course will need to supply a unique addr/port > for each m-line, but that is nothing special. I also see no reason why > you can't retain the bundle while assigning unique addr/port to each > m-line, thus restarting the bundle negotiation. While I don't know why > you might want to do that I see no reason to forbid it. (One reason to > do that might be a 3pcc transfer.) > > Section 6.3 should mention the possibility of accepting the bundle but > omitting some of the m-lines from it. > > Thanks, > Paul From emil@sip-communicator.org Wed Jul 24 15:01: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 6352A11E8253 for ; Wed, 24 Jul 2013 15:01:42 -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 OZev1aGwhG6S for ; Wed, 24 Jul 2013 15:01:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9717D11E815E for ; Wed, 24 Jul 2013 15:01:36 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so4862653wiw.17 for ; Wed, 24 Jul 2013 15:01:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=268cTpDn4WGQavRO7t+oRYPzfnHzh5ROzeLqvQVrY9U=; b=TvfV2bMe7/krgCKqyoelMPRDCKdSOn1s2VEB9H9+7XJlA5JUehVYIBhhi0PrIgYxum cXT7v7ngnjnUSiso2inoT/ILyumoDumn0H+NdT8AoqUdEFCBZmIGoA6BYow1cltRDKfM UzdPt2nvo4rOLJt1pYoo0mTG/6ug4xyIQu/0bpkEsKkF6niZ9wXdSyKi/9KBcPoLrbPR olOnJqW3Oox4PvPPk/TCmhpSQcsQgQxsNaAY4pGkESTNWcCsyEQzclPMtRgIbSQD07N7 u6rXrQ4FreFgnC1AHLGmhmcZVaLf1NA4KfKdW0daf1ToqWkq84yVZWiElStFpvGWceOz FG4Q== X-Received: by 10.180.38.37 with SMTP id d5mr4170260wik.37.1374703295658; Wed, 24 Jul 2013 15:01:35 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:dd4c:7a03:b3a7:c01c]) by mx.google.com with ESMTPSA id l2sm8196931wif.8.2013.07.24.15.01.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 15:01:34 -0700 (PDT) Message-ID: <51F04EBC.3050901@jitsi.org> Date: Thu, 25 Jul 2013 00:01:32 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> In-Reply-To: <51F046A9.5010207@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnKzfDObmJBrXMeOwADGGFJUxKXyekdVGp03mIKj0f2IwotDxpO2Lzku3bWx3QJMjTG0tAm Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 22:01:42 -0000 On 24.07.13, 23:27, Adam Roach wrote: > On 7/24/13 16:17, Emil Ivov wrote: >> >> >> On 24.07.13, 20:31, Eric Rescorla wrote: >>> >>> It depends on the context obviously. But in the case of (for instance= ) a >>> Hangouts >>> like system if the conference bridge were the offerer, it would send = a >>> pile of >>> m-lines with only one being sendrecv (or maybe even recvonly) for the= >>> user's media and the rest being sendonly. >> >> Sorry, I am still not getting it. How does it know exactly how many >> "m=3D" lines to place in a=3Dsendrecv? > > I think you need to re-read and meditate on section 5.1 of RFC 3264. > This stuff is actually pretty well defined, and I'm not sure having an > on-list tutorial is ideal. > > Your follow-up questions are likely answered in section 6.1 of that sam= e > document. Sorry Adam, I must be having my dumb-day today, but I don't see how 3264 = is even related to what I am asking. The original query here was about a bridge that invites an endpoint into = a conference using "unified". The bridge knows that it will be streaming = 8 flows (e.g. from 8 participants) so it creates 8 "m=3D" lines. I believe I=F1aki's question was: if the callee only has one stream to=20 send, how does it pick an "m=3D" line to associate it with (e.g. for the = purposes of codec selection). Eric's answer was: the Offer from the bridge would have marked *one*,=20 and only one of the "m=3D" lines as "a=3Dsendrecv", so that's the line yo= u use. My follow up question was then: how did the bridge know in advance, that = the callee only had one media source and not any other number. This is not a loaded question. I am trying to figure out what the best=20 practices with "unified" are. Again, I might be missing something, so if you feel this would be=20 perfectly obvious to everyone else, then please ignore. Emil --=20 https://jitsi.org From adam@nostrum.com Wed Jul 24 15:22: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 8384A11E8137 for ; Wed, 24 Jul 2013 15:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 MZIIKjCSpy4W for ; Wed, 24 Jul 2013 15:22:01 -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 74BA111E811E for ; Wed, 24 Jul 2013 15:22:01 -0700 (PDT) Received: from orochi-2.roach.at (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 r6OMLtJ7015170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 17:21:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51F0537E.1050507@nostrum.com> Date: Wed, 24 Jul 2013 17:21:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> In-Reply-To: <51F04EBC.3050901@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 22:22:02 -0000 On 7/24/13 17:01, Emil Ivov wrote: > > Sorry Adam, I must be having my dumb-day today, but I don't see how > 3264 is even related to what I am asking. Did you even look at the sections that I specifically cited? They discuss precisely how you determine how to set sendrecv/sendonly/recvonly/inactive attributes. In the example EKR gave, the bridge is only asking for one video stream because that's what makes sense for *it*. It's not guessing how many cameras you might have. /a From emil@sip-communicator.org Wed Jul 24 15:58: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 87A1A11E812E for ; Wed, 24 Jul 2013 15:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUCVGj-bXKFT for ; Wed, 24 Jul 2013 15:58:54 -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 A647511E811E for ; Wed, 24 Jul 2013 15:58:53 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n12so978523wgh.33 for ; Wed, 24 Jul 2013 15:58:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=/5xY7Yg14FdtZr0tm3k0ugBrKN+irjeTgZiPQaUcDsM=; b=lCgpyN+kt4ddjSabuU2MfqE0UOu8NPFoU+7ggYFChJbZm3qIwlOTHGRbFUHqTje1Wd Xg3mKyrc2AmtmtKOlJLo8iPURwJEgM2iDR2YFjQK/JKccOf28Px+ymUXJ7IjMOm5szss dEJxF2vAJC1ms/BwVuY2Bdl8wzwh77Ou4Z88vk2Om7q71USpBFzICHmZlBhIJjBacR1P eC5dVSkMQJzglW3LLFQVLNfQYSZ8lz29ad5AXJYf9QWHgSpW+Ix0mL4eJyLpsS+frhRS u9HD3NNlf2kubrtPNVbCmimiBgy3T4GFEk/99iRe74ZhxaVMMk6WhMYUeDOtXbVxw/Fn 83fQ== X-Received: by 10.180.39.136 with SMTP id p8mr4354600wik.11.1374706732849; Wed, 24 Jul 2013 15:58:52 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id iz8sm8482166wic.3.2013.07.24.15.58.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 15:58:51 -0700 (PDT) Message-ID: <51F05C2A.1000702@jitsi.org> Date: Thu, 25 Jul 2013 00:58:50 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> In-Reply-To: <51F0537E.1050507@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlh/9KgppeQs1nTfZlx6ZJmYHfNbnLFDNTK8q2LHZMIQst5beNvx01cAniSelbewX1rQ8KQ Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Wed, 24 Jul 2013 22:58:59 -0000 On 25.07.13, 00:21, Adam Roach wrote: > On 7/24/13 17:01, Emil Ivov wrote: >> >> Sorry Adam, I must be having my dumb-day today, but I don't see how >> 3264 is even related to what I am asking. > > Did you even look at the sections that I specifically cited? I did and they were delightful! Thanks for recommending! > They > discuss precisely how you determine how to set > sendrecv/sendonly/recvonly/inactive attributes. I don't think this is accurate. At least not in the context of the=20 current scenario. What these sections talk about is how to set the=20 direction attribute once you *know* what direction you'd like to have=20 for your streams. It does not talk about how you get to know what you want. Obviously this = would be quite out of scope there. > In the example EKR gave, the bridge is only asking for one video stream= > because that's what makes sense for *it*. It's not guessing how many > cameras you might have. So you are confirming that the number of media sources, that the bridge=20 expected to get from the callee, was hard-coded or pre-provisioned. Right= ? If so, then that's cool and I off to my next question: How would you handle the case where such pre-provisioning is impossible=20 and a callee could respond with any number of sources. To simplify let's get back to I=F1aki's scenario of 8 "m=3D" lines in the= =20 offer, but lets also assume that different callees can answer with=20 anything between 1 and 8 sources. In this case, do you set all your "m=3D" lines to "a=3Dsendrecv"? If so, we are back to I=F1aki's original question: how does a=20 single-source callee know which if these "m=3D" lines to pick for its own= =20 stream? I suppose one possible answer would be: it just takes any "m=3D" line=20 that matches its needs and sends stuff there. It also sets everything=20 else to "a=3Drecvonly" in the answer. Is this what you'd suggest? Or maybe the callee sends an answer where it sets everything to=20 "a=3Drecvonly" and then re-offers with a ninth "a=3Dsendonly" "m=3D" line= ? Or does the callee use app-specific signalling to tell the bridge that=20 it has N sources so that the bridge would offer with N "a=3Dsendrecv" "m=3D= "=20 lines and 8-N "a=3Dsendonly" "m=3D" lines? Or are all three of the above legal? Emil --=20 https://jitsi.org From adam@nostrum.com Wed Jul 24 17:01: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 E9F2B21F85E6 for ; Wed, 24 Jul 2013 17:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 ulUTBdXs5LlW for ; Wed, 24 Jul 2013 17:01:03 -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 57AF621F85E0 for ; Wed, 24 Jul 2013 17:01:03 -0700 (PDT) Received: from orochi-2.roach.at (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 r6P00xr4025991 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 19:00:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51F06AB6.2010008@nostrum.com> Date: Wed, 24 Jul 2013 19:00:54 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> In-Reply-To: <51F05C2A.1000702@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Thu, 25 Jul 2013 00:01:04 -0000 On 7/24/13 17:58, Emil Ivov wrote: > So you are confirming that the number of media sources, that the > bridge expected to get from the callee, was hard-coded or > pre-provisioned. Right? It's part of the application. Sure. "Hard-coded" is a reasonable way to think about it. > To simplify let's get back to Iñaki's scenario of 8 "m=" lines in the > offer, but lets also assume that different callees can answer with > anything between 1 and 8 sources. > > In this case, do you set all your "m=" lines to "a=sendrecv"? If the bridge wanted to deal with receiving that many media streams, sure. > If so, we are back to Iñaki's original question: how does a > single-source callee know which if these "m=" lines to pick for its > own stream? > > I suppose one possible answer would be: it just takes any "m=" line > that matches its needs and sends stuff there. It also sets everything > else to "a=recvonly" in the answer. Is this what you'd suggest? > > Or maybe the callee sends an answer where it sets everything to > "a=recvonly" and then re-offers with a ninth "a=sendonly" "m=" line? > > Or does the callee use app-specific signalling to tell the bridge that > it has N sources so that the bridge would offer with N "a=sendrecv" > "m=" lines and 8-N "a=sendonly" "m=" lines? > > Or are all three of the above legal? Yes, the first one is what I would recommend. The second one is certainly valid, but why would you do that? It delays the callee-to-caller media unnecessarily. The third one is fine, too, assuming you want to bind yourself to that kind of signaling (it may complicate interdomain federation, if that ever becomes important to you). But this is all pretty easy to derive from RFC 3264 section 6.1, really. /a From randy@qti.qualcomm.com Wed Jul 24 17:38: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 5613C21F92B8 for ; Wed, 24 Jul 2013 17:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sVbGUbywNMos for ; Wed, 24 Jul 2013 17:38:29 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5F74221F89A5 for ; Wed, 24 Jul 2013 17:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374712709; x=1406248709; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=0quCA6Gr+MV5CUV4nWaa3my/27AIEUt8ypxqopXK/Ng=; b=B+0KvJd7Rf+sJKdRciwb00RfL5mGh9KPkmcpG1BCo0R6MlUhv0csncS+ hEPbdOs5e8rSQSZ7wGPvGJBQ1TY9ckpatG4LdzoT69+TSkSMmqPeiR88d dtppxDZ1CJo6/Aq/kbGfMw1Z/kgqUwihmAV6jLdKz1Um231GuPjvQ852C w=; X-IronPort-AV: E=Sophos;i="4.89,738,1367996400"; d="scan'208";a="64529573" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 24 Jul 2013 17:38:28 -0700 X-IronPort-AV: E=Sophos;i="4.89,738,1367996400"; d="scan'208";a="509996064" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2013 17:38:28 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 24 Jul 2013 17:38:28 -0700 Message-ID: In-Reply-To: <51EEC4A8.9050108@alum.mit.edu> <51EF1A54.2070302@alum.mit.edu> References: <51EEC4A8.9050108@alum.mit.edu> <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se> <51EF1A54.2070302@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Wed, 24 Jul 2013 17:36:38 -0700 To: IETF MMUSIC WG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-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 Jul 2013 00:38:33 -0000 Lots of good discussion, especially on the issues of complexity vs completeness, preferences (none, 3-level, q-value), and back to if SDP is the right choice. I'm thinking another face-to-face discussion, such as we did in Orlando, would be helpful in moving towards resolution. I don't think the 15 minutes on the agenda at mmusic will be sufficient for this, so I've set a Doodle poll on a time in Berlin. Please use the link below to indicate when you can make it. http://doodle.com/u6vcppxw3tuncbcd -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most savage controversies are those about matters as to which there is no good evidence either way. --Bertrand Russell From partha@parthasarathi.co.in Thu Jul 25 08:48: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 2604521F8F63 for ; Thu, 25 Jul 2013 08:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 X3fX6BWaXOlC for ; Thu, 25 Jul 2013 08:48:49 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id B859421F9005 for ; Thu, 25 Jul 2013 08:48:49 -0700 (PDT) Received: from userPC (unknown [122.179.63.252]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 1456A190821F; Thu, 25 Jul 2013 15:48:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374767326; bh=/3uO1FInBjo2QU0esBuANXPchUZvVLux5K1o8aPHJIE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UDyYS86CQCb4NiHYY/w3HOPHAW/Njq5RozrjbsTFvCK9d+HKy80VCymgaz6H1+d7d ZKTzqh4VpOZv82ZHgcRjdLETgdz+TC4PTsrHVLYVvJMMmHtp72Qmx+yYSBv5CE5b6W WGUbnAD8KzDBdeNusGQWYIzTc7juP/QZ/Mbix9R0= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Cullen Jennings \(fluffy\)'" References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <51F03DC8.70908@jitsi.org> In-Reply-To: <51F03DC8.70908@jitsi.org> Date: Thu, 25 Jul 2013 21:18:33 +0530 Message-ID: <00d401ce894e$70aa81c0$51ff8540$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6Ir0KyyyKc+PMJSzWyB6BlLpa4aAAm+PGg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51F148DE.0092, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: 'Alan Johnston' , 'MMUSIC IETF WG' , 'Christer Holmberg' Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 25 Jul 2013 15:48:54 -0000 Hi Emil, In the mentioned situation, different To-tag with same contact header for trickled SDP, So there will be no "N" locations. My reading of the draft is that this draft is not required in case UPDATE (RFC 3311) method is supported. UPDATE with SDP will update trickle candidate within 18x. The aim of the draft is to support Trickle ICE for SIP user agent which does not support RFC 3311 for last 11 years. AFAIK, different "to tag" is the simpler way to solve the problem in UAS side. I have concern w.r.t INFO mechanism as it adds one method for handling SDP and complicates the existing SDP O/A handling (RFC 6337). Including Christer in this mail thread as he replied in the parallel mail thread. Thanks Partha > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Thursday, July 25, 2013 2:19 AM > To: Cullen Jennings (fluffy) > Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; MMUSIC > IETF WG > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > > > On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > > > > On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) > wrote: > > > >> 180 with different to-tag would mean call is forked. > >> If uac side do not support call forking, then we cannot use this 180 > >> response to collect trickled candidates. > > > > If it is a UAC, it supports this so I don't see the problem. > > One problem is that the UAC could support it to the extent of making it > visible to the user: > > "Your contact is being alerted on these N locations" > > And of course there's also the fact that we would be creating several > dialogs per call, that we'd then need to clean and garbage collect. > > Why would we want to go there? > > Emil > > -- > https://jitsi.org From partha@parthasarathi.co.in Thu Jul 25 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 BF55821F9B19 for ; Thu, 25 Jul 2013 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 NcPPOBwCzBaV for ; Thu, 25 Jul 2013 08:55:16 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 916C121F9AAB for ; Thu, 25 Jul 2013 08:55:16 -0700 (PDT) Received: from userPC (unknown [122.179.63.252]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 7A18619082CF; Thu, 25 Jul 2013 15:55:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374767716; bh=DI6N6uMsJtV0BIDojWJC8dpIRfd5HDAcWGRguzOc/YA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lSOGT5gxH5z8Pv+cxJPDktEVGBc1ij4WXrqahfQhk37Lt5ZNMJlA1jvyuGFhDfGti ORz7+zkMaC/DrPHtOig3HepSsjriULqdseeYksBFRtchHWN+7Tsrog+zJ4jvVsKE1G Hes5V2pvws1W6wAhwekHCQsTKpjXzg8HC/jcr5us= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Cullen Jennings \(fluffy\)'" , "'Vijaya Mandava \(vimandav\)'" References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com>, <7594FB04B1934943A5C02806D1A2204B1C4083B4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4083B4@ESESSMB209.ericsson.se> Date: Thu, 25 Jul 2013 21:25:04 +0530 Message-ID: <00df01ce894f$58a3baf0$09eb30d0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01CE897D.725BF6F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlzKl8AgABpUQCAAARAgIAAc7GAgAAYYYCAABo/gIAALD5ggAE8h2A= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.51F14A64.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: 'Alan Johnston' , 'MMUSIC IETF WG' Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 25 Jul 2013 15:55:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E0_01CE897D.725BF6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, The only way to identify whether it is same from UAS is to look into contact header/IP address of the SIP response. In this situation, contact header and IP address of SIP response is same all for "to-tag". My concern is w.r.t INFO with SDP handling. I have written in the different thread. Thanks Partha From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, July 25, 2013 2:05 AM To: Cullen Jennings (fluffy); Vijaya Mandava (vimandav) Cc: Alan Johnston; MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP Questions Hi, Wouldn't the UAC need to know that the 180s come from the same UAS? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Cullen Jennings (fluffy) [fluffy@cisco.com] To: Vijaya Mandava (vimandav) [vimandav@cisco.com] CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) wrote: > 180 with different to-tag would mean call is forked. > If uac side do not support call forking, then we cannot use this 180 > response to collect trickled candidates. If it is a UAC, it supports this so I don't see the problem. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_00E0_01CE897D.725BF6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

The only way to identify whether it is same from UAS is = to look into contact header/IP address of the SIP response. In this situation, = contact header and IP address of SIP response is same all for = “to-tag”.

 

My concern is w.r.t INFO with SDP handling. I have = written in the different thread.

 

Thanks

Partha

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: Thursday, July 25, 2013 2:05 AM
To: Cullen Jennings (fluffy); Vijaya Mandava (vimandav)
Cc: Alan Johnston; MMUSIC IETF WG
Subject: Re: [MMUSIC] Trickle ICE for SIP = Questions

 

Hi,

 

Wouldn't the UAC need to know that the 180s come from the = same UAS?

 

Regards,

 

Christer

 



Sent from Windows using TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Cullen Jennings (fluffy) [fluffy@cisco.com]
To: Vijaya Mandava (vimandav) [vimandav@cisco.com]
CC: Alan Johnston [alan.b.johnston@gmail.com]; MMUSIC IETF WG [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP = Questions


On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) <vimandav@cisco.com> wrote:

> 180 with different to-tag would mean call is forked.
> If uac side do not support call forking, then we cannot use this = 180
> response to collect trickled candidates.

If it is a UAC, it supports this so I don't see the problem.

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

------=_NextPart_000_00E0_01CE897D.725BF6F0-- From emil@sip-communicator.org Thu Jul 25 09:38: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 F201321F8925 for ; Thu, 25 Jul 2013 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl4t7yOGKTUA for ; Thu, 25 Jul 2013 09:38:23 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 130B221F8EB3 for ; Thu, 25 Jul 2013 09:38:22 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so5863527wid.3 for ; Thu, 25 Jul 2013 09:38:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=CUIQsvVqetGCZS8Ymx9HGA8kKZaC7rY7xBO952iq0oU=; b=EWwpY0BQSa4cnFGdIxeQODIVjvv/2G8ilMA0fNtKJAVXs6W8Q8buW0fQMvwSPvV/Dx D6cG3gEOAFHqx02LR+NdLmlfNrsKjdWDcWDzwkvaxuQefoCFtrHvUlCA0oLJ4qlsGnIS gBjqZ5MM3mhBcW+xJ4y0sevo8OVIGPtjuf0QI2PehkPzGGKUEQRQf0jjI4qWUN6KbZOW J8K4ZeU0pcMaq7HH8zgWFUAfyu2SGztQJkIqDb5JBpPuEj+eDPENPxBNjWu/aO42aiwB sSd2JKbYP54mCUrXUqnrA836cCi/mEs3OS/503Am3RD/IfFq/FV6AJen6J9+pyE3t41q AeBg== X-Received: by 10.180.208.84 with SMTP id mc20mr2730106wic.32.1374770300729; Thu, 25 Jul 2013 09:38:20 -0700 (PDT) Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id nb12sm4918574wic.7.2013.07.25.09.38.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 09:38:19 -0700 (PDT) Message-ID: <51F15478.3060104@jitsi.org> Date: Thu, 25 Jul 2013 18:38:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: 'MMUSIC IETF WG' References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <51F03DC8.70908@jitsi.org> <00d401ce894e$70aa81c0$51ff8540$@co.in> In-Reply-To: <00d401ce894e$70aa81c0$51ff8540$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk5e+lJxQL35UT2WrNHlbw2tBTg0yF+ZOD8yc+sVHyT0dsEOrf0FyKtSArRcxhZ4oluMqmP Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 25 Jul 2013 16:38:28 -0000 Hey Partha, On 25.07.13, 17:48, Parthasarathi R wrote: > Hi Emil, > > In the mentioned situation, different To-tag with same contact header for > trickled SDP, So there will be no "N" locations. Having the same contact header does not automatically suggest that this is somehow a fake fork (unless I am missing the text that says this in 3261). You could potentially have this if the fork is done by a B2BUA or a PSTN gateway for example. > My reading of the draft is that this draft is not required in case UPDATE > (RFC 3311) method is supported. UPDATE with SDP will update trickle > candidate within 18x. Use of UPDATE has already been discussed and we pretty much agreed not to go that way. A mail from Alan and the preceding discussion: http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html A follow up with a nice summary from Dale: http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html > The aim of the draft is to support Trickle ICE for SIP user agent which does > not support RFC 3311 for last 11 years. AFAIK, different "to tag" is the > simpler way to solve the problem in UAS side. I have concern w.r.t INFO > mechanism as it adds one method for handling SDP and complicates the > existing SDP O/A handling (RFC 6337). That's the thing, trickle ICE is not part of Offer/Answer. It's a separate channel for agent-to-agent communication. Use of SDP is just a convenient coincidence. > Including Christer in this mail thread as he replied in the parallel mail > thread. I believe he is on the list I don't think that's an issue :) Cheers, Emil > > Thanks > Partha > >> -----Original Message----- >> From: Emil Ivov [mailto:emcho@jitsi.org] >> Sent: Thursday, July 25, 2013 2:19 AM >> To: Cullen Jennings (fluffy) >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; MMUSIC >> IETF WG >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >> >> >> >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: >>> >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) >> wrote: >>> >>>> 180 with different to-tag would mean call is forked. >>>> If uac side do not support call forking, then we cannot use this 180 >>>> response to collect trickled candidates. >>> >>> If it is a UAC, it supports this so I don't see the problem. >> >> One problem is that the UAC could support it to the extent of making it >> visible to the user: >> >> "Your contact is being alerted on these N locations" >> >> And of course there's also the fact that we would be creating several >> dialogs per call, that we'd then need to clean and garbage collect. >> >> Why would we want to go there? >> >> Emil >> >> -- >> https://jitsi.org > > -- https://jitsi.org From pkyzivat@alum.mit.edu Thu Jul 25 10:09: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 B5DD821F9703 for ; Thu, 25 Jul 2013 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=0.178, 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 9MNw+rpEaPpP for ; Thu, 25 Jul 2013 10:09:34 -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 5B28521F969F for ; Thu, 25 Jul 2013 10:09:30 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4dya1m00B1ap0As55h9NhF; Thu, 25 Jul 2013 17:09:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 4h9M1m00Y3ZTu2S3ih9Mbw; Thu, 25 Jul 2013 17:09:21 +0000 Message-ID: <51F15BC0.2000401@alum.mit.edu> Date: Thu, 25 Jul 2013 13:09:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF MMUSIC WG , Emil Ivov 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=1374772162; bh=L0CEZXj/b+QI+U8n1lshZCgpwGQGcKEuoiHIpj9ITJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rOWXtudnWj1ZN26pe8TyID8p7xIWslfnd29tb26D9LjojdsOw4VqAUt+fr/ugrnAd WnD0W++6eLzkurDVF4nnETKb72+dOlmWM2Dy33TA7DNvJakb5cGPpp0vs59NK0/sQH rLGCR0N59EcjpP8Nryn7MD9IiNGUx38nvg12U9gbWke6Agw1N1o8dLI2hZBf5jgz7D KI8ocbCdHjtbr3tINFOndxbLSdQsptvi4aFR/QvzjOsAGDIZBVQQuSKZc4Qq1eL2L3 MMO4uQJYM4nqLa44MfV9DMpKoiyHNy2WrdFsDuH3lh9N0rPWao8+ibDf0Blw5vuXxh 0JTV4SPX0aw0Q== Subject: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 17:09:40 -0000 (I was rereviewing this in prep for the meeting) Section 4 says that trickled candidates are transported as INFO payloads containing SDP formatted according to ivov-mmusic-trickle-ice. But AFAICT that draft doesn't specify this. Also the example in this section shows an info payload that contains only a subset of SDP, and doesn't conform to mime type application/sdp. Section 5.6 again references the trickle-ice draft (section 4) for definition of the body of the info message, but that section of that draft doesn't contain any such definition. Aside from that, it occurs to me that trickle-ice, and for that matter ice in sip even without trickle, is a good candidate for preconditions. The use of preconditions could eliminate the need for half trickle. This would of course require a new precondition type, but that is doable. By using preconditions, you can establish the dialog without alerting the callee. Then the alert can be deferred until at least one workable path has been detected. (But I suppose the hate for preconditions is so great that this is not to be considered.) Thanks, Paul From christer.holmberg@ericsson.com Thu Jul 25 11:36: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 5E83D21F964C for ; Thu, 25 Jul 2013 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.171, 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 ZoBoKHzzw1wD for ; Thu, 25 Jul 2013 11:36:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4B121F9473 for ; Thu, 25 Jul 2013 11:36:43 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-fe-51f1703ab7c7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B0.28.19388.A3071F15; Thu, 25 Jul 2013 20:36:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 20:36:41 +0200 From: Christer Holmberg To: Paul Kyzivat , IETF MMUSIC WG , Emil Ivov Thread-Topic: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 Thread-Index: AQHOiVnCmhdeCV/JPUOLAt8lIwg8Y5l1uRtH Date: Thu, 25 Jul 2013 18:36:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> References: <51F15BC0.2000401@alum.mit.edu> In-Reply-To: <51F15BC0.2000401@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C408F15ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvra5VwcdAgyvP+S3W7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlHPzez1zQrVexcrpWA+Mq 9S5GTg4JAROJ0xPbGCFsMYkL99azdTFycQgJHGaUONUzFcpZwigx69Vfli5GDg42AQuJ7n/a IA0iApkSn658YQKxhQWsJB5MnMEEEbeWODn/OjuEbSTx7uVtVhCbRUBVYv/cV+wgY3gFfCV2 bbAHCQsJaEtMfDIN7AZOAR2J/z0TwcoZge75fmoN2EhmAXGJW0/mM0HcKSCxZM95ZghbVOLl 43+sEDX5EhP/zGUDsXkFBCVOznzCMoFReBaS9llIymYhKYOI60gs2P2JDcLWlli28DUzjH3m wGMmZPEFjOyrGNlzEzNz0svNNzECI+bglt8GOxg33Rc7xCjNwaIkzrtZ70ygkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkYvXqcvf2JCm+0mbeyYuuagyiLpDas2aXHWLJxpL3N/8aXY6OsW O4wfB25Y5XI4Le74C9cnx4wDljlHdlWtaD2QasvtFsSoZr6zZWVGsd7yjlmWcQUfuTY43V7+ Kumx0Y91z1WCMhXeZfms++N3o1b5ZI7sUteOv6W33Ri8UqOX5f1jT2tR/63EUpyRaKjFXFSc CABJJCiuZgIAAA== Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 18:36:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C408F15ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Are you sure a new type is needed? The existing types are rather generic, a= ren't they? Also, if people don't like the precondition mechanism, another option is to= simply set the streams to inactive until enough candidates are collected, = and specify that trickle ICE UASs don't alert the user until the direction = attribute is changed to a non-inactive value. E.g. 3GPP has done that for m= any years. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] Subject: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 (I was rereviewing this in prep for the meeting) Section 4 says that trickled candidates are transported as INFO payloads containing SDP formatted according to ivov-mmusic-trickle-ice. But AFAICT that draft doesn't specify this. Also the example in this section shows an info payload that contains only a subset of SDP, and doesn't conform to mime type application/sdp. Section 5.6 again references the trickle-ice draft (section 4) for definition of the body of the info message, but that section of that draft doesn't contain any such definition. Aside from that, it occurs to me that trickle-ice, and for that matter ice in sip even without trickle, is a good candidate for preconditions. The use of preconditions could eliminate the need for half trickle. This would of course require a new precondition type, but that is doable. By using preconditions, you can establish the dialog without alerting the callee. Then the alert can be deferred until at least one workable path has been detected. (But I suppose the hate for preconditions is so great that this is not to be considered.) Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C408F15ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Paul,
 
Are you sure a new type is needed? The existing= types are rather generic, aren't they?
 
Also, if people don't like the precondition mec= hanism, another option is to simply set the streams to inactive until enoug= h candidates are collected, and specify that trickle ICE UASs don't alert t= he user until the direction attribute is changed to a non-inactive value. E.g. 3GPP has done that for many years= .
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] Subject: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
(I was rereviewing this in prep for the meeting)
Section 4 says that trickled candidates are transported as INFO payloads containing SDP formatted according to ivov-mmusic-trickle-ice. But
AFAICT that draft doesn't specify this. Also the example in this section shows an info payload that contains only a subset of SDP, and doesn't
conform to mime type application/sdp.

Section 5.6 again references the trickle-ice draft (section 4) for
definition of the body of the info message, but that section of that
draft doesn't contain any such definition.

Aside from that, it occurs to me that trickle-ice, and for that matter
ice in sip even without trickle, is a good candidate for preconditions. The use of preconditions could eliminate the need for half trickle. This would of course require a new precondition type, but that is doable.

By using preconditions, you can establish the dialog without alerting
the callee. Then the alert can be deferred until at least one workable
path has been detected.

(But I suppose the hate for preconditions is so great that this is not
to be considered.)

        Thanks,
        Paul
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C408F15ESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu Jul 25 11: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 7672E21F9371 for ; Thu, 25 Jul 2013 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=0.168, 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 dAoTk46X4tPS for ; Thu, 25 Jul 2013 11:55:33 -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 EFDEA21F9344 for ; Thu, 25 Jul 2013 11:55:31 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id 4bq91m0031ei1Bg58ivX6G; Thu, 25 Jul 2013 18:55:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 4ivX1m00V3ZTu2S3kivXVV; Thu, 25 Jul 2013 18:55:31 +0000 Message-ID: <51F174A2.2020402@alum.mit.edu> Date: Thu, 25 Jul 2013 14:55:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C408F15@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=1374778531; bh=AD/30rwZoQ2rxUQX7OiwwgBuz1Hi3jfFIgM845Rvp5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XHeUl78X/7yyEp3dwS5RI69EmXICFG0FBYb5/4aYpO1Tr23AWy8ecqatBxMTj0Tnt JbZgIyWissVzFuXwwA+lWyJlIRcfJdJn00609Dvr7Y2IRapmMOpOtUXYkDIZ8HwDs/ 49TEtKVRZr/o5acvWKzmlz0nlJwfUGEqkRfEiF4pv0HE1bkRz+1zhaOsEtMxbifXOP i0cSTaaeYKOmd5DJ24bIFs/t1NVy7QdnfZUdlk1fXGCU7RY+oKdOytybyyT9Mo/CVq RxjGJSI+8wVBPeb1VWy4LgVMa2e1JgPVHQzWjD26kag4CQitJ1n3MwCW4ko7sktpc3 xBG8Zx8BOAI6w== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 18:55:37 -0000 On 7/25/13 2:36 PM, Christer Holmberg wrote: > Hi Paul, > Are you sure a new type is needed? The existing types are rather > generic, aren't they? I'm not sure, but I thought they were more specific than that. Maybe there is some type that is sufficiently general. > Also, if people don't like the precondition mechanism, another option is > to simply set the streams to inactive until enough candidates are > collected, and specify that trickle ICE UASs don't alert the user until > the direction attribute is changed to a non-inactive value. E.g. 3GPP > has done that for many years. I hadn't heard of specifying a change in alerting behavior based on inactive. That seems weird and improper to me. Thanks, Paul > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *To:* IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] > *Subject:* [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 > (I was rereviewing this in prep for the meeting) > > Section 4 says that trickled candidates are transported as INFO payloads > containing SDP formatted according to ivov-mmusic-trickle-ice. But > AFAICT that draft doesn't specify this. Also the example in this section > shows an info payload that contains only a subset of SDP, and doesn't > conform to mime type application/sdp. > > Section 5.6 again references the trickle-ice draft (section 4) for > definition of the body of the info message, but that section of that > draft doesn't contain any such definition. > > Aside from that, it occurs to me that trickle-ice, and for that matter > ice in sip even without trickle, is a good candidate for preconditions. > The use of preconditions could eliminate the need for half trickle. This > would of course require a new precondition type, but that is doable. > > By using preconditions, you can establish the dialog without alerting > the callee. Then the alert can be deferred until at least one workable > path has been detected. > > (But I suppose the hate for preconditions is so great that this is not > to be considered.) > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Thu Jul 25 11:57: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 DAE7121F9360 for ; Thu, 25 Jul 2013 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 vUTx-A6-NnT3 for ; Thu, 25 Jul 2013 11:57:29 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2A8B21F9344 for ; Thu, 25 Jul 2013 11:57:28 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so2001484wgg.0 for ; Thu, 25 Jul 2013 11:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=+BWXih+NyTAYPYRQxbG7UxbD5R2u0Fs0i2LwoekYBDU=; b=JCAzreDKeg4xBJpghAHuHbTXXd6nArort1VAIdRY7JANMWbm9u3a1HzgMPjHkSdIJ+ EYCH5TnO4wx5P8/aSkW7rg3mDr9q/BPkm6ngVDbqUyJWpuGbchTcUXSW9Dz2uTstDJd/ 5FOgRvU9KrawgNrtdze4Os+UcMjuizsrdXtyWFKQHmYmOb6Ozu3utGoMH9khoJPUvzp1 u4zrPZvXcSswHjIuhFD9tNrjvSs8rWoSSuthUwNRiBJ9iTqfbVX4UNIgDEm9SjUXpNrb 4elBDc+kVzTneBKClgXK2YP79Jzh2HPHMsFzV+CXDQtkuFahfbTLOEnoYlRCwM58aGGc El1A== X-Received: by 10.180.160.134 with SMTP id xk6mr3089785wib.40.1374778646434; Thu, 25 Jul 2013 11:57:26 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:a84e:51b7:5b8c:268f]) by mx.google.com with ESMTPSA id nb12sm5754279wic.7.2013.07.25.11.57.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 11:57:25 -0700 (PDT) Message-ID: <51F17512.8090700@jitsi.org> Date: Thu, 25 Jul 2013 20:57:22 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkRObUBV9jMNrOPrJAkrXeoq60vNKpNimjqwOnZEk+vFUo1LREFPtP8sAbpW24x7h8rTRvX Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 18:57:33 -0000 Hey folks, On 25.07.13, 20:36, Christer Holmberg wrote: > Hi Paul, > Are you sure a new type is needed? The existing types are rather > generic, aren't they? Back in Boston we decided to do something like this: http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 More below: > On 25.07.13, 19:09, Paul Kyzivat wrote: > > Section 4 says that trickled candidates are transported as INFO payloads > containing SDP formatted according to ivov-mmusic-trickle-ice. But > AFAICT that draft doesn't specify this. Well, it just borrows the format from 5245 and says that this is how you represent trickled candidates. > Also the example in this section > shows an info payload that contains only a subset of SDP, and doesn't > conform to mime type application/sdp. Yup, should be application/sdpfrag. > Section 5.6 again references the trickle-ice draft (section 4) for > definition of the body of the info message, but that section of that > draft doesn't contain any such definition. Will need to fix. > Aside from that, it occurs to me that trickle-ice, and for that matter > ice in sip even without trickle, is a good candidate for preconditions. > The use of preconditions could eliminate the need for half trickle. This > would of course require a new precondition type, but that is doable. Hmmm ... that's a good point! > By using preconditions, you can establish the dialog without alerting > the callee. Then the alert can be deferred until at least one workable > path has been detected. > > (But I suppose the hate for preconditions is so great that this is not > to be considered.) Well, it doesn't have to be mandatory ... Emil > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- https://jitsi.org From christer.holmberg@ericsson.com Thu Jul 25 12:08: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 B8B6E21F85E6 for ; Thu, 25 Jul 2013 12:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=-1.667, 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 Kygp-ydNtagf for ; Thu, 25 Jul 2013 12:08:49 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0A21F859A for ; Thu, 25 Jul 2013 12:08:48 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-ad-51f177be3b96 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 13.6F.11907.EB771F15; Thu, 25 Jul 2013 21:08:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 21:08:45 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 Thread-Index: AQHOiVnCmhdeCV/JPUOLAt8lIwg8Y5l1uRtH///juwCAACU7oQ== Date: Thu, 25 Jul 2013 19:08:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C408FED@ESESSMB209.ericsson.se> References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se>, <51F174A2.2020402@alum.mit.edu> In-Reply-To: <51F174A2.2020402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C408FEDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre6+8o+BBt1NUhZrdk5gsZi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgyTvf/YSy4ZFcx59lDtgbG ByZdjJwcEgImEvdnbGCBsMUkLtxbz9bFyMUhJHCUUWJH/2d2kISQwBJGiUsfVboYOTjYBCwk uv9pg5giAhoSk7aqgVQwCzhKXD22jgUkLCxgJfHgvyJIWETAWuLk/OvsELaTxI/VL1hBbBYB VYnN29vBtvIK+Eq8OfSTCWJRP6NE82tbEJtTQEdi67kWRhCbEeiy76fWMEGsEpe49WQ+E8TF AhJL9pxnhrBFJV4+/scKUZMvsXJXJxvEfEGJkzOfsExgFJmFpH0WkrJZSMog4noSN6ZOYYOw tSWWLXzNDGHrSsz4d4gFWXwBI/sqRo7i1OKk3HQjg02MwEg6uOW3xQ7Gy39tDjFKc7AoifNu 0TsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGR307rdQHz6/dLF8fHCFy+cOzcxp6lsc0x r2wLuiz/VLxg9tYTuakhYVe25+P2WUKhKjpf85d1x+cdPmnV+f7brtr7p+T6HnIr31uQVMdm t2LK4x+mrbwzckyDDsx1PC1zXK5O6fnfo+8SXfa7Tfb5XtHikL/eubvWv1BdrFf2a+TeGdxx zw8osRRnJBpqMRcVJwIAtUw4unICAAA= Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 19:08:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C408FEDESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, I don't thin 3261 specifies when a user must be alerted, does it? ;) Anyway, it was just one example of how people have achieved "delayed user a= lerting" without using the precondition mechanism. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 On 7/25/13 2:36 PM, Christer Holmberg wrote: > Hi Paul, > Are you sure a new type is needed? The existing types are rather > generic, aren't they? I'm not sure, but I thought they were more specific than that. Maybe there is some type that is sufficiently general. > Also, if people don't like the precondition mechanism, another option is > to simply set the streams to inactive until enough candidates are > collected, and specify that trickle ICE UASs don't alert the user until > the direction attribute is changed to a non-inactive value. E.g. 3GPP > has done that for many years. I hadn't heard of specifying a change in alerting behavior based on inactive. That seems weird and improper to me. Thanks, Paul > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *To:* IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] > *Subject:* [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 > (I was rereviewing this in prep for the meeting) > > Section 4 says that trickled candidates are transported as INFO payloads > containing SDP formatted according to ivov-mmusic-trickle-ice. But > AFAICT that draft doesn't specify this. Also the example in this section > shows an info payload that contains only a subset of SDP, and doesn't > conform to mime type application/sdp. > > Section 5.6 again references the trickle-ice draft (section 4) for > definition of the body of the info message, but that section of that > draft doesn't contain any such definition. > > Aside from that, it occurs to me that trickle-ice, and for that matter > ice in sip even without trickle, is a good candidate for preconditions. > The use of preconditions could eliminate the need for half trickle. This > would of course require a new precondition type, but that is doable. > > By using preconditions, you can establish the dialog without alerting > the callee. Then the alert can be deferred until at least one workable > path has been detected. > > (But I suppose the hate for preconditions is so great that this is not > to be considered.) > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C408FEDESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul,
 
I don't thin 3261 specifies when a user must be alerted, does it? ;)
 
Anyway, it was just one example of how people have achieved "= ;delayed user alerting" without using the precondition mechanism.
 
Regards,
 
Christer
 
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
On 7/25/13 2:36 PM, Christer Holmberg wrote:
> Hi Paul,
> Are you sure a new type is needed? The existing types are rather
> generic, aren't they?

I'm not sure, but I thought they were more specific than that.
Maybe there is some type that is sufficiently general.

> Also, if people don't like the precondition mechanism, another option = is
> to simply set the streams to inactive until enough candidates are
> collected, and specify that trickle ICE UASs don't alert the user unti= l
> the direction attribute is changed to a non-inactive value. E.g. 3GPP<= br> > has done that for many years.

I hadn't heard of specifying a change in alerting behavior based on
inactive. That seems weird and improper to me.

        Thanks,
        Paul

> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Paul Kyzivat [pkyzivat@alum.mit.edu]
> *To:* IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] > *Subject:* [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
> (I was rereviewing this in prep for the meeting)
>
> Section 4 says that trickled candidates are transported as INFO payloa= ds
> containing SDP formatted according to ivov-mmusic-trickle-ice. But
> AFAICT that draft doesn't specify this. Also the example in this secti= on
> shows an info payload that contains only a subset of SDP, and doesn't<= br> > conform to mime type application/sdp.
>
> Section 5.6 again references the trickle-ice draft (section 4) for
> definition of the body of the info message, but that section of that > draft doesn't contain any such definition.
>
> Aside from that, it occurs to me that trickle-ice, and for that matter=
> ice in sip even without trickle, is a good candidate for preconditions= .
> The use of preconditions could eliminate the need for half trickle. Th= is
> would of course require a new precondition type, but that is doable. >
> By using preconditions, you can establish the dialog without alerting<= br> > the callee. Then the alert can be deferred until at least one workable=
> path has been detected.
>
> (But I suppose the hate for preconditions is so great that this is not=
> to be considered.)
>
>          Thanks,
>          Paul
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

 --_000_7594FB04B1934943A5C02806D1A2204B1C408FEDESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Jul 25 12:12: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 CF28D21F997E for ; Thu, 25 Jul 2013 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.277, 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 fDOqmXVuwMvj for ; Thu, 25 Jul 2013 12:11:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9921F859A for ; Thu, 25 Jul 2013 12:11:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-e5-51f1786e49fa Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A1.B6.05990.E6871F15; Thu, 25 Jul 2013 21:11:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 21:11:41 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 Thread-Index: AQHOiVnCmhdeCV/JPUOLAt8lIwg8Y5l1uRtH///kQACAACWIYw== Date: Thu, 25 Jul 2013 19:11:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C409031@ESESSMB209.ericsson.se> References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se>, <51F17512.8090700@jitsi.org> In-Reply-To: <51F17512.8090700@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C409031ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvrW5excdAgy83hCzW7JzAYjF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBlnD0jVrDDpOLopKUsDYwT dboYOTkkBEwk7h99ygxhi0lcuLeerYuRi0NI4DCjxJd9l5khnCWMEldeHAVyODjYBCwkuv9p gzSICMhLdLctYgKxmQW8JO7tOsAIUiIsYCXx4L8iRIm1xMn519khbCeJtuenGEFsFgFViRez P4DZvAK+El+fP4da1cMo0XL7LytIglNAU+LrxD6wZkag476fWgO1S1zi1pP5TBBHC0gs2XMe 6gFRiZeP/7FC1ORL7Og9xwSxQFDi5MwnLBMYRWYhaZ+FpGwWkjKIuJ7EjalT2CBsbYllC18z Q9i6EjP+HWJBFl/AyL6KkT03MTMnvdxoEyMwlg5u+a26g/HOOZFDjNIcLErivJv1zgQKCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYFykOlEodmr3Xqldol+TpLZKXmHRffm+YadGVO8roez/ V3/UneHP3Nx294njoeeSJzOL9dMuffL5XrjEZ1/N5mqfQsYTzZNiDjAssV35RGCHb4peZHHp 6TUZDw/lu2osFeftFOiZkqAbYTZz/a8Z08JVlLcdzxee0FO3POtYYuff9Kj0lhlTTyixFGck GmoxFxUnAgC3iYtbcwIAAA== Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 19:12:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C409031ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Emil, I don't think Paul was talking about a new MIME types, but the type values = used for the precondition mechanism. Paul? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Emil Ivov [emcho@jitsi.org] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Paul Kyzivat [pkyzivat@alum.mit.edu]; IETF MMUSIC WG [mmusic@ietf.org] Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 Hey folks, On 25.07.13, 20:36, Christer Holmberg wrote: > Hi Paul, > Are you sure a new type is needed? The existing types are rather > generic, aren't they? Back in Boston we decided to do something like this: http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 More below: > On 25.07.13, 19:09, Paul Kyzivat wrote: > > Section 4 says that trickled candidates are transported as INFO payloads > containing SDP formatted according to ivov-mmusic-trickle-ice. But > AFAICT that draft doesn't specify this. Well, it just borrows the format from 5245 and says that this is how you represent trickled candidates. > Also the example in this section > shows an info payload that contains only a subset of SDP, and doesn't > conform to mime type application/sdp. Yup, should be application/sdpfrag. > Section 5.6 again references the trickle-ice draft (section 4) for > definition of the body of the info message, but that section of that > draft doesn't contain any such definition. Will need to fix. > Aside from that, it occurs to me that trickle-ice, and for that matter > ice in sip even without trickle, is a good candidate for preconditions. > The use of preconditions could eliminate the need for half trickle. This > would of course require a new precondition type, but that is doable. Hmmm ... that's a good point! > By using preconditions, you can establish the dialog without alerting > the callee. Then the alert can be deferred until at least one workable > path has been detected. > > (But I suppose the hate for preconditions is so great that this is not > to be considered.) Well, it doesn't have to be mandatory ... Emil > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- https://jitsi.org --_000_7594FB04B1934943A5C02806D1A2204B1C409031ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Emil,
 
I don't think Paul was talking about a new MIME types, but the type va= lues used for the precondition mechanism. Paul?
 
Regards,
 
Christer

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [emcho@jitsi.org]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Paul Kyzivat [pkyzivat@alum.mit.edu]; IETF MMUSIC WG [mmusic@iet= f.org]
Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00
Hey folks,

On 25.07.13, 20:36, Christer Holmberg wrote:
> Hi Paul,
> Are you sure a new type is needed? The existing types are rather
> generic, aren't they?

Back in Boston we decided to do something like this:

http:= //tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00

More below:

> On 25.07.13, 19:09, Paul Kyzivat wrote:
>
> Section 4 says that trickled candidates are transported as INFO payloa= ds
> containing SDP formatted according to ivov-mmusic-trickle-ice. But
> AFAICT that draft doesn't specify this.

Well, it just borrows the format from 5245 and says that this is how you represent trickled candidates.

> Also the example in this section
> shows an info payload that contains only a subset of SDP, and doesn't<= br> > conform to mime type application/sdp.

Yup, should be application/sdpfrag.

> Section 5.6 again references the trickle-ice draft (section 4) for
> definition of the body of the info message, but that section of that > draft doesn't contain any such definition.

Will need to fix.

> Aside from that, it occurs to me that trickle-ice, and for that matter=
> ice in sip even without trickle, is a good candidate for preconditions= .
> The use of preconditions could eliminate the need for half trickle. Th= is
> would of course require a new precondition type, but that is doable.
Hmmm ... that's a good point!

> By using preconditions, you can establish the dialog without alerting<= br> > the callee. Then the alert can be deferred until at least one workable=
> path has been detected.
>
> (But I suppose the hate for preconditions is so great that this is not=
> to be considered.)

Well, it doesn't have to be mandatory ...

Emil

>
>          Thanks,
>          Paul
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

--
https://jitsi.org
 --_000_7594FB04B1934943A5C02806D1A2204B1C409031ESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu Jul 25 13:05: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 EA2C421F9298 for ; Thu, 25 Jul 2013 13:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=0.151, 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 ME53m5pKdoot for ; Thu, 25 Jul 2013 13:05:03 -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 D5FD321F91CE for ; Thu, 25 Jul 2013 13:04:57 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id 4bqr1m0011uE5Es5Ek4xC3; Thu, 25 Jul 2013 20:04:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 4k4x1m00B3ZTu2S3ck4xlF; Thu, 25 Jul 2013 20:04:57 +0000 Message-ID: <51F184E8.40406@alum.mit.edu> Date: Thu, 25 Jul 2013 16:04:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> In-Reply-To: <51F17512.8090700@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=1374782697; bh=Aq2s5O7FuUMw2aH5LkGE+uHbNVqSbgUsXrq90GOWIXw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Er733WFNJlrll3QoRDDOSNouxo6OVRruiKAuNIrfNsW89DUpmOrmTFv6rzKsNlpmu +RkNTmN7taHxWS4u+hhUIYxWYSASPjwAtbvkLnASV+RjwcCYHdMcGoZ2Szzye8I+iS PKgpBIu8ftk/MDR9e17+T55tj5iRfdxKW5mI/EC2zWNimeYBWqvQqUpz4kopjNxmVT XPLo1yU6+tnzEt4tYyiWwPAF9k5SxcDjA8l3oAGAMvIR3+GlvJ5GAGgl2GiRyY4x8w Qr+qyNqyNscK0U6HHa4k9t4sce3h+xVyeua9pcQIeRQVDD4XI9U2sv+jW6PKlP9oT9 FbX2eM97lSpCw== Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 20:05:08 -0000 On 7/25/13 2:57 PM, Emil Ivov wrote: > Hey folks, > > On 25.07.13, 20:36, Christer Holmberg wrote: >> Hi Paul, >> Are you sure a new type is needed? The existing types are rather >> generic, aren't they? > > Back in Boston we decided to do something like this: > > http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 I thought Christer was talking about my suggestion that preconditions would require a new precondition type. Nothing to do with the mime type. > More below: > >> On 25.07.13, 19:09, Paul Kyzivat wrote: >> >> Section 4 says that trickled candidates are transported as INFO payloads >> containing SDP formatted according to ivov-mmusic-trickle-ice. But >> AFAICT that draft doesn't specify this. > > Well, it just borrows the format from 5245 and says that this is how you > represent trickled candidates. But all of that assumes a full SDP body. And it seems you don't. Your draft somewhere has a mention that the trickled stuff must be keyed to a media section via mid, but nothing formally written about it. >> Also the example in this section >> shows an info payload that contains only a subset of SDP, and doesn't >> conform to mime type application/sdp. > > Yup, should be application/sdpfrag. Well, AFAIK there is currently no such mime type. So its necessary to define it. And while you could define a generic one, you have some specific requirements about what this needs to contain, so you might want to define application/trickle-ice-sdp with all the requisite rules. >> Section 5.6 again references the trickle-ice draft (section 4) for >> definition of the body of the info message, but that section of that >> draft doesn't contain any such definition. > > Will need to fix. > >> Aside from that, it occurs to me that trickle-ice, and for that matter >> ice in sip even without trickle, is a good candidate for preconditions. >> The use of preconditions could eliminate the need for half trickle. This >> would of course require a new precondition type, but that is doable. > > Hmmm ... that's a good point! > >> By using preconditions, you can establish the dialog without alerting >> the callee. Then the alert can be deferred until at least one workable >> path has been detected. >> >> (But I suppose the hate for preconditions is so great that this is not >> to be considered.) > > Well, it doesn't have to be mandatory ... > > Emil > >> >> Thanks, >> Paul >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Thu Jul 25 13:07: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 4C0A421F84D9 for ; Thu, 25 Jul 2013 13:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm5JHgIXW2H1 for ; Thu, 25 Jul 2013 13:07:42 -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 6E96321F91CE for ; Thu, 25 Jul 2013 13:07:24 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4jVc1m0031wpRvQ55k6y5q; Thu, 25 Jul 2013 20:06:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 4k6y1m00b3ZTu2S3ek6yBU; Thu, 25 Jul 2013 20:06:58 +0000 Message-ID: <51F18562.4050804@alum.mit.edu> Date: Thu, 25 Jul 2013 16:06:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se>, <51F174A2.2020402@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408FED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C408FED@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=1374782818; bh=o1pmmkG1TwqV/L3sUOe/b54fOJCYbDDFNb8+oaWQxi0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SKakq205J5OXlrk6+JH0BSofBEcPC90hI5X0rf/8O7Hf8MKWMEoiTe/KmnjY3rkYg yI+xGXNpoPow675Lgslbc2pG74Vbm4HzOEzSTOKH1zHu5+pDb6QUgorjVjtcPRizQE GnL+vwCeSJaHMuUTaMNJVZwVts77Hp+SKxt17vHJyLdXYzRAWixJiOk9Ukru6SYH+j sEpYmbUWh4bz5AtrrGty7964JV+lkmMmCUTJTEX8K1iRIagTVUT+H+0njztwyIM1XM vEo4nsxRvYF/gC/oms4m0TkhdTxRC8my5OoVREjaq7jkSpIGWb75nAaooVDVChGdRW ANa0XM4Xp5JRg== Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 20:07:47 -0000 On 7/25/13 3:08 PM, Christer Holmberg wrote: > > Hi Paul, > I don't thin 3261 specifies when a user must be alerted, does it? ;) No, I don't think so. I didn't say it was an invalid thing to do, just improper and weird. :-) IOW, it doesn't smell right to me. Thanks, Paul > Anyway, it was just one example of how people have achieved "delayed > user alerting" without using the precondition mechanism. > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] > *Subject:* Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 > On 7/25/13 2:36 PM, Christer Holmberg wrote: >> Hi Paul, >> Are you sure a new type is needed? The existing types are rather >> generic, aren't they? > > I'm not sure, but I thought they were more specific than that. > Maybe there is some type that is sufficiently general. > >> Also, if people don't like the precondition mechanism, another option is >> to simply set the streams to inactive until enough candidates are >> collected, and specify that trickle ICE UASs don't alert the user until >> the direction attribute is changed to a non-inactive value. E.g. 3GPP >> has done that for many years. > > I hadn't heard of specifying a change in alerting behavior based on > inactive. That seems weird and improper to me. > > Thanks, > Paul > >> Regards, >> Christer >> >> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com ) >> >> -----Original Message----- >> *From:* Paul Kyzivat [pkyzivat@alum.mit.edu] >> *To:* IETF MMUSIC WG [mmusic@ietf.org]; Emil Ivov [emcho@jitsi.org] >> *Subject:* [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00 >> (I was rereviewing this in prep for the meeting) >> >> Section 4 says that trickled candidates are transported as INFO payloads >> containing SDP formatted according to ivov-mmusic-trickle-ice. But >> AFAICT that draft doesn't specify this. Also the example in this section >> shows an info payload that contains only a subset of SDP, and doesn't >> conform to mime type application/sdp. >> >> Section 5.6 again references the trickle-ice draft (section 4) for >> definition of the body of the info message, but that section of that >> draft doesn't contain any such definition. >> >> Aside from that, it occurs to me that trickle-ice, and for that matter >> ice in sip even without trickle, is a good candidate for preconditions. >> The use of preconditions could eliminate the need for half trickle. This >> would of course require a new precondition type, but that is doable. >> >> By using preconditions, you can establish the dialog without alerting >> the callee. Then the alert can be deferred until at least one workable >> path has been detected. >> >> (But I suppose the hate for preconditions is so great that this is not >> to be considered.) >> >> Thanks, >> Paul >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From emil@sip-communicator.org Thu Jul 25 13:42: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 A6E1A21F9301 for ; Thu, 25 Jul 2013 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paGxXAvuOjlu for ; Thu, 25 Jul 2013 13:42:32 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2E21F91B4 for ; Thu, 25 Jul 2013 13:42:31 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so2123747wgh.5 for ; Thu, 25 Jul 2013 13:42:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=ksm1aSpWZXhRDovZVAIbvjc7yDENXp+dIK+MVSJ57fk=; b=eoZlV8eUtM2GWJYdUvxSNV9d4oQyAUXblsUIOsf01iTBUF5+KL9ZutroHaXzucHTaS desLc8BGohF3zSpATh2Io3vo7hpjstCdsp0U6efTZIMldjWYyIv6p7b3s46ohAZsU22Q AEIiqpmQ2sUfN3+F4tXYqjVEry398VStUpaN1TuduAAazfDoyHT7ubV4y88DvSPeIeRQ dT7MGImHjwTpKgQbkj7JlnrWFVFsQNevAiF5ezyvStgtju0gSmjvA0+julFXuJq7DK2O 8tXks/RgmIb7zxZxD0giXLbn0tOTqHeQtYyrBpVDOl0ikO5RTy/ckhIsrikgsKLky8A1 3KHQ== X-Received: by 10.180.39.136 with SMTP id p8mr3445935wik.11.1374784939642; Thu, 25 Jul 2013 13:42:19 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id nb12sm397577wic.3.2013.07.25.13.42.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 13:42:18 -0700 (PDT) Message-ID: <51F18DA9.1080509@jitsi.org> Date: Thu, 25 Jul 2013 22:42:17 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> <51F184E8.40406@alum.mit.edu> In-Reply-To: <51F184E8.40406@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkgLDm8iwpa987ILAE+8HVOSdZMD428ISlLVdILmEkVVSpcjB3ozkcIwvEKLUG1KWHB6vSX Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 20:42:36 -0000 Hey Paul, On 25.07.13, 22:04, Paul Kyzivat wrote: > On 7/25/13 2:57 PM, Emil Ivov wrote: >> Hey folks, >> >> On 25.07.13, 20:36, Christer Holmberg wrote: >>> Hi Paul, >>> Are you sure a new type is needed? The existing types are rather >>> generic, aren't they? >> >> Back in Boston we decided to do something like this: >> >> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 > > I thought Christer was talking about my suggestion that preconditions > would require a new precondition type. Nothing to do with the mime type. Sorry, the above was meant to go underneath your comment about how this: "doesn't conform to mime type application/sdp." But I messed up the quoting. >> More below: >> >>> On 25.07.13, 19:09, Paul Kyzivat wrote: >>> >>> Section 4 says that trickled candidates are transported as INFO payloads >>> containing SDP formatted according to ivov-mmusic-trickle-ice. But >>> AFAICT that draft doesn't specify this. >> >> Well, it just borrows the format from 5245 and says that this is how you >> represent trickled candidates. > > But all of that assumes a full SDP body. I don't see how the syntax of an "a=candidate" line depends on the full SDP body, so I don't see the problem with just pointing there. Again, I mean this only about syntax. > And it seems you don't. > Your draft somewhere has a mention that the trickled stuff must be keyed > to a media section via mid, but nothing formally written about it. Yes agreed. This will have to be expanded in trickle-ice-sip. > >>> Also the example in this section >>> shows an info payload that contains only a subset of SDP, and doesn't >>> conform to mime type application/sdp. >> >> Yup, should be application/sdpfrag. > > Well, AFAIK there is currently no such mime type. So its necessary to > define it. This is the point of the draft I pasted above: http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 Of course, it does need more work (by the way, help there is more than welcome so if you want to join just let me know). > And while you could define a generic one, you have some specific > requirements about what this needs to contain, so you might want to > define application/trickle-ice-sdp with all the requisite rules. The original idea (which I believe came from Adam) was that this could be avoided in a way similar to how application/sipfrag does it. I basically specifies syntax (as a SIP subset) and leaves semantics to specs that are using it, like for example 3515 Do you see any reason why this couldn't work here? Emil >>> Section 5.6 again references the trickle-ice draft (section 4) for >>> definition of the body of the info message, but that section of that >>> draft doesn't contain any such definition. >> >> Will need to fix. >> >>> Aside from that, it occurs to me that trickle-ice, and for that matter >>> ice in sip even without trickle, is a good candidate for preconditions. >>> The use of preconditions could eliminate the need for half trickle. This >>> would of course require a new precondition type, but that is doable. >> >> Hmmm ... that's a good point! >> >>> By using preconditions, you can establish the dialog without alerting >>> the callee. Then the alert can be deferred until at least one workable >>> path has been detected. >>> >>> (But I suppose the hate for preconditions is so great that this is not >>> to be considered.) >> >> Well, it doesn't have to be mandatory ... >> >> Emil >> >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > > . > -- https://jitsi.org From pkyzivat@alum.mit.edu Thu Jul 25 14:46: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 8669F21F8F3C for ; Thu, 25 Jul 2013 14:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.126, 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 E6vJvWzMkQAE for ; Thu, 25 Jul 2013 14:46:04 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 4990921F85B4 for ; Thu, 25 Jul 2013 14:46:04 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id 4k8z1m0031c6gX85Alm3rB; Thu, 25 Jul 2013 21:46:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 4lm31m00R3ZTu2S3jlm3Py; Thu, 25 Jul 2013 21:46:03 +0000 Message-ID: <51F19C9A.3040706@alum.mit.edu> Date: Thu, 25 Jul 2013 17:46:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> <51F184E8.40406@alum.mit.edu> <51F18DA9.1080509@jitsi.org> In-Reply-To: <51F18DA9.1080509@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=1374788763; bh=3/tCW8hbA4Aj20BUk9g96u0WCOcqTSrBv+hpj+WkmZk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hdsmjl24Mt/fuJcmiA7PTsg9cRlCKm69JRjKX58IgUSiTL/mjoux8TeV97ntp5CE4 pvU8qTrCGfrlb+Dfx/oat+9lBf9XBRLrneuFwuHUWWq6D8XaHOGiPVrvWNC/6WE7vQ MCYgdwyoRXtdjR17FyDCSwLvG6PnzFMozbCgXqA6G5rMnU+dvgdc5et2bQtSXkOMT/ CEL65/IShMjr/dA+txl4wv4uvMAdAt6MyKkCu+YOrDblV9mm1Gs0+ENJIOgp+6yiPX 9siy45IVwVuv8G2KJ6Rx8OHkS2pAVzW58a+X4CzHSNXrrBry9u991+g7apxfuLADXK wfxjVF60bvqxg== Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 21:46:16 -0000 On 7/25/13 4:42 PM, Emil Ivov wrote: >>>> On 25.07.13, 19:09, Paul Kyzivat wrote: >>>> >>>> Section 4 says that trickled candidates are transported as INFO >>>> payloads >>>> containing SDP formatted according to ivov-mmusic-trickle-ice. But >>>> AFAICT that draft doesn't specify this. >>> >>> Well, it just borrows the format from 5245 and says that this is how you >>> represent trickled candidates. >> >> But all of that assumes a full SDP body. > > I don't see how the syntax of an "a=candidate" line depends on the full > SDP body, so I don't see the problem with just pointing there. Again, I > mean this only about syntax. My point is that 5245 never suggests that ICE will be represented in SDP in anything but a full SDP body. If you said that you were proposing to send subsets of SDP as described in 5245, that would make some sense. (As long as you specify how to select the subset.) >>>> Also the example in this section >>>> shows an info payload that contains only a subset of SDP, and doesn't >>>> conform to mime type application/sdp. >>> >>> Yup, should be application/sdpfrag. >> >> Well, AFAIK there is currently no such mime type. So its necessary to >> define it. > > This is the point of the draft I pasted above: > http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 > > Of course, it does need more work (by the way, help there is more than > welcome so if you want to join just let me know). Oh, duh. That slipped right by me. But of course it is incomplete. I could help, once I understand what it needs to say. The first decision is: >> And while you could define a generic one, you have some specific >> requirements about what this needs to contain, so you might want to >> define application/trickle-ice-sdp with all the requisite rules. > > The original idea (which I believe came from Adam) was that this could > be avoided in a way similar to how application/sipfrag does it. I > basically specifies syntax (as a SIP subset) and leaves semantics to > specs that are using it, like for example 3515 > > Do you see any reason why this couldn't work here? Its a choice. In the case of sipfrag, IIRC it was defined for use with 3515. In that it isn't crucial what is in it. So it works there. In your case what goes in it is more critical. It can still be defined this way. But it will take some care to get it right. The main thing is that it be done somewhere! Can an INFO trickle ICE candidates for more than one m-line? If so, it gets messy. Consider a full SDP: ... m=... a=mid:1 a=candidate:... ... m=... a=candidate:... a=mid:2 a=candidate:... (AFAIK the above is entirely legal.) Now consider a sipfrag for trickle from the above: a=mid:1 a=candidate:... a=candidate:... a=mid:2 a=candidate:... Now, which candidates go with which m-line? So, I think your sdpfrag needs special constraints that don't apply to ICE in full SDP. Thanks, Paul > Emil > >>>> Section 5.6 again references the trickle-ice draft (section 4) for >>>> definition of the body of the info message, but that section of that >>>> draft doesn't contain any such definition. >>> >>> Will need to fix. >>> >>>> Aside from that, it occurs to me that trickle-ice, and for that matter >>>> ice in sip even without trickle, is a good candidate for preconditions. >>>> The use of preconditions could eliminate the need for half trickle. >>>> This >>>> would of course require a new precondition type, but that is doable. >>> >>> Hmmm ... that's a good point! >>> >>>> By using preconditions, you can establish the dialog without alerting >>>> the callee. Then the alert can be deferred until at least one workable >>>> path has been detected. >>>> >>>> (But I suppose the hate for preconditions is so great that this is not >>>> to be considered.) >>> >>> Well, it doesn't have to be mandatory ... >>> >>> Emil >>> >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> . >> > From emil@sip-communicator.org Thu Jul 25 15: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 12DF921F8F29 for ; Thu, 25 Jul 2013 15:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 NhQRYnuerMlC for ; Thu, 25 Jul 2013 15:32:36 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E821F8E3D for ; Thu, 25 Jul 2013 15:32:35 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so1497965wgg.4 for ; Thu, 25 Jul 2013 15:32:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=+KWhVM1iEjgojC1iRTU9KHvZ+rtHXQ3V5speXF+KEFE=; b=D6IglI3t9oND3ueiXJRVQQngj37UkuivNlEE12DikgnsCdvInJ7yDkMJQLGabpS0bi pC+JG/bzcsWJ8JqwHP8jBnHM+jQEkD3WgAE7wA0aYdST6PxFXPygH7wXdlnJpXMlXU91 VTnKJHN0k9JiJ9UqIAR5FgGBXEDm6oXSbz1PkjyD0B+OixIzqLnY8tFA4QirB5H+9R7t qS5kl/f4LbI9K5uJTifPmxki2JjJWX5zCqAP48CNrNaTkYL8fByUEtvpeYlHDPLQ+1eG Omr/Prm1+bvaIKa/s2+eIflaJoHW2PhzseGcf70d+EmCRJgxBznuzKFJT9l3NEZu3GY9 B67Q== X-Received: by 10.194.1.226 with SMTP id 2mr21952898wjp.91.1374791554618; Thu, 25 Jul 2013 15:32:34 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:fd7b:1632:360c:32df]) by mx.google.com with ESMTPSA id d8sm934146wiz.0.2013.07.25.15.32.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 15:32:33 -0700 (PDT) Message-ID: <51F1A77F.10608@jitsi.org> Date: Fri, 26 Jul 2013 00:32:31 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> <51F184E8.40406@alum.mit.edu> <51F18DA9.1080509@jitsi.org> <51F19C9A.3040706@alum.mit.edu> In-Reply-To: <51F19C9A.3040706@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkR7uxDIDF9g5PDfikzK75H/wKq3BUBurJLXh1HElDp7A0hjpFklI2TqOpX0fzawm+kM44E Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 22:32:40 -0000 Hey Paul, On 25.07.13, 23:46, Paul Kyzivat wrote: > On 7/25/13 4:42 PM, Emil Ivov wrote: > >>>>> On 25.07.13, 19:09, Paul Kyzivat wrote: >>>>> >>>>> Section 4 says that trickled candidates are transported as INFO >>>>> payloads >>>>> containing SDP formatted according to ivov-mmusic-trickle-ice. But >>>>> AFAICT that draft doesn't specify this. >>>> >>>> Well, it just borrows the format from 5245 and says that this is how you >>>> represent trickled candidates. >>> >>> But all of that assumes a full SDP body. >> >> I don't see how the syntax of an "a=candidate" line depends on the full >> SDP body, so I don't see the problem with just pointing there. Again, I >> mean this only about syntax. > > My point is that 5245 never suggests that ICE will be represented in SDP > in anything but a full SDP body. > > If you said that you were proposing to send subsets of SDP as described > in 5245, that would make some sense. The section that deals with this is 9.1 http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#section-9.1 The intention is exactly what you describe above. > (As long as you specify how to > select the subset.) The subset is an "a=candidate" line. I don't think select is the right word here though. You just encode an ICE candidate, as you would encode it for an SDP offer or answer. >>>>> Also the example in this section >>>>> shows an info payload that contains only a subset of SDP, and doesn't >>>>> conform to mime type application/sdp. >>>> >>>> Yup, should be application/sdpfrag. >>> >>> Well, AFAIK there is currently no such mime type. So its necessary to >>> define it. >> >> This is the point of the draft I pasted above: >> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 >> >> Of course, it does need more work (by the way, help there is more than >> welcome so if you want to join just let me know). > > Oh, duh. That slipped right by me. But of course it is incomplete. > > I could help, once I understand what it needs to say. Great! > The first decision is: Did you miss something here? >>> And while you could define a generic one, you have some specific >>> requirements about what this needs to contain, so you might want to >>> define application/trickle-ice-sdp with all the requisite rules. >> >> The original idea (which I believe came from Adam) was that this could >> be avoided in a way similar to how application/sipfrag does it. I >> basically specifies syntax (as a SIP subset) and leaves semantics to >> specs that are using it, like for example 3515 >> >> Do you see any reason why this couldn't work here? > > Its a choice. In the case of sipfrag, IIRC it was defined for use with > 3515. In that it isn't crucial what is in it. So it works there. > > In your case what goes in it is more critical. It can still be defined > this way. But it will take some care to get it right. > > The main thing is that it be done somewhere! Agreed! > Can an INFO trickle ICE candidates for more than one m-line? Yes. > If so, it gets messy. Consider a full SDP: > > ... > m=... > a=mid:1 > a=candidate:... > ... > m=... > a=candidate:... > a=mid:2 > a=candidate:... > > (AFAIK the above is entirely legal.) > > Now consider a sipfrag for trickle from the above: > > a=mid:1 > a=candidate:... > a=candidate:... > a=mid:2 > a=candidate:... > > Now, which candidates go with which m-line? So, I think your sdpfrag > needs special constraints that don't apply to ICE in full SDP. I think the problem with the above is that you are trying to present it as an extract from some pre-existing offer or answer, while it isn't. When you are trickling you find yourself in a situation where you have one or more newly learned candidates. You want to send those to the remote agent. To do this you group them by stream (as in "m=" line). For each group you start by creating an "a=mid:x" attribute that matches the one from the "m=" line that created the stream. You then create and append "a=candidate" lines for every candidate in that group. That's it. The receiving peer does the opposite: it parses the "a=mid:x" line, it finds the stream object that it refers to, then parses all the candidates and adds them there. Does this make sense? Emil > > Thanks, > Paul > >> Emil >> >>>>> Section 5.6 again references the trickle-ice draft (section 4) for >>>>> definition of the body of the info message, but that section of that >>>>> draft doesn't contain any such definition. >>>> >>>> Will need to fix. >>>> >>>>> Aside from that, it occurs to me that trickle-ice, and for that matter >>>>> ice in sip even without trickle, is a good candidate for preconditions. >>>>> The use of preconditions could eliminate the need for half trickle. >>>>> This >>>>> would of course require a new precondition type, but that is doable. >>>> >>>> Hmmm ... that's a good point! >>>> >>>>> By using preconditions, you can establish the dialog without alerting >>>>> the callee. Then the alert can be deferred until at least one workable >>>>> path has been detected. >>>>> >>>>> (But I suppose the hate for preconditions is so great that this is not >>>>> to be considered.) >>>> >>>> Well, it doesn't have to be mandatory ... >>>> >>>> Emil >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> . >>> >> > > -- https://jitsi.org From pkyzivat@alum.mit.edu Thu Jul 25 16:26: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 EF21421F89A5 for ; Thu, 25 Jul 2013 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.267 X-Spam-Level: X-Spam-Status: No, score=0.267 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=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 P2tCAo2JTDP1 for ; Thu, 25 Jul 2013 16:26:31 -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 D4F3B21F8925 for ; Thu, 25 Jul 2013 16:26:19 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id 4mXC1m0040Fqzac59nSKrn; Thu, 25 Jul 2013 23:26:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 4nSK1m00B3ZTu2S3UnSKLm; Thu, 25 Jul 2013 23:26:19 +0000 Message-ID: <51F1B41A.3000700@alum.mit.edu> Date: Thu, 25 Jul 2013 19:26:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> <51F184E8.40406@alum.mit.edu> <51F18DA9.1080509@jitsi.org> <51F19C9A.3040706@alum.mit.edu> <51F1A77F.10608@jitsi.org> In-Reply-To: <51F1A77F.10608@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=1374794779; bh=DS9WEvOC4gXL8Z0WNSfBIfV5sDb1a4IdAh9qtP1Nwo4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PUoVz258KuSPQVEsuOJnb81vDm5sCueM7r97tUMwSVFtSTiksL2B9e8rKEivJJHK3 jHC4X7gxAN/FDt/N0SlxndsJU0NqGnlm85KAsw+fH3HE7CEhOl1c7wjbNBjtRunskJ Javpso8WLXrmE23ysOCYh2wG+H35XvX3Y/9f0xfi3e3KqNWacbQQIQx4ISgV3x7CUs vrwdxLNe9bjEzdepskWFn5htWlymNPyB2+T/v7yHXLcL0srURyS3n9BFWnyY6Gj2mj 7bJ3lN6q63TCyu6bYBBwLlyjb9UNboK27IfAxCJGnci1PwnGDFxknHwyL2byXIxAIk 7r5TyY3Ei1K0g== Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 25 Jul 2013 23:26:36 -0000 Emil, On 7/25/13 6:32 PM, Emil Ivov wrote: > Hey Paul, > > On 25.07.13, 23:46, Paul Kyzivat wrote: >> On 7/25/13 4:42 PM, Emil Ivov wrote: >> >>>>>> On 25.07.13, 19:09, Paul Kyzivat wrote: >>>>>> >>>>>> Section 4 says that trickled candidates are transported as INFO >>>>>> payloads >>>>>> containing SDP formatted according to ivov-mmusic-trickle-ice. But >>>>>> AFAICT that draft doesn't specify this. >>>>> >>>>> Well, it just borrows the format from 5245 and says that this is >>>>> how you >>>>> represent trickled candidates. >>>> >>>> But all of that assumes a full SDP body. >>> >>> I don't see how the syntax of an "a=candidate" line depends on the full >>> SDP body, so I don't see the problem with just pointing there. Again, I >>> mean this only about syntax. >> >> My point is that 5245 never suggests that ICE will be represented in SDP >> in anything but a full SDP body. >> >> If you said that you were proposing to send subsets of SDP as described >> in 5245, that would make some sense. > > The section that deals with this is 9.1 > > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#section-9.1 > > The intention is exactly what you describe above. Maybe you intended that. But I don't find sufficient words in the doc to determine what you mean. The words that seem to pertain to this are: Given that such lines do not provide a relationship between the candidate and the m line that it relates to, signalling protocols using trickle ICE MUST establish that relation themselves. This can be done in one of two ways: using the m-line index, or an MID [RFC3388]. The m-line index is a zero-based index, referring to the Nth m-line in the SDP. The MID uses "media stream identification", as defined in [RFC3388], to identify the m-line. So I'm supposed to infer that you are proposing to use a subset of SDP from that??? Also, what does "signalling protocols using trickle ICE MUST establish that relation themselves" *mean*? Does it mean that you intend the INFO message containing the trickle ice info in its body to specify the m-line somewhere other than in the same body??? I would expect that the body you send would include something to do this. If you use mid, then the syntax to do so already exists, sort of. If you use m-line index, then it doesn't. >> (As long as you specify how to >> select the subset.) > > The subset is an "a=candidate" line. I don't think select is the right > word here though. You just encode an ICE candidate, as you would encode > it for an SDP offer or answer. > >>>>>> Also the example in this section >>>>>> shows an info payload that contains only a subset of SDP, and doesn't >>>>>> conform to mime type application/sdp. >>>>> >>>>> Yup, should be application/sdpfrag. >>>> >>>> Well, AFAIK there is currently no such mime type. So its necessary to >>>> define it. >>> >>> This is the point of the draft I pasted above: >>> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 >>> >>> Of course, it does need more work (by the way, help there is more than >>> welcome so if you want to join just let me know). >> >> Oh, duh. That slipped right by me. But of course it is incomplete. >> >> I could help, once I understand what it needs to say. > > Great! > >> The first decision is: > > Did you miss something here? I forget. It doesn't matter. >>>> And while you could define a generic one, you have some specific >>>> requirements about what this needs to contain, so you might want to >>>> define application/trickle-ice-sdp with all the requisite rules. >>> >>> The original idea (which I believe came from Adam) was that this could >>> be avoided in a way similar to how application/sipfrag does it. I >>> basically specifies syntax (as a SIP subset) and leaves semantics to >>> specs that are using it, like for example 3515 >>> >>> Do you see any reason why this couldn't work here? >> >> Its a choice. In the case of sipfrag, IIRC it was defined for use with >> 3515. In that it isn't crucial what is in it. So it works there. >> >> In your case what goes in it is more critical. It can still be defined >> this way. But it will take some care to get it right. >> >> The main thing is that it be done somewhere! > > Agreed! > >> Can an INFO trickle ICE candidates for more than one m-line? > > Yes. > >> If so, it gets messy. Consider a full SDP: >> >> ... >> m=... >> a=mid:1 >> a=candidate:... >> ... >> m=... >> a=candidate:... >> a=mid:2 >> a=candidate:... >> >> (AFAIK the above is entirely legal.) >> >> Now consider a sipfrag for trickle from the above: >> >> a=mid:1 >> a=candidate:... >> a=candidate:... >> a=mid:2 >> a=candidate:... >> >> Now, which candidates go with which m-line? So, I think your sdpfrag >> needs special constraints that don't apply to ICE in full SDP. > > I think the problem with the above is that you are trying to present it > as an extract from some pre-existing offer or answer, while it isn't. > > When you are trickling you find yourself in a situation where you have > one or more newly learned candidates. You want to send those to the > remote agent. > > To do this you group them by stream (as in "m=" line). For each group > you start by creating an "a=mid:x" attribute that matches the one from > the "m=" line that created the stream. You then create and append > "a=candidate" lines for every candidate in that group. > > That's it. I thought that is what you had in mind. But you have said you want to use application/sdpfrag, which means it should be viewed as a subset of a full SDP. And that is especially so if you intend to reference m-lines in an SDP, but don't want to include them. And you haven't defined any new ordering rules for lines other than what exist for SDP. And SDP allows the ordering I show above, which doesn't work for you. I'll also mention that I think you need to explicitly reference the SDP offer or answer that this trickle updates. Probably by replicating the o-line from that SDP. So there are some significant syntax rules that need to be followed here. I would expect something like: - must start with o-line of the SDP it is updating - has one or more "media sections" - each media section begins with an a:mid line, referencing a mid defined in the referenced SDP - each a:mid line is followed by one or more a:candidate lines ... If going that way, then I think it is better to define a mime type that consists of exactly this syntax, with some extensibility hooks. Thanks, Paul > The receiving peer does the opposite: it parses the "a=mid:x" line, it > finds the stream object that it refers to, then parses all the > candidates and adds them there. > > Does this make sense? > > Emil > > >> >> Thanks, >> Paul >> >>> Emil >>> >>>>>> Section 5.6 again references the trickle-ice draft (section 4) for >>>>>> definition of the body of the info message, but that section of that >>>>>> draft doesn't contain any such definition. >>>>> >>>>> Will need to fix. >>>>> >>>>>> Aside from that, it occurs to me that trickle-ice, and for that >>>>>> matter >>>>>> ice in sip even without trickle, is a good candidate for >>>>>> preconditions. >>>>>> The use of preconditions could eliminate the need for half trickle. >>>>>> This >>>>>> would of course require a new precondition type, but that is doable. >>>>> >>>>> Hmmm ... that's a good point! >>>>> >>>>>> By using preconditions, you can establish the dialog without alerting >>>>>> the callee. Then the alert can be deferred until at least one >>>>>> workable >>>>>> path has been detected. >>>>>> >>>>>> (But I suppose the hate for preconditions is so great that this is >>>>>> not >>>>>> to be considered.) >>>>> >>>>> Well, it doesn't have to be mandatory ... >>>>> >>>>> Emil >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> . >>>> >>> >> >> > From pkyzivat@alum.mit.edu Thu Jul 25 16:33: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 6011721F8EEA for ; Thu, 25 Jul 2013 16:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.121, 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 JqtMyU+Cebzu for ; Thu, 25 Jul 2013 16:33:00 -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 4F7E421F81FF for ; Thu, 25 Jul 2013 16:32:59 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 4nUd1m0030bG4ec5BnYxVz; Thu, 25 Jul 2013 23:32:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 4nYw1m0183ZTu2S3PnYwHS; Thu, 25 Jul 2013 23:32:57 +0000 Message-ID: <51F1B5A7.1060400@alum.mit.edu> Date: Thu, 25 Jul 2013 19:32:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Emil Ivov References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> <51EEB807.6010704@jitsi.org> In-Reply-To: <51EEB807.6010704@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=1374795177; bh=OI3YxB4c2NNuxLtuyW7bJDm/9njsrcULb6au54yf8aA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VZNk2zfftoXovFhAz19iRmBrZycmoQqZLJB6qyFnkfcJ4wjPpaXw8ZOUvcol12CDs fUn5+gj2K5oszx/uvF4GSDLZ4Td2d1AqD1HqOogLtwylCM/6Ck04Zx5CB2yGTe3IhF W9yH6aHfYq4Unq+FjTPLpNSZc42KIO4xhbZPjkM1TE7woYvUPBAmZF02190XOnSO2t xYShsy26mPtmw+uO5n1KfGaFUnagPS0/JhoOubcgkfIt4pdBX1RWNtl7a8nqVuqe/E TWyVsn8tSR5FUB7vbgvS9qT+ZkihuczLhece7M3MA5NmfihTLXWbUxIh8oA90UA+cB EMkb0FkqTotEA== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 25 Jul 2013 23:33:06 -0000 On 7/23/13 1:06 PM, Emil Ivov wrote: > I actually think we could pull this off with simple PRACKs. Only, rather > than using the "100rel" tag we go for something like "100rel-lite" which > could be defined to indicate that a UA supports PRACK but only for > reliability (and PRACK bodies are not allowed). This is crazy! Every new option presents backward compatibility issues, implementation issues, ... It doesn't make sense to define a new option that is a subset of a long time existing option. This is *not* rocket science. Just tell people they need to support 100rel as a precondition for trickle ICE. If they find trickle ice worthwhile they can implement it. I'd be amazed if there are any SBCs that don't support PRACK. (But Hadriel will fill us in about that.) Thanks, Paul From fluffy@cisco.com Thu Jul 25 16:37:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2CB21F8F4A for ; Thu, 25 Jul 2013 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=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 ZYRsC+00hphJ for ; Thu, 25 Jul 2013 16:37:29 -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 D243821F8EEA for ; Thu, 25 Jul 2013 16:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=664; q=dns/txt; s=iport; t=1374795450; x=1376005050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0byuchmiqKbJYyMYCZx0gbtcXjBjHgMOWCOOcIAXxhk=; b=XejSKMOYLJxzEM01LGbrQxFEXE3La3oD9KaBJJ6B1cTJZKiCHh0oCZrq 5PgULzuhP8ydy8rY/GmGClqPlvObZkhjpFuGWDgLEteqx0FxZFeKO8ysy 9Bltu8TaL4t8qAvPp1jTqyAHNf7yS8IDkR/xImzGFssUct7MAWX+Uhw3R M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPO18VGtJXG9/2dsb2JhbABagwY1UIJFux+BFBZ0giQBAQEDAXkFCwIBCA4UJDIlAgQOBQiIAgYMuQOPSgIxB4MSbgOIcpAWkCSDFIIq X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="239443906" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2013 23:37:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6PNbTgM029941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 23:37:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 18:37:28 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiY/s1zYd+mpt00qv4Q6vDAxD9g== Date: Thu, 25 Jul 2013 23:37:28 +0000 Message-ID: References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> In-Reply-To: <51F05C2A.1000702@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Thu, 25 Jul 2013 23:37:34 -0000 On Jul 24, 2013, at 4:58 PM, Emil Ivov wrote: > If so, we are back to I=F1aki's original question: how does a single-sour= ce callee know which if these "m=3D" lines to pick for its own stream? If they don't have a=3Dcontent line (see http://tools.ietf.org/html/rfc4796= ) , you probably don't know which one to use and just use the first. If the= y no have the a=3Dcontent slide, then you likely have the information you n= eed to make the right decision by matching up to the one that has the value= for a=3Dcontent as the video you want to send. Note this would work better= if the registry also had front, left and right.=20 From fluffy@cisco.com Thu Jul 25 16:41: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 2B9C721F8D10 for ; Thu, 25 Jul 2013 16:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 mIzK1GK7Q1Cb for ; Thu, 25 Jul 2013 16:41:33 -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 43F4E21F8947 for ; Thu, 25 Jul 2013 16:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1009; q=dns/txt; s=iport; t=1374795693; x=1376005293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nI25K5U4cPo2RH62vsGpT1hntDun7rbSSuFVIi2Bh20=; b=SFPvBKR3kK/c9dbm69xajHDIxtsxVy1MbTewG3EUFX9r3XFiw7cLSh6d qK0iwhpciqcgHxEp+msTNXBEPzb1aWLcxuzsN5mJmWAtaZnkL58unnJTp agI9uwPKKuWm5tMiuAQ1uInOUZMCzKkKgGSx9ReAKsVR0C7NAuH94ANwM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAB+38VGtJXHA/2dsb2JhbABagwaBBb1kgRQWdIIkAQEBAwE6PwULAgEIGAoUEDIlAgQOBQiIAga5EY9KAjEHgxJuA5QIlSSDFIIq X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="236637691" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2013 23:41:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6PNfWkk003233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 23:41:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 18:41:32 -0500 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [MMUSIC] draft-roach-mmusic-unified-plan-00 Thread-Index: AQHOiZB9ama4WGXdmUuNfxPt9E6o0g== Date: Thu, 25 Jul 2013 23:41:31 +0000 Message-ID: References: <51EFF8E0.6010203@alum.mit.edu> <51EFFACD.7040905@nostrum.com> In-Reply-To: <51EFFACD.7040905@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] draft-roach-mmusic-unified-plan-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, 25 Jul 2013 23:41:44 -0000 On Jul 24, 2013, at 10:03 AM, Adam Roach wrote: > On 7/24/13 10:55, Paul Kyzivat wrote: >> This seems to be excluded, except by sending a new O/A every time the sp= eaker switches, which isn't feasible. If this means that CLUE can't represe= nt capture-encodings as m-lines, then there is no benefit to CLUE for the u= nified plan over No Plan (Emil's multiple-sources draft).=20 >=20 > That's interesting. I wonder whether we should simply move to the RTP hea= der extension described in section 3.2.1.1 as the primary means of correlat= ion. It would seem to address the case you describe. >=20 > /a SSRC can collide too so they might be wrong but the header extension does = not have that problem. It seems to me the algorithm is roughly if you have header extension, use that, if not then if you know the SSRC u= se that, if not then if you have unique PTs, use that. Perhaps there are ot= her things to use too but roughly those get used in that order.=20 From pkyzivat@alum.mit.edu Thu Jul 25 17:19: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 D76B421F91C4 for ; Thu, 25 Jul 2013 17:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=0.117, 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 RwiRlMs6OPzL for ; Thu, 25 Jul 2013 17:19:41 -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 AF91E21F90DC for ; Thu, 25 Jul 2013 17:19:40 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 4o3P1m0041YDfWL58oKf9d; Fri, 26 Jul 2013 00:19:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 4oKf1m00w3ZTu2S3goKf5M; Fri, 26 Jul 2013 00:19:39 +0000 Message-ID: <51F1C09B.2020205@alum.mit.edu> Date: Thu, 25 Jul 2013 20:19:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51EFF8E0.6010203@alum.mit.edu> <51EFFACD.7040905@nostrum.com> 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=1374797979; bh=2QPHOrjraR+h6jBRy1XTorIyvkqWB3w2l0H+FYUjSiI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QeIvaJiUiQgYfIpKKUz9XYZb2d4RaLuE/Tart2t2ffkHpvA7MhMO8wO99h/vMvDqt ejfjj30RMoUbManj7qOdi4dDRBXFFY/RNYehzAQr0kVigk/3Uic+oHs0BaSGG3uMuh MaAOKIcAG+WxZjj2JNPR1tHcdGnrX3C0VvRqDlcZ9Yh+7GmCj1a7N9UaPC9b393Zve VLCOmtBy/wAmCJe5Cjj6EsZCzRWLGMy2cs0YSTACVGoe7LHev5SO5GZl9yfO6jYyE/ L0DKtxML9C+XhGT7rQaozZz8CIB7V0VKNN0+eTgB0oM1gGdTxsolIs1KqD96i6Omq7 4LrL7d3IjWFVQ== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-roach-mmusic-unified-plan-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, 26 Jul 2013 00:19:47 -0000 On 7/25/13 7:41 PM, Cullen Jennings (fluffy) wrote: > > > On Jul 24, 2013, at 10:03 AM, Adam Roach wrote: > >> On 7/24/13 10:55, Paul Kyzivat wrote: >>> This seems to be excluded, except by sending a new O/A every time the speaker switches, which isn't feasible. If this means that CLUE can't represent capture-encodings as m-lines, then there is no benefit to CLUE for the unified plan over No Plan (Emil's multiple-sources draft). >> >> That's interesting. I wonder whether we should simply move to the RTP header extension described in section 3.2.1.1 as the primary means of correlation. It would seem to address the case you describe. >> >> /a > > SSRC can collide too so they might be wrong but the header extension does not have that problem. It seems to me the algorithm is roughly > > if you have header extension, use that, if not then if you know the SSRC use that, if not then if you have unique PTs, use that. Perhaps there are other things to use too but roughly those get used in that order. I commented on this before. You don't need to have an ordering. If the combination of things you have is unique, use that. If not, then you have a problem. Thanks, Paul From emil@sip-communicator.org Thu Jul 25 17:24: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 5E8FB21F8E97 for ; Thu, 25 Jul 2013 17:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=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 D8Ntc+GMKAIg for ; Thu, 25 Jul 2013 17:24:44 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 116E521F8DDD for ; Thu, 25 Jul 2013 17:24:43 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hi5so222579wib.1 for ; Thu, 25 Jul 2013 17:24:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=bWuF/Jy01gRFhCv9uS2gfmiPof5whYkUhgQn3W9ErXw=; b=ddMs3yqp4XDb3ios5vkhs1UUjltqmgmqLeGW6MTV/NlovXYVrfgPCtkrq49I65WP9l 5wEaB5U07ZUqhDQqYQUeD6LqksOidX9YVIAlHN4qbpgi/ho4bED8zec1E6LWaY+eERPD D5yyB3afkm94oK12Kfpf6qj0epRHTpdYmEVEu1m/hj22FdYLCrmVzx9sW38xG07C/P3d maHAKos5zuzlWolntCNrzzjDluHmKSRpcp8JiRDEIRLhsymrPWzxsKQLP13x3Hrk9+2q /rF08SvcHsn6ydOynWHJngfkBZYgX3yenSqVHPsPgAHPqCiyX4FKez1ZigpuTFebz86v 72nQ== X-Received: by 10.180.185.74 with SMTP id fa10mr3827775wic.26.1374798282314; Thu, 25 Jul 2013 17:24:42 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:fd7b:1632:360c:32df]) by mx.google.com with ESMTPSA id x6sm1265120wiy.8.2013.07.25.17.24.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 17:24:41 -0700 (PDT) Message-ID: <51F1C1C6.7030508@jitsi.org> Date: Fri, 26 Jul 2013 02:24:38 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Kyzivat References: <51F15BC0.2000401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C408F15@ESESSMB209.ericsson.se> <51F17512.8090700@jitsi.org> <51F184E8.40406@alum.mit.edu> <51F18DA9.1080509@jitsi.org> <51F19C9A.3040706@alum.mit.edu> <51F1A77F.10608@jitsi.org> <51F1B41A.3000700@alum.mit.edu> In-Reply-To: <51F1B41A.3000700@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmkARFMH7xeYguTYJjv+LfL4AOpaAYaDBx4OFkueaYLYeZlD6l5B0fNyBLyMQMD6xyH/Wis Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-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, 26 Jul 2013 00:24:48 -0000 On 26.07.13, 01:26, Paul Kyzivat wrote: > Emil, > > On 7/25/13 6:32 PM, Emil Ivov wrote: >> Hey Paul, >> >> On 25.07.13, 23:46, Paul Kyzivat wrote: >>> On 7/25/13 4:42 PM, Emil Ivov wrote: >>> >>>>>>> On 25.07.13, 19:09, Paul Kyzivat wrote: >>>>>>> >>>>>>> Section 4 says that trickled candidates are transported as INFO >>>>>>> payloads >>>>>>> containing SDP formatted according to ivov-mmusic-trickle-ice. But >>>>>>> AFAICT that draft doesn't specify this. >>>>>> >>>>>> Well, it just borrows the format from 5245 and says that this is >>>>>> how you >>>>>> represent trickled candidates. >>>>> >>>>> But all of that assumes a full SDP body. >>>> >>>> I don't see how the syntax of an "a=candidate" line depends on the full >>>> SDP body, so I don't see the problem with just pointing there. Again, I >>>> mean this only about syntax. >>> >>> My point is that 5245 never suggests that ICE will be represented in SDP >>> in anything but a full SDP body. >>> >>> If you said that you were proposing to send subsets of SDP as described >>> in 5245, that would make some sense. >> >> The section that deals with this is 9.1 >> >> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#section-9.1 >> >> The intention is exactly what you describe above. > > Maybe you intended that. But I don't find sufficient words in the doc to > determine what you mean. The words that seem to pertain to this are: > > Given that such lines do not provide a relationship between the > candidate and the m line that it relates to, signalling protocols > using trickle ICE MUST establish that relation themselves. This can > be done in one of two ways: using the m-line index, or an MID > [RFC3388]. The m-line index is a zero-based index, referring to the > Nth m-line in the SDP. The MID uses "media stream identification", > as defined in [RFC3388], to identify the m-line. > > So I'm supposed to infer that you are proposing to use a subset of SDP > from that??? No, you are not. This is the generic trickle ICE draft and it says: when using trickle with a specific protocol, make sure you match candidates to m= lines through use of MIDs. It can't say anything more here because XMPP would encode the MID value one way (i.e. using content names attributes), SIP another (using a=mid) and WebRTC apps in yet another (likely json). > Also, what does "signalling protocols using trickle ICE MUST establish > that relation themselves" *mean*? I hope the above answers your question. > Does it mean that you intend the INFO > message containing the trickle ice info in its body to specify the > m-line somewhere other than in the same body??? I don't understand this part. Didn't my previous mail clarify this? Here's an example: INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/sdp Content-Disposition: Info-Package Content-length: ... a=mid:1 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx a=mid:2 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx a=end-of-candidates That's the entire body and there are no m= lines in it. > I would expect that the body you send would include something to do > this. If you use mid, then the syntax to do so already exists, sort of. > If you use m-line index, then it doesn't. We kind of decided not to use "m=" line index in one of the previous meetings so we are only going for MID. The draft hasn't been updated since so it still refers to "m=" line index in a few locations but they will go. >>> (As long as you specify how to >>> select the subset.) >> >> The subset is an "a=candidate" line. I don't think select is the right >> word here though. You just encode an ICE candidate, as you would encode >> it for an SDP offer or answer. >> >>>>>>> Also the example in this section >>>>>>> shows an info payload that contains only a subset of SDP, and doesn't >>>>>>> conform to mime type application/sdp. >>>>>> >>>>>> Yup, should be application/sdpfrag. >>>>> >>>>> Well, AFAIK there is currently no such mime type. So its necessary to >>>>> define it. >>>> >>>> This is the point of the draft I pasted above: >>>> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00 >>>> >>>> Of course, it does need more work (by the way, help there is more than >>>> welcome so if you want to join just let me know). >>> >>> Oh, duh. That slipped right by me. But of course it is incomplete. >>> >>> I could help, once I understand what it needs to say. >> >> Great! >> >>> The first decision is: >> >> Did you miss something here? > > I forget. It doesn't matter. > >>>>> And while you could define a generic one, you have some specific >>>>> requirements about what this needs to contain, so you might want to >>>>> define application/trickle-ice-sdp with all the requisite rules. >>>> >>>> The original idea (which I believe came from Adam) was that this could >>>> be avoided in a way similar to how application/sipfrag does it. I >>>> basically specifies syntax (as a SIP subset) and leaves semantics to >>>> specs that are using it, like for example 3515 >>>> >>>> Do you see any reason why this couldn't work here? >>> >>> Its a choice. In the case of sipfrag, IIRC it was defined for use with >>> 3515. In that it isn't crucial what is in it. So it works there. >>> >>> In your case what goes in it is more critical. It can still be defined >>> this way. But it will take some care to get it right. >>> >>> The main thing is that it be done somewhere! >> >> Agreed! >> >>> Can an INFO trickle ICE candidates for more than one m-line? >> >> Yes. >> >>> If so, it gets messy. Consider a full SDP: >>> >>> ... >>> m=... >>> a=mid:1 >>> a=candidate:... >>> ... >>> m=... >>> a=candidate:... >>> a=mid:2 >>> a=candidate:... >>> >>> (AFAIK the above is entirely legal.) >>> >>> Now consider a sipfrag for trickle from the above: >>> >>> a=mid:1 >>> a=candidate:... >>> a=candidate:... >>> a=mid:2 >>> a=candidate:... >>> >>> Now, which candidates go with which m-line? So, I think your sdpfrag >>> needs special constraints that don't apply to ICE in full SDP. >> >> I think the problem with the above is that you are trying to present it >> as an extract from some pre-existing offer or answer, while it isn't. >> >> When you are trickling you find yourself in a situation where you have >> one or more newly learned candidates. You want to send those to the >> remote agent. >> >> To do this you group them by stream (as in "m=" line). For each group >> you start by creating an "a=mid:x" attribute that matches the one from >> the "m=" line that created the stream. You then create and append >> "a=candidate" lines for every candidate in that group. >> >> That's it. > > I thought that is what you had in mind. > > But you have said you want to use application/sdpfrag, which means it > should be viewed as a subset of a full SDP. Doesn't this apply to the INFO example that I pasted above? Why could it not be viewed as a subset of *some* valid full SDP? > And that is especially so if > you intend to reference m-lines in an SDP No, there's no such intention any more. > , but don't want to include > them. And you haven't defined any new ordering rules for lines other > than what exist for SDP. And SDP allows the ordering I show above, which > doesn't work for you. I agree that there's no such definition in the draft. I did provide example rules in a couple of paragraphs above though. Do you see a problem using this logic as basis for defining the ordering in trickle-ice-sip? > I'll also mention that I think you need to explicitly reference the SDP > offer or answer that this trickle updates. Probably by replicating the > o-line from that SDP. That's a good point. We do need this for SIP. I'll make sure we add it. > So there are some significant syntax rules that need to be followed > here. I would expect something like: > > - must start with o-line of the SDP it is updating > - has one or more "media sections" > - each media section begins with an a:mid line, referencing > a mid defined in the referenced SDP > - each a:mid line is followed by one or more a:candidate lines > ... Sounds great to me! > If going that way, then I think it is better to define a mime type that > consists of exactly this syntax, with some extensibility hooks. Are you proposing this because you think this MIME type could be reused by someone else? Personally I don't really mind. However, if we leave sdpfrag with the current intention (i.e. any SDP line or combination of lines work) and then define the specifics in trickle-ice-sip, then we have a MIME type for the a=candidate lines that come out of WebRTC browsers, should anyone every need this. Cheers, Emil > > Thanks, > Paul > >> The receiving peer does the opposite: it parses the "a=mid:x" line, it >> finds the stream object that it refers to, then parses all the >> candidates and adds them there. >> >> Does this make sense? >> >> Emil >> >> >>> >>> Thanks, >>> Paul >>> >>>> Emil >>>> >>>>>>> Section 5.6 again references the trickle-ice draft (section 4) for >>>>>>> definition of the body of the info message, but that section of that >>>>>>> draft doesn't contain any such definition. >>>>>> >>>>>> Will need to fix. >>>>>> >>>>>>> Aside from that, it occurs to me that trickle-ice, and for that >>>>>>> matter >>>>>>> ice in sip even without trickle, is a good candidate for >>>>>>> preconditions. >>>>>>> The use of preconditions could eliminate the need for half trickle. >>>>>>> This >>>>>>> would of course require a new precondition type, but that is doable. >>>>>> >>>>>> Hmmm ... that's a good point! >>>>>> >>>>>>> By using preconditions, you can establish the dialog without alerting >>>>>>> the callee. Then the alert can be deferred until at least one >>>>>>> workable >>>>>>> path has been detected. >>>>>>> >>>>>>> (But I suppose the hate for preconditions is so great that this is >>>>>>> not >>>>>>> to be considered.) >>>>>> >>>>>> Well, it doesn't have to be mandatory ... >>>>>> >>>>>> Emil >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> >>>>> . >>>>> >>>> >>> >>> >> > > -- https://jitsi.org From christer.holmberg@ericsson.com Fri Jul 26 01:30: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 5C56D21F8F78 for ; Fri, 26 Jul 2013 01:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-1.597, 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 t+Okay8LwRlM for ; Fri, 26 Jul 2013 01:30:16 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5321F8613 for ; Fri, 26 Jul 2013 01:30:00 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-9a-51f233866e29 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 06.B0.11907.68332F15; Fri, 26 Jul 2013 10:29:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 10:29:58 +0200 From: Christer Holmberg To: Paul Kyzivat , Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOhsxOmoY6im5NjkKbz0BNRi4Q7ZlyXsGAgAOQsoCAALeVVg== Date: Fri, 26 Jul 2013 08:29:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40A57F@ESESSMB209.ericsson.se> References: <51D43186.2010907@jitsi.org> <51D6D456.7090900@jitsi.org> <51DAE06C.1030203@alum.mit.edu> <51DC9180.5070407@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F2106@ESESSMB209.ericsson.se> <51EC2EF7.1090000@jitsi.org> <51EC5569.60106@alum.mit.edu> <51EC5B75.1020306@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F366B@ESESSMB209.ericsson.se> <51ED0C24.30206@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C3F685F@ESESSMB209.ericsson.se> <51EEB807.6010704@jitsi.org>,<51F1B5A7.1060400@alum.mit.edu> In-Reply-To: <51F1B5A7.1060400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40A57FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvrW678adAgzuf2S3W7JzAYjF1+WMW ixUbDrBa7Npe48Di8ff9ByaPJUt+Mnn8fxPoceP2e+YAligum5TUnMyy1CJ9uwSujKuLlzAV LFSuePrsAksDY5tcFyMnh4SAiUR3YwsLhC0mceHeejYQW0jgKKPEsq15XYxcQPYSRomnV1qA EhwcbAIWEt3/tEFMEQFXiXnPFEHKmQXiJP7fvMcEYgsLGEs8PNbIBFFiIvH6ihtIWETASeLL zElg01kEVCW2zHoIZvMK+Eo8f3CGFWLrbVaJGZv1QWxOAR2JxRcnMoPYjECXfT+1hglilbjE rSfzmSAuFpBYsuc8M4QtKvHy8T9WiJp8iXX73kDNF5Q4OfMJywRGkVlI2mchKZuFpAwiridx Y+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9i5ChOLU7KTTcy2MQIjK2DW35b7GC8/NfmEKM0 B4uSOO8WvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjN/yxy/LB/xoFEdY13zlWC2h3H kw+KzlXeE35rv+/tA5Epk2IeLBJV6v7k8WnXo9i0nJVFmU7b3p69oZqu+1KJYelTBa5VlU3v wuYdqDgsm7ns2kmXCXMfPN+ez1O2v26zSkyjy4zSArepNza/m/YhfmKE4IcNR2ebhm8767de 52HJut9Hvz5/oMRSnJFoqMVcVJwIAFwFChB7AgAA Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 26 Jul 2013 08:30:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40A57FESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am not sure we would need to define anything new - we could simply say th= at Trickle ICE UAs don't send Offer/Answers in PRACKSs :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: Emil Ivov [emcho@jitsi.org] CC: Christer Holmberg [christer.holmberg@ericsson.com]; Stach, Thomas [thom= as.stach@siemens-enterprise.com]; mmusic@ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions On 7/23/13 1:06 PM, Emil Ivov wrote: > I actually think we could pull this off with simple PRACKs. Only, rather > than using the "100rel" tag we go for something like "100rel-lite" which > could be defined to indicate that a UA supports PRACK but only for > reliability (and PRACK bodies are not allowed). This is crazy! Every new option presents backward compatibility issues, implementation issues, ... It doesn't make sense to define a new option that is a subset of a long time existing option. This is *not* rocket science. Just tell people they need to support 100rel as a precondition for trickle ICE. If they find trickle ice worthwhile they can implement it. I'd be amazed if there are any SBCs that don't support PRACK. (But Hadriel will fill us in about that.) Thanks, Paul --_000_7594FB04B1934943A5C02806D1A2204B1C40A57FESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am not sure we would need to define anything = new - we could simply say that Trickle ICE UAs don't send Offer/Answers in = PRACKSs :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: Emil Ivov [emcho@jitsi.org]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; Stach, Thoma= s [thomas.stach@siemens-enterprise.com]; mmusic@ietf.org [mmusic@ietf.org]<= br> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
On 7/23/13 1:06 PM, Emil Ivov wrote:

> I actually think we could pull this off with simple PRACKs. Only, rath= er
> than using the "100rel" tag we go for something like "1= 00rel-lite" which
> could be defined to indicate that a UA supports PRACK but only for
> reliability (and PRACK bodies are not allowed).

This is crazy!

Every new option presents backward compatibility issues, implementation issues, ...

It doesn't make sense to define a new option that is a subset of a long time existing option. This is *not* rocket science. Just tell people
they need to support 100rel as a precondition for trickle ICE. If they
find trickle ice worthwhile they can implement it.

I'd be amazed if there are any SBCs that don't support PRACK. (But
Hadriel will fill us in about that.)

        Thanks,
        Paul

 --_000_7594FB04B1934943A5C02806D1A2204B1C40A57FESESSMB209erics_-- From fluffy@cisco.com Fri Jul 26 05:04: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 52E7121F8C9D for ; Fri, 26 Jul 2013 05:04:57 -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 nbOT0nVytyLG for ; Fri, 26 Jul 2013 05:04:51 -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 92F9E21F89A5 for ; Fri, 26 Jul 2013 05:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1374840291; x=1376049891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nicQR7dSM8lkCvLa9TQ6zwRfXRTnGfpPKXoq9AGRZis=; b=EkIQIRzOpq5oDU0l0hbJ2ek/v1+6+7vsKQckS/d1pMSSDgX2QWJ1v5wn bJDBZVbvOrRGFED552ocdRn6p+Kuus8N8exVVkXBYw9q4IXpPthMPZear LdnM7Qv3G8vl+lddb0og1z2WngfGOssWzwxvHxdh7GcDRxewiCvAoPly1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJFk8lGtJV2b/2dsb2JhbABaDoJ4gQW9RIEWFnSCJAEBAQMBOj8FCwIBCA4KChQQMiUCBA4FCIgCBrkVj0oCMQeDFm8DlAiVI4JWPoIq X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239838024" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2013 12:04:51 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QC4p2R031811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 12:04:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 07:04:50 -0500 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [MMUSIC] draft-roach-mmusic-unified-plan-00 Thread-Index: AQHOifhUWXK+VS/nCkSjdG4nezl1sg== Date: Fri, 26 Jul 2013 12:04:50 +0000 Message-ID: References: <51EFF8E0.6010203@alum.mit.edu> <51EFFACD.7040905@nostrum.com> <51F1C09B.2020205@alum.mit.edu> In-Reply-To: <51F1C09B.2020205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] draft-roach-mmusic-unified-plan-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, 26 Jul 2013 12:04:57 -0000 On Jul 25, 2013, at 6:19 PM, Paul Kyzivat wrote: > On 7/25/13 7:41 PM, Cullen Jennings (fluffy) wrote: >>=20 >>=20 >> On Jul 24, 2013, at 10:03 AM, Adam Roach wrote: >>=20 >>> On 7/24/13 10:55, Paul Kyzivat wrote: >>>> This seems to be excluded, except by sending a new O/A every time the = speaker switches, which isn't feasible. If this means that CLUE can't repre= sent capture-encodings as m-lines, then there is no benefit to CLUE for the= unified plan over No Plan (Emil's multiple-sources draft). >>>=20 >>> That's interesting. I wonder whether we should simply move to the RTP h= eader extension described in section 3.2.1.1 as the primary means of correl= ation. It would seem to address the case you describe. >>>=20 >>> /a >>=20 >> SSRC can collide too so they might be wrong but the header extension do= es not have that problem. It seems to me the algorithm is roughly >>=20 >> if you have header extension, use that, if not then if you know the SSR= C use that, if not then if you have unique PTs, use that. Perhaps there are= other things to use too but roughly those get used in that order. >=20 > I commented on this before. You don't need to have an ordering. >=20 > If the combination of things you have is unique, use that. If not, then y= ou have a problem. >=20 That would be fine with me too.=20 From vimandav@cisco.com Fri Jul 26 07:09: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 6955111E80E4 for ; Fri, 26 Jul 2013 07:09:58 -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, HTML_MESSAGE=0.001, 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 TGqpKoLtaE36 for ; Fri, 26 Jul 2013 07:09:53 -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 3ACB321F99C1 for ; Fri, 26 Jul 2013 07:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3432; q=dns/txt; s=iport; t=1374847788; x=1376057388; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ONNWX/28dRHYl6MQ2wbDONKP2P2TibEP9CZHAH34nCc=; b=Gks4dt87eIO4237JqUPyLfW1hXHDVGtIuaeDXNDEuG1fqwJbc5lpwZJv 48NLQ96D675PIgSj3BE2GfD+DOS7pSKVciMU8aUhwLvTL8ITJp7gzT2rj JYY0RwH/wGk7MDTNGThCO+5GGVqSSL6T1rRKKbpPzcX3lsDHpnW7By8wC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAKCB8lGtJV2c/2dsb2JhbABbDoI0RDVQvUOBFxZ0giQBAQEEeRIBCAQNAwECCx05FAkIAgQBDQUIiAi5GI9MIBEHCYMNbwOpK4JWPoIq X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208,217";a="236880940" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2013 14:09:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6QE9l5V008882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 14:09:47 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.96]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 09:09:47 -0500 From: "Vijaya Mandava (vimandav)" To: Christer Holmberg , Paul Kyzivat , Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSaLa5Hh3VhE64hO3afq874plU1OAAgAGiagCABGacgIAAbIEAgAHtwYCAABaEAIASioUAgAAS1ICAAC3VgIAABzWAgACNhwCAAEUZAIAACLAAgAH1ZICAA5CygIAAlg0AgAAb4YA= Date: Fri, 26 Jul 2013 14:09:46 +0000 Message-ID: <1CDFD781608D924094E43F573C3519610230DAF3@xmb-rcd-x13.cisco.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C40A57F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.173.69] Content-Type: multipart/alternative; boundary="_000_1CDFD781608D924094E43F573C3519610230DAF3xmbrcdx13ciscoc_" MIME-Version: 1.0 Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 26 Jul 2013 14:09:58 -0000 --_000_1CDFD781608D924094E43F573C3519610230DAF3xmbrcdx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To add more to this - PRACK can be enabled or disabled. Trickle Ice UA's would not be affected by= this, Since we rely on INFOs to send trickled candidates. Thanks, Vijaya From: Christer Holmberg > Date: Friday, July 26, 2013 4:29 AM To: Paul Kyzivat >, Emi= l Ivov > Cc: "mmusic_ietf.org" > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions I am not sure we would need to define anything new - we could simply say th= at Trickle ICE UAs don't send Offer/Answers in PRACKSs :) --_000_1CDFD781608D924094E43F573C3519610230DAF3xmbrcdx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8E796032090E00428C291F8F8830495A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
To add more to this -
PRACK can be enabled or disabled. Trickle Ice UA's would not be affect= ed by this, Since we rely on INFOs to send trickled candidates.

Thanks,
Vijaya

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, July 26, 2013 4:29 AM=
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Emil Ivov <emcho@jitsi.org>
Cc: "mmusic_ietf.org" <= ;mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE f= or SIP Questions

I am not sure we would need to define anything new -= we could simply say that Trickle ICE UAs don't send Offer/Answers in PRACK= Ss :)

 --_000_1CDFD781608D924094E43F573C3519610230DAF3xmbrcdx13ciscoc_-- From partha@parthasarathi.co.in Fri Jul 26 11:03: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 0106821F949F for ; Fri, 26 Jul 2013 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 HBe8IoX-msan for ; Fri, 26 Jul 2013 11:02:57 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6421F8DE3 for ; Fri, 26 Jul 2013 11:02:51 -0700 (PDT) Received: from userPC (unknown [122.179.107.157]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 00987868854; Fri, 26 Jul 2013 18:02:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374861770; bh=2M43q/rQ6UZC4Zar0DSj5RNCXqbtypvGGf6glA1BAWQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EgvrdHtL08Pp1Jj4EhlLuVJr3vWhh9vp/VUl6khwzTPOfjoAqnHbAh+BV0e89GWNe MdJMJ93W2lAcLECVbvVYbc+Y/4xZmm2a1kmFiUOiJBt+/ppT9cW236oAtbgjqEYhWQ WpAm97SRj0sTh5ZRWieuii8ZhHg9PeknXkzA+B8k= From: "Parthasarathi R" To: "'Emil Ivov'" , "'MMUSIC IETF WG'" References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <51F03DC8.70908@jitsi.org> <00d401ce894e$70aa81c0$51ff8540$@co.in> <51F15478.3060104@jitsi.org> In-Reply-To: <51F15478.3060104@jitsi.org> Date: Fri, 26 Jul 2013 23:32:40 +0530 Message-ID: <009301ce8a2a$54995ec0$fdcc1c40$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6JVWiSsRcuVEzCRmWbkqNTTdREgAA0tdPg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0204.51F2B9CA.006B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.153 Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 26 Jul 2013 18:03:02 -0000 Hi Emil, Please read inline. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Thursday, July 25, 2013 10:08 PM > To: 'MMUSIC IETF WG' > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > Hey Partha, > > On 25.07.13, 17:48, Parthasarathi R wrote: > > Hi Emil, > > > > In the mentioned situation, different To-tag with same contact header > for > > trickled SDP, So there will be no "N" locations. > > Having the same contact header does not automatically suggest that this > is somehow a fake fork (unless I am missing the text that says this in > 3261). You could potentially have this if the fork is done by a B2BUA > or > a PSTN gateway for example. > The discussion is not about fake fork. The contact indicates location of the UAS. In case of PSTN & B2BUA as UAS, PSTN & B2BUA contact SIP URI is the location for UAC. From the UAC perspective, there is no "N" location in UAS due to fake forking as you expect. > > My reading of the draft is that this draft is not required in case > UPDATE > > (RFC 3311) method is supported. UPDATE with SDP will update trickle > > candidate within 18x. > > Use of UPDATE has already been discussed and we pretty much agreed not > to go that way. > > A mail from Alan and the preceding discussion: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html > > A follow up with a nice summary from Dale: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html Sorry for the delay discussion. I'm still seeing few aspects Missing from the discussion. I'll write the separate mail thread for this > > > The aim of the draft is to support Trickle ICE for SIP user agent > which does > > not support RFC 3311 for last 11 years. AFAIK, different "to tag" is > the > > simpler way to solve the problem in UAS side. I have concern w.r.t > INFO > > mechanism as it adds one method for handling SDP and complicates the > > existing SDP O/A handling (RFC 6337). > > That's the thing, trickle ICE is not part of Offer/Answer. It's a > separate channel for agent-to-agent communication. Use of SDP is just a > convenient coincidence. > > > Including Christer in this mail thread as he replied in the parallel > mail > > thread. > > I believe he is on the list I don't think that's an issue :) > > Cheers, > Emil > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: Thursday, July 25, 2013 2:19 AM > >> To: Cullen Jennings (fluffy) > >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; > MMUSIC > >> IETF WG > >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > >> > >> > >> > >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > >>> > >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) > >> wrote: > >>> > >>>> 180 with different to-tag would mean call is forked. > >>>> If uac side do not support call forking, then we cannot use this > 180 > >>>> response to collect trickled candidates. > >>> > >>> If it is a UAC, it supports this so I don't see the problem. > >> > >> One problem is that the UAC could support it to the extent of making > it > >> visible to the user: > >> > >> "Your contact is being alerted on these N locations" > >> > >> And of course there's also the fact that we would be creating > several > >> dialogs per call, that we'd then need to clean and garbage collect. > >> > >> Why would we want to go there? > >> > >> Emil > >> > >> -- > >> https://jitsi.org > > > > > > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Jul 26 11:44: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 A357821F92B8 for ; Fri, 26 Jul 2013 11:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.300, 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 xI54MNTeDTfx for ; Fri, 26 Jul 2013 11:43:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5711E8118 for ; Fri, 26 Jul 2013 11:43:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-c7-51f2c367e5d9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BD.4C.05990.763C2F15; Fri, 26 Jul 2013 20:43:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 20:43:42 +0200 From: Christer Holmberg To: "Vijaya Mandava (vimandav)" , Paul Kyzivat , Emil Ivov Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOhsxOmoY6im5NjkKbz0BNRi4Q7ZlyXsGAgAOQsoCAALeVVoAAPWgAgABuE+o= Date: Fri, 26 Jul 2013 18:43:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40AC1A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C40A57F@ESESSMB209.ericsson.se>, <1CDFD781608D924094E43F573C3519610230DAF3@xmb-rcd-x13.cisco.com> In-Reply-To: <1CDFD781608D924094E43F573C3519610230DAF3@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40AC1AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvrW764U+BBg2/JC3W7JzAYjF1+WMW ixUbDrBaNE87weLA4vH3/Qcmjym/N7J6LFnyk8nj/5vAAJYoLpuU1JzMstQifbsEroxH7S4F L1QqXs06wdrAuEOhi5GTQ0LAROJtyxMmCFtM4sK99WxdjFwcQgKHGSUer1rNCOEsYZTYMX0H axcjBwebgIVE9z9tkAYRgUqJzRt2sYDYzAKqEq+nfmcFsYUFjCUeHmtkAikXAVrw+oobRLmf xI71x8BKWIDKn55eDdbKK+Arsbv3MCvEqj5Gif/v54MVcQIlrs7/A1bECHTc91NrmCB2iUvc ejIf6mgBiSV7zjND2KISLx//Y4WoyZdY297MDLFAUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC 3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxoEyMwvg5u+a26g/HOOZFDjNIcLEri vJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKxsvua7Li2gu11rO9+TbROZbFa36rwI unZ8670X/7/NfbHbdt4xia0ScvaHRa8xmLP94Dko4nPWIfho26MKhgUeRddVbuq97RA0mSev 5n/8vqyspeucVZb7D5618OZY/Uo7OND/wWnBy9uNXk88n7KYT2P1ice/co/7JBu1qwdX75fc Hu19tUWJpTgj0VCLuag4EQBMCIjWfQIAAA== Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 26 Jul 2013 18:44:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40AC1AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Wasn't this discussion started due to the fact that the UAS cannot send INF= O until it knows that a dialog has been established? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Vijaya Mandava (vimandav) [vimandav@cisco.com] To: Christer Holmberg [christer.holmberg@ericsson.com]; Paul Kyzivat [pkyzi= vat@alum.mit.edu]; Emil Ivov [emcho@jitsi.org] CC: mmusic_ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions To add more to this - PRACK can be enabled or disabled. Trickle Ice UA's would not be affected by= this, Since we rely on INFOs to send trickled candidates. Thanks, Vijaya From: Christer Holmberg > Date: Friday, July 26, 2013 4:29 AM To: Paul Kyzivat >, Emi= l Ivov > Cc: "mmusic_ietf.org" > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions I am not sure we would need to define anything new - we could simply say th= at Trickle ICE UAs don't send Offer/Answers in PRACKSs :) --_000_7594FB04B1934943A5C02806D1A2204B1C40AC1AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Wasn't this discussion started due to the fact that the UAS cannot sen= d INFO until it knows that a dialog has been established?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Vijaya Mandava (vimandav) [vimandav@cisco.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]; Paul Kyzivat= [pkyzivat@alum.mit.edu]; Emil Ivov [emcho@jitsi.org]
CC: mmusic_ietf.org [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
To add more to this -
PRACK can be enabled or disabled. Trickle Ice UA's would not be affect= ed by this, Since we rely on INFOs to send trickled candidates.

Thanks,
Vijaya

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, July 26, 2013 4:29 AM=
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Emil Ivov <emcho@jitsi.org>
Cc: "mmusic_ietf.org" <= ;mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE f= or SIP Questions

I am not sure we would need to define anything new -= we could simply say that Trickle ICE UAs don't send Offer/Answers in PRACK= Ss :)

--_000_7594FB04B1934943A5C02806D1A2204B1C40AC1AESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Jul 26 11:49: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 7B66211E8138 for ; Fri, 26 Jul 2013 11:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.285, 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 jihiknhU5tTk for ; Fri, 26 Jul 2013 11:49:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A265D11E8149 for ; Fri, 26 Jul 2013 11:49:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-82-51f2c49bea31 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9B.71.00725.B94C2F15; Fri, 26 Jul 2013 20:48:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 20:48:56 +0200 From: Christer Holmberg To: Parthasarathi R , 'Emil Ivov' , 'MMUSIC IETF WG' Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOd/eSpf9rBUBElUWwJCcck0Z1VZlzKl8AgABpUQCAAARAgIAAc7GAgAAYYYCAABo/gIAADskAgAE+VYCAAA3kAIABqekAgAAudx4= Date: Fri, 26 Jul 2013 18:48:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40ACA8@ESESSMB209.ericsson.se> References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <51F03DC8.70908@jitsi.org> <00d401ce894e$70aa81c0$51ff8540$@co.in> <51F15478.3060104@jitsi.org>,<009301ce8a2a$54995ec0$fdcc1c40$@co.in> In-Reply-To: <009301ce8a2a$54995ec0$fdcc1c40$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40ACA8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre7sI58CDdYulbJYs3MCi8XU5Y9Z LCZ/6mN1YPZYsuQnk8f/N4EeH+Z/YQ9gjuKySUnNySxLLdK3S+DKOLTzFFPB9/iKWUf1GxjP +HcxcnJICJhIrDn7hR3CFpO4cG89WxcjF4eQwGFGic4Vq9khnCWMEi2Xuhi7GDk42AQsJLr/ aYM0iAiUSsyYsIUNxBYWMJZ4eKyRCaREBGjo6ytuECVlEgc6msDmswioSpzb+pgZxOYV8JW4 N/EM1K6ZTBL9q68zgiQ4gXoXPjkL1sAIdND3U2uYQGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl 43+sEDX5EktuNbFBLBCUODnzCcsERuFZSNpnISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOP mZDFFzCyr2Jkz03MzEkvN9zECIyZg1t+6+5gPHVO5BCjNAeLkjjvJr0zgUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYi5l2pwR5MCzpd6mTsnijLWTNa7vPMpAnYnZWQp1Q7c+3yUw7902P UZKuK7h8b6L8ucgEj+/ZPjo7L5fwfbhr41IwiXtR7bTJG+c+XuU33TyyZvnUH4kK4la+khX3 rZRXqcm4yM65LfD0RkPmV9HJ55o2qP6K5PHOvsequKox5tr8bdun9rMqsRRnJBpqMRcVJwIA DTRmsmcCAAA= Subject: Re: [MMUSIC] Trickle ICE for SIP 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, 26 Jul 2013 18:49:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40ACA8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Two different UASs could have the same Contact value, if they e.g. are loca= ted in private networks. Of course, you could use the instance-id, but then we would need to require= support of that extension... Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: 'Emil Ivov' [emcho@jitsi.org]; 'MMUSIC IETF WG' [mm= usic@ietf.org] Subject: Re: [MMUSIC] Trickle ICE for SIP Questions Hi Emil, Please read inline. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Thursday, July 25, 2013 10:08 PM > To: 'MMUSIC IETF WG' > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > Hey Partha, > > On 25.07.13, 17:48, Parthasarathi R wrote: > > Hi Emil, > > > > In the mentioned situation, different To-tag with same contact header > for > > trickled SDP, So there will be no "N" locations. > > Having the same contact header does not automatically suggest that this > is somehow a fake fork (unless I am missing the text that says this in > 3261). You could potentially have this if the fork is done by a B2BUA > or > a PSTN gateway for example. > The discussion is not about fake fork. The contact indicates location of the UAS. In case of PSTN & B2BUA as UAS, PSTN & B2BUA contact SIP URI is the location for UAC. From the UAC perspective, there is no "N" location in UAS due to fake forking as you expect. > > My reading of the draft is that this draft is not required in case > UPDATE > > (RFC 3311) method is supported. UPDATE with SDP will update trickle > > candidate within 18x. > > Use of UPDATE has already been discussed and we pretty much agreed not > to go that way. > > A mail from Alan and the preceding discussion: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html > > A follow up with a nice summary from Dale: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html Sorry for the delay discussion. I'm still seeing few aspects Missing from the discussion. I'll write the separate mail thread for this > > > The aim of the draft is to support Trickle ICE for SIP user agent > which does > > not support RFC 3311 for last 11 years. AFAIK, different "to tag" is > the > > simpler way to solve the problem in UAS side. I have concern w.r.t > INFO > > mechanism as it adds one method for handling SDP and complicates the > > existing SDP O/A handling (RFC 6337). > > That's the thing, trickle ICE is not part of Offer/Answer. It's a > separate channel for agent-to-agent communication. Use of SDP is just a > convenient coincidence. > > > Including Christer in this mail thread as he replied in the parallel > mail > > thread. > > I believe he is on the list I don't think that's an issue :) > > Cheers, > Emil > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: Thursday, July 25, 2013 2:19 AM > >> To: Cullen Jennings (fluffy) > >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; > MMUSIC > >> IETF WG > >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > >> > >> > >> > >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > >>> > >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) > >> wrote: > >>> > >>>> 180 with different to-tag would mean call is forked. > >>>> If uac side do not support call forking, then we cannot use this > 180 > >>>> response to collect trickled candidates. > >>> > >>> If it is a UAC, it supports this so I don't see the problem. > >> > >> One problem is that the UAC could support it to the extent of making > it > >> visible to the user: > >> > >> "Your contact is being alerted on these N locations" > >> > >> And of course there's also the fact that we would be creating > several > >> dialogs per call, that we'd then need to clean and garbage collect. > >> > >> Why would we want to go there? > >> > >> Emil > >> > >> -- > >> https://jitsi.org > > > > > > -- > https://jitsi.org > _______________________________________________ > 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 --_000_7594FB04B1934943A5C02806D1A2204B1C40ACA8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,
 
Two different UASs could have the same Contact value, if they e.g. are= located in private networks.
 
Of course, you could use the instance-id, but then we would need to re= quire support of that extension...
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Emil Ivov&apos; [emcho@jitsi.org]; &apos;MMUSI= C IETF WG&apos; [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
Hi Emil,

Please read inline.

Thanks
Partha

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: Thursday, July 25, 2013 10:08 PM
> To: 'MMUSIC IETF WG'
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
>
> Hey Partha,
>
> On 25.07.13, 17:48, Parthasarathi R wrote:
> > Hi Emil,
> >
> > In the mentioned situation, different To-tag with same contact he= ader
> for
> > trickled SDP, So there will be no "N" locations.
>
> Having the same contact header does not automatically suggest that thi= s
> is somehow a fake fork (unless I am missing the text that says this in=
> 3261). You could potentially have this if the fork is done by a B2BUA<= br> > or
> a PSTN gateway for example.
>
<Partha>The discussion is not about fake fork. The contact indicates<= br> location of the UAS. In case of PSTN & B2BUA as UAS, PSTN & B2BUA c= ontact
SIP URI is the location for UAC. From the UAC perspective, there is no &quo= t;N"
location in UAS due to fake forking as you expect.</Partha>

> > My reading of the draft is that this draft is not required in cas= e
> UPDATE
> > (RFC 3311) method is supported. UPDATE with SDP will update trick= le
> > candidate within 18x.
>
> Use of UPDATE has already been discussed and we pretty much agreed not=
> to go that way.
>
> A mail from Alan and the preceding discussion:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html
>
> A follow up with a nice summary from Dale:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html

<Partha> Sorry for the delay discussion. I'm still seeing few aspects=  
Missing from the discussion. I'll write the separate mail thread for this </Partha>

>
> > The aim of the draft is to support Trickle ICE for SIP user agent=
> which does
> > not support RFC 3311 for last 11 years. AFAIK, different "to= tag" is
> the
> > simpler way to solve the problem in UAS side. I have concern w.r.= t
> INFO
> > mechanism as it adds one method for handling SDP and complicates = the
> > existing SDP O/A handling (RFC 6337).
>
> That's the thing, trickle ICE is not part of Offer/Answer. It's a
> separate channel for agent-to-agent communication. Use of SDP is just = a
> convenient coincidence.
>
> > Including Christer in this mail thread as he replied in the paral= lel
> mail
> > thread.
>
> I believe he is on the list I don't think that's an issue :)
>
> Cheers,
> Emil
> >
> > Thanks
> > Partha
> >
> >> -----Original Message-----
> >> From: Emil Ivov [mailto:em= cho@jitsi.org]
> >> Sent: Thursday, July 25, 2013 2:19 AM
> >> To: Cullen Jennings (fluffy)
> >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston= ;
> MMUSIC
> >> IETF WG
> >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> >>
> >>
> >>
> >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote:
> >>>
> >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) > >> <vimandav@cisco.com> wrote:
> >>>
> >>>> 180 with different to-tag would mean call is forked.<= br> > >>>> If uac side do not support call forking, then we cann= ot use this
> 180
> >>>> response to collect trickled candidates.
> >>>
> >>> If it is a UAC, it supports this so I don't see the probl= em.
> >>
> >> One problem is that the UAC could support it to the extent of= making
> it
> >> visible to the user:
> >>
> >>     "Your contact is being alerted o= n these N locations"
> >>
> >> And of course there's also the fact that we would be creating=
> several
> >> dialogs per call, that we'd then need to clean and garbage co= llect.
> >>
> >> Why would we want to go there?
> >>
> >> Emil
> >>
> >> --
> >> https://jitsi.org
> >
> >
>
> --
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C40ACA8ESESSMB209erics_-- From ari.keranen@ericsson.com Sat Jul 27 01:58: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 D2D8321F99EB for ; Sat, 27 Jul 2013 01:58:42 -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 fFHHMmd09OLX for ; Sat, 27 Jul 2013 01:58:36 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 153A921F9DD6 for ; Sat, 27 Jul 2013 01:58:35 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-ab-51f38bb44a88 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AA.22.11907.4BB83F15; Sat, 27 Jul 2013 10:58:28 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Sat, 27 Jul 2013 10:58:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 31CEF11043A; Sat, 27 Jul 2013 11:58:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DC4D85578E; Sat, 27 Jul 2013 11:58:23 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 970E85577A; Sat, 27 Jul 2013 11:58:23 +0300 (EEST) Message-ID: <51F38BD5.8020203@ericsson.com> Date: Sat, 27 Jul 2013 11:59:01 +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/20130620 Thunderbird/17.0.7 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+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvre6W7s+BBg8WaVm8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK6Pr6grGgieMFet3dDE3MK5j7GLk5JAQMJFo nTuTCcIWk7hwbz1bFyMXh5DAUUaJ56efs0I46xklXj5Zzwzh7GWUWHmyjxHCWccosevmeShn BaNE97EDQA4HB6+AtsTnLfkgJouAqsTnhyIgK9gE7CVuTrjODhIWFUiWeHnECCTMKyAocXLm ExYQW0RARmLvps3MIDYz0JDZd2aBXScsoCWx/NVLFoi4rcSFOdehbHmJ7W/nMEN8oCZx9dwm MFsIaOvVf68YJzAKz0KyYhaS9llI2hcwMq9i5ChOLU7KTTcy2MQIDOKDW35b7GC8/NfmEKM0 B4uSOO8WvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhinXa1T1V57creXZ5kG3wIDwZkG /CYivJUuu99wrjSa3nl5ki3z5iO/5h93Mju4Iin7xfR199X+eLzhP2x8KpJzJmMGE8dX7w9v X7zMjroa82KH0atte2vVNi9cP+PdLntD7pDtLY8E57ApOxxwbGFvrGhLyXigvHl5rK6dGOfW i9EHpzroizUpsRRnJBpqMRcVJwIA2OnRzDACAAA= Cc: Flemming Andreasen Subject: [MMUSIC] Note takers for MMUSIC at IETF 87 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 08:58:43 -0000 Hi all, We are looking for two note takers and a jabber scribe for the MMUSIC sessions at the Berlin meeting. If you are attending and would be able to take notes, please contact the chairs. Thanks, Ari & Flemming From harald@alvestrand.no Sat Jul 27 08:49: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 3E13921F9B21 for ; Sat, 27 Jul 2013 08:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=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 quozAaC7nIZS for ; Sat, 27 Jul 2013 08:49:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5421F9B19 for ; Sat, 27 Jul 2013 08:49:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 387BF39E199 for ; Sat, 27 Jul 2013 17:49:36 +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 L6bUQjnC9pQ7 for ; Sat, 27 Jul 2013 17:49:35 +0200 (CEST) Received: from [10.0.0.79] (unknown [91.113.173.59]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1D31D39E17B for ; Sat, 27 Jul 2013 17:49:35 +0200 (CEST) Message-ID: <51F3EC0E.7030607@alvestrand.no> Date: Sat, 27 Jul 2013 17:49:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> In-Reply-To: <51F046A9.5010207@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sat, 27 Jul 2013 15:49:42 -0000 On 07/24/2013 11:27 PM, Adam Roach wrote: > On 7/24/13 16:17, Emil Ivov wrote: >> >> >> On 24.07.13, 20:31, Eric Rescorla wrote: >>> >>> It depends on the context obviously. But in the case of (for >>> instance) a >>> Hangouts >>> like system if the conference bridge were the offerer, it would send a >>> pile of >>> m-lines with only one being sendrecv (or maybe even recvonly) for the >>> user's media and the rest being sendonly. >> >> Sorry, I am still not getting it. How does it know exactly how many >> "m=" lines to place in a=sendrecv? > > I think you need to re-read and meditate on section 5.1 of RFC 3264. > This stuff is actually pretty well defined, and I'm not sure having an > on-list tutorial is ideal. > > Your follow-up questions are likely answered in section 6.1 of that > same document. Adam, I couldn't find anything in those sections that addressed the question either, so either I'm as uneducated in RFC 3264 as Eric, or we're talking about 2 different questions. I perceive the question to be a variant of the scenario that's explicitly outlined in the -unified- draft in section 3.5: 3.5. Negotiation of Stream Ordinality Within advanced applications, circumstances can easily arise in which the party creating the offer does not know ahead of time the number of streams the remote party will desire. For example, in a meet-me videoconference application that sends a separate stream for each participant, a client creating an offer to send to the conference focus does not necessarily know how many video streams to indicate in its SDP. Although this can be potentially be solved in an application-specific way (e.g., by always offering the maximum number of streams known to be supported by the application), this is not always desirable or even possible. To address this situation, a three-way handshake can be employed. In addition to the situation outlined there, if an offerer places an m-line in "sendonly" or "inactive" mode, it is making it unavailable for the answerer, and I believe that a consistent answer is the same as in section 3.5: A three-way handshake can be employed. In fact, I think it MUST be employed. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From emil@sip-communicator.org Sat Jul 27 09:16: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 86E3F21F9B92 for ; Sat, 27 Jul 2013 09:16:51 -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 8NrKYwxzIw2J for ; Sat, 27 Jul 2013 09:16:46 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 000AC21F9B8F for ; Sat, 27 Jul 2013 09:16:43 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id c4so2080604eek.15 for ; Sat, 27 Jul 2013 09:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=rAabp7tsmboq1YUDw4YGmnJSikcc//GjvB8X3DMd2Wo=; b=oyPIomPwcGgeoDmChAY1XRlNcHn69EIYposfLiisxDsuZ6HaVkS+kmzThSV+/zFK8v x7ogmOZX5f3Y3p5+BRkrQn/8vPxURwlqQqypFFvxtZwGtU3mctbSnOjfK9Ai5/hZt6Kq pZx2IHKnoCx+8w5LruBe/YSmdBwSiGacXc2akFUSEi4wf40DoNAIvvY1E5GP4w0+b+t4 HyKXRU0qOJRllQTsCKehiV5jWQ4/31PAM+JrUKQ8zXJ1LDJlx40zaExnJ4C+1ERFAmyI pA1fbzfYdu0q+9MxayWSZnBubV/IKBnJoVzEzr9RNtP9D4MHRS+nPFSVCLdKFj1w8mJk YMFg== X-Received: by 10.14.182.132 with SMTP id o4mr51519368eem.94.1374941802851; Sat, 27 Jul 2013 09:16:42 -0700 (PDT) Received: from camionet.local ([46.189.28.46]) by mx.google.com with ESMTPSA id p49sm88841984eeu.2.2013.07.27.09.16.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 09:16:41 -0700 (PDT) Message-ID: <51F3F264.1040601@jitsi.org> Date: Sat, 27 Jul 2013 18:16:36 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> In-Reply-To: <51F06AB6.2010008@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnpELVx+yWPB5DMI0ZUJ5TZRiVpMIoDqTNQ08aV6Rswsh7t5h1feTM4s/h/WwfKbSx1VIBu Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sat, 27 Jul 2013 16:16:51 -0000 On 25.07.13, 02:00, Adam Roach wrote: > On 7/24/13 17:58, Emil Ivov wrote: >> So you are confirming that the number of media sources, that the >> bridge expected to get from the callee, was hard-coded or >> pre-provisioned. Right? > > It's part of the application. Sure. "Hard-coded" is a reasonable way to= > think about it. A follow up question here then: How strong of an indication is the=20 direction? Let's say you do offer me a session with eight streams, seven = of which are a=3Dsendonly and only one is a=3Dsendrecv. Does this mean th= at=20 I should never consider sending you more than one stream? In other words, once we complete the first offer/answer, can I send you=20 a new offer with additional a=3Dsendrecv "m=3D" lines? Following 3264 wou= ld=20 mean that I could ... but if I did, I would essentially be ignore your=20 wish to only receive a single stream. Another question, when rendering the a=3Dsendonly lines in the above=20 8-stream offer, should the callee's GUI label them as being "on hold"?=20 Given the original scenario, I don't think we'd want that, but how does=20 the UA know this? Do we extend 3264 to say that a call is either=20 entirely on hold or it is not? One more: it is entirely possible that I missed this but I couldn't find = anything in 3264 that says whether or not a callee can, at some point,=20 change change the direction of an a=3Dsendonly line to a=3Dsendrecv. Do w= e=20 need to say a word about this? >> To simplify let's get back to I=F1aki's scenario of 8 "m=3D" lines in = the >> offer, but lets also assume that different callees can answer with >> anything between 1 and 8 sources. >> >> In this case, do you set all your "m=3D" lines to "a=3Dsendrecv"? > > If the bridge wanted to deal with receiving that many media streams, su= re. > >> If so, we are back to I=F1aki's original question: how does a >> single-source callee know which if these "m=3D" lines to pick for its >> own stream? >> >> I suppose one possible answer would be: it just takes any "m=3D" line >> that matches its needs and sends stuff there. It also sets everything >> else to "a=3Drecvonly" in the answer. Is this what you'd suggest? >> >> Or maybe the callee sends an answer where it sets everything to >> "a=3Drecvonly" and then re-offers with a ninth "a=3Dsendonly" "m=3D" l= ine? >> >> Or does the callee use app-specific signalling to tell the bridge that= >> it has N sources so that the bridge would offer with N "a=3Dsendrecv" >> "m=3D" lines and 8-N "a=3Dsendonly" "m=3D" lines? >> >> Or are all three of the above legal? > > Yes, the first one is what I would recommend. OK > The second one is certainly valid, but why would you do that? It delays= > the callee-to-caller media unnecessarily. I am just trying to figure out the exact semantics of the 3/4-way=20 handshake. So far the way I get it is that I express as much of my=20 intentions as I could in my answer. Then, if I need to say something=20 more, and only then, I send another offer. Is this correct? Or is it=20 more specific than that and I should only follow up with an update offer = in case I'd like to add streams? > The third one is fine, too, assuming you want to bind yourself to that > kind of signaling (it may complicate interdomain federation, if that > ever becomes important to you). Well I do care about federation by I worry more about it when we start=20 mentioning hard-coded assumptions in MCUs. An application-layer protocol = could always be properly specified at some point (and some already are). > But this is all pretty easy to derive from RFC 3264 section 6.1, really= =2E I don't really think it is that obvious (otherwise we wouldn't really=20 need this document, would we) I think the issue with directions is that in 3264 they only have an "m=3D= "=20 line scope. What you and Eric have implied is that now they actually=20 mean something for the entire session. Emil --=20 https://jitsi.org From christer.holmberg@ericsson.com Sat Jul 27 12:58: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 7879221F8E2D for ; Sat, 27 Jul 2013 12:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 zibXsj00hhq6 for ; Sat, 27 Jul 2013 12:58:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A621F8E2A for ; Sat, 27 Jul 2013 12:58:22 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-1a-51f4265e7464 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 14.7E.19388.E5624F15; Sat, 27 Jul 2013 21:58:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 27 Jul 2013 21:58:21 +0200 From: Christer Holmberg To: Emil Ivov , Adam Roach Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiHdm/eCEDVXXHUmH2aQmC+8qS5lzwdGAgAAcJYCAACd5gIAALo6AgAACo4CAAAmgAIAABawAgAAKVgCAABFYAIAENUUAgABffEQ= Date: Sat, 27 Jul 2013 19:58:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com>,<51F3F264.1040601@jitsi.org> In-Reply-To: <51F3F264.1040601@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40D21CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvrW6c2pdAg2c3BSz2/F3EbrFm5wQW i+n7bCymLn/M4sDica7hPbvHkiU/mTz+vwn0mLXzCUsASxSXTUpqTmZZapG+XQJXxpFJTUwF vxIrWluvsTQwvgroYuTkkBAwkTgyoYkVwhaTuHBvPVsXIxeHkMBhRokDr88ygiSEBJYwSnT+ COpi5OBgE7CQ6P6nDRIWEbCTuLXmIxOIzSyQIDHzyzt2EFtYwE3i/cVvrBA17hLrpzxihLDL JC4/h4izCKhKdCyfAlbPK+Ar8WTWWnaIVVeYJbYedgexOQU0JVr6XoLVMwLd9v3UGqhd4hK3 nsxngrhZQGLJnvPMELaoxMvH/1ghavIltrV+ZIGYLyhxcuYTlgmMIrOQtM9CUjYLSRlEXE/i xtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FyJ6bmJmTXm6+iREYXQe3/DbYwbjpvtghRmkO FiVx3s16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MBq6sqnra295s8LNRq3j7q9Nr5WU /vtfWn/b+u1d6z3lW3I23jzsf7/57mXjW98N70UUcRaGOb/aOGX7IpGZB8UYOtMkvaaukBQP 28aXYaN1J0/b869fCZP/n4uuFVk+8Uy5KypLIg62d9dGCJgku/XXRzzjyf437VlAEENjDk9E xK4VctO/KLEUZyQaajEXFScCAHAEeW18AgAA Cc: =?iso-8859-1?Q?I=C3=B1aki_Baz_Castillo?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sat, 27 Jul 2013 19:58:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40D21CESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Emil, I think you questions are not specific to the unified plan, but to Offer/An= swer in general. First, you can always offer additional m- lines. The receiver may accept th= em, or it may not, but just because you previously received an Offer with 8= m- lines doesn't automatically means the Offerer can't handle more. Second, it is allowed to send an Offer, where you suggest to change a sendo= nly m- line to sendrecv. Again, the receiver may accept it, or it may not. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Emil Ivov [emcho@jitsi.org] To: Adam Roach [adam@nostrum.com] CC: I=C3=B1aki Baz Castillo [ibc@aliax.net]; MMUSIC IETF WG [mmusic@ietf.or= g] Subject: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines On 25.07.13, 02:00, Adam Roach wrote: > On 7/24/13 17:58, Emil Ivov wrote: >> So you are confirming that the number of media sources, that the >> bridge expected to get from the callee, was hard-coded or >> pre-provisioned. Right? > > It's part of the application. Sure. "Hard-coded" is a reasonable way to > think about it. A follow up question here then: How strong of an indication is the direction? Let's say you do offer me a session with eight streams, seven of which are a=3Dsendonly and only one is a=3Dsendrecv. Does this mean that I should never consider sending you more than one stream? In other words, once we complete the first offer/answer, can I send you a new offer with additional a=3Dsendrecv "m=3D" lines? Following 3264 would mean that I could ... but if I did, I would essentially be ignore your wish to only receive a single stream. Another question, when rendering the a=3Dsendonly lines in the above 8-stream offer, should the callee's GUI label them as being "on hold"? Given the original scenario, I don't think we'd want that, but how does the UA know this? Do we extend 3264 to say that a call is either entirely on hold or it is not? One more: it is entirely possible that I missed this but I couldn't find anything in 3264 that says whether or not a callee can, at some point, change change the direction of an a=3Dsendonly line to a=3Dsendrecv. Do we need to say a word about this? >> To simplify let's get back to I=F1aki's scenario of 8 "m=3D" lines in th= e >> offer, but lets also assume that different callees can answer with >> anything between 1 and 8 sources. >> >> In this case, do you set all your "m=3D" lines to "a=3Dsendrecv"? > > If the bridge wanted to deal with receiving that many media streams, sure= . > >> If so, we are back to I=F1aki's original question: how does a >> single-source callee know which if these "m=3D" lines to pick for its >> own stream? >> >> I suppose one possible answer would be: it just takes any "m=3D" line >> that matches its needs and sends stuff there. It also sets everything >> else to "a=3Drecvonly" in the answer. Is this what you'd suggest? >> >> Or maybe the callee sends an answer where it sets everything to >> "a=3Drecvonly" and then re-offers with a ninth "a=3Dsendonly" "m=3D" lin= e? >> >> Or does the callee use app-specific signalling to tell the bridge that >> it has N sources so that the bridge would offer with N "a=3Dsendrecv" >> "m=3D" lines and 8-N "a=3Dsendonly" "m=3D" lines? >> >> Or are all three of the above legal? > > Yes, the first one is what I would recommend. OK > The second one is certainly valid, but why would you do that? It delays > the callee-to-caller media unnecessarily. I am just trying to figure out the exact semantics of the 3/4-way handshake. So far the way I get it is that I express as much of my intentions as I could in my answer. Then, if I need to say something more, and only then, I send another offer. Is this correct? Or is it more specific than that and I should only follow up with an update offer in case I'd like to add streams? > The third one is fine, too, assuming you want to bind yourself to that > kind of signaling (it may complicate interdomain federation, if that > ever becomes important to you). Well I do care about federation by I worry more about it when we start mentioning hard-coded assumptions in MCUs. An application-layer protocol could always be properly specified at some point (and some already are). > But this is all pretty easy to derive from RFC 3264 section 6.1, really. I don't really think it is that obvious (otherwise we wouldn't really need this document, would we) I think the issue with directions is that in 3264 they only have an "m=3D" line scope. What you and Eric have implied is that now they actually mean something for the entire session. Emil -- https://jitsi.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C40D21CESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Emil,
 
I think you questions are not specific to the u= nified plan, but to Offer/Answer in general.
 
First, you can always offer additional m- lines= . The receiver may accept them, or it may not, but just because you previou= sly received an Offer with 8 m- lines doesn't automatically means the Offer= er can't handle more.
 
Second, it is allowed to send an Offer, where y= ou suggest to change a sendonly m- line to sendrecv. Again, the receiver ma= y accept it, or it may not.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [emcho@jitsi.org]
To: Adam Roach [adam@nostrum.com]
CC: I=C3=B1aki Baz Castillo [ibc@aliax.net]; MMUSIC IETF WG [mmusic@= ietf.org]
Subject: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lin= es
On 25.07.13, 02:00, Adam Roach wrote:
> On 7/24/13 17:58, Emil Ivov wrote:
>> So you are confirming that the number of media sources, that the >> bridge expected to get from the callee, was hard-coded or
>> pre-provisioned. Right?
>
> It's part of the application. Sure. "Hard-coded" is a reason= able way to
> think about it.

A follow up question here then: How strong of an indication is the
direction? Let's say you do offer me a session with eight streams, seven of which are a=3Dsendonly and only one is a=3Dsendrecv. Does this mean that=
I should never consider sending you more than one stream?

In other words, once we complete the first offer/answer, can I send you a new offer with additional a=3Dsendrecv "m=3D" lines? Following = 3264 would
mean that I could ... but if I did, I would essentially be ignore your
wish to only receive a single stream.

Another question, when rendering the a=3Dsendonly lines in the above
8-stream offer, should the callee's GUI label them as being "on hold&q= uot;?
Given the original scenario, I don't think we'd want that, but how does the UA know this? Do we extend 3264 to say that a call is either
entirely on hold or it is not?

One more: it is entirely possible that I missed this but I couldn't find anything in 3264 that says whether or not a callee can, at some point,
change change the direction of an a=3Dsendonly line to a=3Dsendrecv. Do we =
need to say a word about this?

>> To simplify let's get back to I=F1aki's scenario of 8 "m=3D&q= uot; lines in the
>> offer, but lets also assume that different callees can answer with=
>> anything between 1 and 8 sources.
>>
>> In this case, do you set all your "m=3D" lines to "= a=3Dsendrecv"?
>
> If the bridge wanted to deal with receiving that many media streams, s= ure.
>
>> If so, we are back to I=F1aki's original question: how does a
>> single-source callee know which if these "m=3D" lines to= pick for its
>> own stream?
>>
>> I suppose one possible answer would be: it just takes any "m= =3D" line
>> that matches its needs and sends stuff there. It also sets everyth= ing
>> else to "a=3Drecvonly" in the answer. Is this what you'd= suggest?
>>
>> Or maybe the callee sends an answer where it sets everything to >> "a=3Drecvonly" and then re-offers with a ninth "a= =3Dsendonly" "m=3D" line?
>>
>> Or does the callee use app-specific signalling to tell the bridge = that
>> it has N sources so that the bridge would offer with N "a=3Ds= endrecv"
>> "m=3D" lines and 8-N "a=3Dsendonly" "m=3D= " lines?
>>
>> Or are all three of the above legal?
>
> Yes, the first one is what I would recommend.

OK

> The second one is certainly valid, but why would you do that? It delay= s
> the callee-to-caller media unnecessarily.

I am just trying to figure out the exact semantics of the 3/4-way
handshake. So far the way I get it is that I express as much of my
intentions as I could in my answer. Then, if I need to say something
more, and only then, I send another offer. Is this correct? Or is it
more specific than that and I should only follow up with an update offer in case I'd like to add streams?

> The third one is fine, too, assuming you want to bind yourself to that=
> kind of signaling (it may complicate interdomain federation, if that > ever becomes important to you).

Well I do care about federation by I worry more about it when we start
mentioning hard-coded assumptions in MCUs. An application-layer protocol could always be properly specified at some point (and some already are).
> But this is all pretty easy to derive from RFC 3264 section 6.1, reall= y.

I don't really think it is that obvious (otherwise we wouldn't really
need this document, would we)

I think the issue with directions is that in 3264 they only have an "m= =3D"
line scope. What you and Eric have implied is that now they actually
mean something for the entire session.

Emil

--
https://jitsi.org

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C40D21CESESSMB209erics_-- From pkyzivat@alum.mit.edu Sun Jul 28 01:00: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 47B4121F9D5E for ; Sun, 28 Jul 2013 01:00:29 -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 xcAaswdMqtf8 for ; Sun, 28 Jul 2013 01:00:24 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31C21F9D50 for ; Sun, 28 Jul 2013 01:00:24 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 5k051m0021Y3wxoA5k0Qi7; Sun, 28 Jul 2013 08:00:24 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta15.emeryville.ca.mail.comcast.net with comcast id 5jyE1m00G4YBfqS8bjyHKF; Sun, 28 Jul 2013 07:58:22 +0000 Message-ID: <51F4CF12.5070906@alum.mit.edu> Date: Sun, 28 Jul 2013 09:58:10 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> In-Reply-To: <51F06AB6.2010008@nostrum.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=1374998424; bh=CbzzjIpp2x3NILhJbO/eFkqBVezMoB5can/l9uUy2Ak=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QLZ7mVpdCr+Y+zS/1gOW1TkKOdy0KDanUSBbUlKjJEYvSt1XrqSHAMyDZ6M3SJv5b GDD6q3k3ogEv8LV41mqH7+9Z3SF3pEYrGxnWrj0rwS7u8kERElsn2dG4YNlsBlbIbp sgjiFniwRumvZ0ZECBr0LEk8P2TPSiKbEoegYQNauX4EDxuJM4ILOhR+khWLW2vhPX 9BRqU52jVLFLgA428BXI24Qhwl69JFXnxYEVtABEUpWFNY7Uwcv/CPqSMIosSRSYYy Wxiu8190I4vEM0+39gjwWRvikOH4l2/BlkLnpby7YCjSHJfmgmOY6NB2rr4kdcIBJU A305Rp/c9nrXg== Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sun, 28 Jul 2013 08:00:29 -0000 On 7/25/13 2:00 AM, Adam Roach wrote: > On 7/24/13 17:58, Emil Ivov wrote: >> So you are confirming that the number of media sources, that the >> bridge expected to get from the callee, was hard-coded or >> pre-provisioned. Right? > > It's part of the application. Sure. "Hard-coded" is a reasonable way to > think about it. > >> To simplify let's get back to Iñaki's scenario of 8 "m=" lines in the >> offer, but lets also assume that different callees can answer with >> anything between 1 and 8 sources. >> >> In this case, do you set all your "m=" lines to "a=sendrecv"? > > If the bridge wanted to deal with receiving that many media streams, sure. > >> If so, we are back to Iñaki's original question: how does a >> single-source callee know which if these "m=" lines to pick for its >> own stream? >> >> I suppose one possible answer would be: it just takes any "m=" line >> that matches its needs and sends stuff there. It also sets everything >> else to "a=recvonly" in the answer. Is this what you'd suggest? >> >> Or maybe the callee sends an answer where it sets everything to >> "a=recvonly" and then re-offers with a ninth "a=sendonly" "m=" line? >> >> Or does the callee use app-specific signalling to tell the bridge that >> it has N sources so that the bridge would offer with N "a=sendrecv" >> "m=" lines and 8-N "a=sendonly" "m=" lines? >> >> Or are all three of the above legal? > > Yes, the first one is what I would recommend. There are potential problems with this approach. Having answered this and chosen the m-line for bidirectional use all is well for the moment. But then, one side may make another offer, proposing to change something about that m-line. At that point, its unclear whether the change is intended for the stream it is sending, the one it is receiving, or both. For instance, some devices can really only use one codec, so the new offer might be to lock down to the first codec that was chosen. But it may be that the desire by the other side was to use a different codec for each direction. I don't have an answer here. It is certainly tempting to use an m-line bidirectionally, at least in absence of bundle. With bundle there is a lot less motivation to do that. Thanks, Paul > The second one is certainly valid, but why would you do that? It delays > the callee-to-caller media unnecessarily. > > The third one is fine, too, assuming you want to bind yourself to that > kind of signaling (it may complicate interdomain federation, if that > ever becomes important to you). > > But this is all pretty easy to derive from RFC 3264 section 6.1, really. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From emil@sip-communicator.org Sun Jul 28 04:04: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 11D5621F9D93 for ; Sun, 28 Jul 2013 04:04:36 -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 kNghrmdC261T for ; Sun, 28 Jul 2013 04:04:25 -0700 (PDT) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5727521F9D7C for ; Sun, 28 Jul 2013 04:04:25 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so433690eaj.34 for ; Sun, 28 Jul 2013 04:04:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=0RtCpmQcKecK6Tnx8sfX8s2A5iOcSC7kg9C3L/4DB7M=; b=nXPBWqWTRaCj92iD88LoBq3Z6lKgBl/T1eAFUOzx5x1//bi7JGqNroVW1LZwuhLXVc Vb0y4AKOFpVlOSoH78Y/YNBEkK3ZbAnrDUAw4XzMFVtpyBxTX9oKkkw5aGvsCmV1sdMg Ptubbt1qXmBvtxGkXb4edf9At+TsiyXCw+uhY21dA8IEE6UbdBJLLHAxaEhIZpg5Rp/S M1L8h7XrDanPs728PsT4s8ekheyTjvYY+euUDWCxtuFO02yVlK3iJVkCnoFFyNz4+dnS Rgie+UCMFFUAY2JuEFcoXIuN4efKQ1ZYerdoAuaM8wskIjegz17oXGu9NBzhXI+do2r2 D+SA== X-Received: by 10.14.148.133 with SMTP id v5mr55186510eej.81.1375009464269; Sun, 28 Jul 2013 04:04:24 -0700 (PDT) Received: from camionet.local ([46.189.28.96]) by mx.google.com with ESMTPSA id ci50sm94286861eeb.12.2013.07.28.04.04.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 04:04:23 -0700 (PDT) Message-ID: <51F4FAB5.2000507@jitsi.org> Date: Sun, 28 Jul 2013 13:04:21 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com>, <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmE9STtEXu+DhF1rQgkxsSQQdfWUycBor3jZroceNWNWh2cqKZ72mR4n5Mgw9Swem797x/q Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castill?= =?ISO-8859-1?Q?o?= , MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sun, 28 Jul 2013 11:04:36 -0000 On 27.07.13, 21:58, Christer Holmberg wrote: > Hi Emil, > I think you questions are not specific to the unified plan, but to > Offer/Answer in general. Well that's the thing, they *are* about unified plan. Looking for=20 answers to these questions in 3264 would be the same as looking for=20 traffic regulations and ordinances in the manual of your car. The answers you can get from 3264 are that pretty much anything and=20 everything is possible. Some of that ambiguity would have to be removed. = Ideally we'd do this in the spec but if we don't, then implementations=20 would do it implicitly. > First, you can always offer additional m- lines. The receiver may accep= t > them, or it may not, but just because you previously received an Offer > with 8 m- lines doesn't automatically means the Offerer can't handle mo= re. > Second, it is allowed to send an Offer, where you suggest to change a > sendonly m- line to sendrecv. Again, the receiver may accept it, or it This is a great example of how 3264 is not enough. Let's say for example that you want to add a new stream by switching an=20 a=3Dsendonly "m=3D" line to a=3Dsendrecv. However, I consider this line t= o be=20 "on hold" and I don't want you thinking that you can unhold it, so I=20 reject it. At the same time I am totally fine with you adding a new one=20 for your stream. Inversely, I might have sent you an offer with 8 "m=3D" lines as an=20 indication that this is the maximum number of streams that I can deal=20 with (this is actually labelled as bad practice in unified but I didn't=20 find an alternative). In this case, I might be OK with you changing my=20 directions to enable new streams but I would reject new "m=3D" lines=20 because I don't want to have any more streams than the 8 already in the=20 SDP. In both of the above cases there are different ways of achieving the=20 same thing and each time one would work, while others wouldn't. Yet it=20 would be hard for the remote party to pick the right one. Paul just made a case for using different sets of "m=3D" lines for either= =20 direction. This is totally valid from a 3264 perspective, but without=20 further information, an implementation would have to go through a number = of trials and errors until it figures out that this is how you expect=20 things to happen. Emil > may not. > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Emil Ivov [emcho@jitsi.org] > *To:* Adam Roach [adam@nostrum.com] > *CC:* I=C3=B1aki Baz Castillo [ibc@aliax.net]; MMUSIC IETF WG [mmusic@i= etf.org] > *Subject:* Re: [MMUSIC] [rtcweb] About unified Plan and multiple m line= s > On 25.07.13, 02:00, Adam Roach wrote: >> On 7/24/13 17:58, Emil Ivov wrote: >>> So you are confirming that the number of media sources, that the >>> bridge expected to get from the callee, was hard-coded or >>> pre-provisioned. Right? >> >> It's part of the application. Sure. "Hard-coded" is a reasonable way t= o >> think about it. > > A follow up question here then: How strong of an indication is the > direction? Let's say you do offer me a session with eight streams, seve= n > of which are a=3Dsendonly and only one is a=3Dsendrecv. Does this mean = that > I should never consider sending you more than one stream? > > In other words, once we complete the first offer/answer, can I send you= > a new offer with additional a=3Dsendrecv "m=3D" lines? Following 3264 w= ould > mean that I could ... but if I did, I would essentially be ignore your > wish to only receive a single stream. > > Another question, when rendering the a=3Dsendonly lines in the above > 8-stream offer, should the callee's GUI label them as being "on hold"? > Given the original scenario, I don't think we'd want that, but how does= > the UA know this? Do we extend 3264 to say that a call is either > entirely on hold or it is not? > > One more: it is entirely possible that I missed this but I couldn't fin= d > anything in 3264 that says whether or not a callee can, at some point, > change change the direction of an a=3Dsendonly line to a=3Dsendrecv. Do= we > need to say a word about this? > >>> To simplify let's get back to I=F1aki's scenario of 8 "m=3D" lines in= the >>> offer, but lets also assume that different callees can answer with >>> anything between 1 and 8 sources. >>> >>> In this case, do you set all your "m=3D" lines to "a=3Dsendrecv"? >> >> If the bridge wanted to deal with receiving that many media streams, s= ure. >> >>> If so, we are back to I=F1aki's original question: how does a >>> single-source callee know which if these "m=3D" lines to pick for its= >>> own stream? >>> >>> I suppose one possible answer would be: it just takes any "m=3D" line= >>> that matches its needs and sends stuff there. It also sets everything= >>> else to "a=3Drecvonly" in the answer. Is this what you'd suggest? >>> >>> Or maybe the callee sends an answer where it sets everything to >>> "a=3Drecvonly" and then re-offers with a ninth "a=3Dsendonly" "m=3D" = line? >>> >>> Or does the callee use app-specific signalling to tell the bridge tha= t >>> it has N sources so that the bridge would offer with N "a=3Dsendrecv"= >>> "m=3D" lines and 8-N "a=3Dsendonly" "m=3D" lines? >>> >>> Or are all three of the above legal? >> >> Yes, the first one is what I would recommend. > > OK > >> The second one is certainly valid, but why would you do that? It delay= s >> the callee-to-caller media unnecessarily. > > I am just trying to figure out the exact semantics of the 3/4-way > handshake. So far the way I get it is that I express as much of my > intentions as I could in my answer. Then, if I need to say something > more, and only then, I send another offer. Is this correct? Or is it > more specific than that and I should only follow up with an update offe= r > in case I'd like to add streams? > >> The third one is fine, too, assuming you want to bind yourself to that= >> kind of signaling (it may complicate interdomain federation, if that >> ever becomes important to you). > > Well I do care about federation by I worry more about it when we start > mentioning hard-coded assumptions in MCUs. An application-layer protoco= l > could always be properly specified at some point (and some already are)= =2E > >> But this is all pretty easy to derive from RFC 3264 section 6.1, reall= y. > > I don't really think it is that obvious (otherwise we wouldn't really > need this document, would we) > > I think the issue with directions is that in 3264 they only have an "m=3D= " > line scope. What you and Eric have implied is that now they actually > mean something for the entire session. > > Emil > > -- > https://jitsi.org > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 https://jitsi.org From pkyzivat@alum.mit.edu Sun Jul 28 04:58: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 55D4021F941F for ; Sun, 28 Jul 2013 04:58: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 y65geuYzPwPR for ; Sun, 28 Jul 2013 04:58:06 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23921F93E1 for ; Sun, 28 Jul 2013 04:58:06 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 5nup1m0011smiN4AFny6x2; Sun, 28 Jul 2013 11:58:06 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta20.emeryville.ca.mail.comcast.net with comcast id 5nvw1m00X4YBfqS8gnvzby; Sun, 28 Jul 2013 11:56:04 +0000 Message-ID: <51F506C8.30004@alum.mit.edu> Date: Sun, 28 Jul 2013 13:55:52 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com>, <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> In-Reply-To: <51F4FAB5.2000507@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=1375012686; bh=TiquKYPk2SSxNST07epcrzvnBL9dZpooQ0UtZsaJ8yE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hCZzx4SghZFNvtSfkgopsAag0wqugGRwf949NulRbEBfaIwPUHlBvKIynNRQnvn47 ppLhhq4/7q3AeLzhknWfuirscqX4fAhb6G/+Gu9TIqT8rGtrgDzg5wT6pRl85BzBi1 8O/BO9w+bVtpyAeKflEjVLzbJKg3SVOAOeYlCHqShDSA9Zq7HSnHxLha+eNyiA/ZFi zJXNqSGOM3Tf18IBT4owmG79Ydxdw2I5mupi79bJMbNCLml98qZPhiq7jS60jjiEsS w/HanEJYWSItWV/fFyCVtFJ8Xc3qA3CfG0KHN8HTKHwf/pcFS1/oW2zIHltWFxgQF+ o7qX5UIduTe1Q== Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Sun, 28 Jul 2013 11:58:12 -0000 On 7/28/13 1:04 PM, Emil Ivov wrote: > Paul just made a case for using different sets of "m=" lines for either > direction. This is totally valid from a 3264 perspective, but without > further information, an implementation would have to go through a number > of trials and errors until it figures out that this is how you expect > things to happen. I don't claim to know what is *right* here. I commented on some difficulties of using m-lines bidirectionally. ISTM that 3264 is predicated on sendrecv describing a bi-directional usage, rather than two uni-directional usages. This can be inferred from the use of a single set of matched attributes for the two directions - no ability to say "use codec X in one direction and codec Y in the other direction." But I am not aware of any clear guidelines about when you logically have a single bidirectional usage vs. two unidirectional usages. I think we are lacking a conceptual model of the distinction. In certain cases history provides a precedent. In particular, a basic audio call. In that case we can how common usage links the two directions: when I want to "put the call on hold" I want to stop receiving the stream from the far end and I either want to stop sending, or else I will send some sort of MoH stuff. These actions are viewed as coupled, so using a single m-line works out. I suppose, if I had one sendonly and one recvonly audio m-line, then I could figure out what to to with the SDP. But would the other side understand? But when you start adding streams - even audio/video - then those common usages provide little guidance for what to do. Does hold do make the same changes to both audio and video? Or are they managed separately. And once I have more than one audio or video in each direction, it becomes quite unclear. We have been living in blissful ignorance. Once we start seriously thinking about multiple audio or video m-lines we are forced to actually think about this stuff, make some decisons, and write them down. Thanks, Paul From thomas.stach@siemens-enterprise.com Sun Jul 28 07:37: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 1D91021F9DA9 for ; Sun, 28 Jul 2013 07:37:02 -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 PPeWNOU76Dd1 for ; Sun, 28 Jul 2013 07:36:52 -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 180BF21F9C4E for ; Sun, 28 Jul 2013 07:36:48 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8C6A923F04AE; Sun, 28 Jul 2013 16:36:46 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.30]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Sun, 28 Jul 2013 16:36:46 +0200 From: "Stach, Thomas" To: Emil Ivov , Alan Johnston Thread-Topic: [MMUSIC] Trickle ICE for SIP Questions Thread-Index: AQHOiB3rOpQLK3xMc0CKfL3MA1dNd5lzc2MAgAAEQYCABrTt4A== Date: Sun, 28 Jul 2013 14:36:46 +0000 Message-ID: References: <51D43186.2010907@jitsi.org> <51EFA5DD.3000805@jitsi.org> In-Reply-To: <51EFA5DD.3000805@jitsi.org> Accept-Language: de-AT, 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: "Cullen Jennings \(fluffy\)" , MMUSIC IETF WG Subject: Re: [MMUSIC] Trickle ICE for SIP 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: Sun, 28 Jul 2013 14:37:02 -0000 ... chiming in after vacation > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Wednesday, 24 July, 2013 12:01 > To: Alan Johnston > Cc: Cullen Jennings (fluffy); MMUSIC IETF WG > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions >=20 > Hey Alan, Cullen, >=20 > On 24.07.13, 11:45, Alan Johnston wrote: > > Agree with Cullen - if there is a reasonable approach (such as > > retransmitting 180) that avoids PRACK, then we should use this > approach. >=20 > There is one and it comes down to requiring the remote side to send an > INFO request as soon as it gets it. The INFO request could contain > trickled candidates (in the case of full trickle) or just > end-of-candidates (in the case of half-trickle). >=20 > This could work and, personally, I have no issue with it. [TS] I think this also works for me. >=20 > I believe the suggestion that Christer made was: given how the above > basically works as a PRACK minus the O/A and given how the O/A in > PRACKs > seems to be a deal breaker for many,=20 [TS] It is not only the O/A in PRACK, but also the arbitrary number of furt= her O/As in UPDATEs before the 200OK to the initial INVITE. > then we might want to generalize > the above mechanism so that other specs can also use it. [TS] Yes, I think that would be good.=20 Paul also seemed to propose to do something generic with my INFO/481/ re-se= nd 18x proposal.=20 http://www.ietf.org/mail-archive/web/mmusic/current/msg11754.html=20 I liked that as well, but as said above I could also live with acknowledgin= g the 18x with an immediate INFO from the UAC. Regards=20 Thomas >=20 > Cheers, > Emil >=20 >=20 > > - Alan - > > > > > > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) > > > wrote: > > > > > > I prefer the 180 resend approach and all the right things are > > already looking at them. I have always objected to mandating use > of > > PRACK. Obviously I'm fine with things that have PRACK can use it > but > > I want some solution for things that don't. > > > > One small note, the SDP in the 180 can change as long as the to- > tag > > is also changed. > > > > > > > > On Jul 3, 2013, at 8:13 AM, Emil Ivov > > wrote: > > > > > Hey all, > > > > > > Christer, Enrico and I are preparing the next version of > Trickle > > ICE for SIP. Now that discussions on BUNDLE and the plans seem to > be > > winding down, we wanted to run a few questions by the working > group. > > > > > > Q1: Making reliable provisional responses and PRACK mandatory. > > Obviously this would be nice to avoid, so the question is: is > there > > a reasonable mechanism to achieve this (and by reasonable, we > mean > > something that wouldn't be harder than implementing support for > PRACK). > > > > > > There was some discussion about this back in April and there > was > > a suggestion for implementing a 5245-style hack where the > answerer > > basically resends the 180 until it knows that it has been > received. > > > > > > 5245 uses connectivity checks for this (i.e. it stops 180 > > retransmissions when the first connectivity check is received) > but > > we don't have that option here since the 180 may contain either > none > > or only host candidates so there are strong chances that no > binding > > request would be received on them. > > > > > > Thomas also suggested a second option which would be to also > use > > INFO requests with trickled candidates as an indication that 180 > was > > received. This however wouldn't work with half trickle so we are > > basically back to vanilla ICE for all (non-re) INVITEs. > > > > > > Another option would be to mandate an INFO request with > > "end-of-candidates" in response to the 180, but that would be > just > > the same as mandating PRACK support. > > > > > > Thomas also suggested that the answerer can start sending > INFOs > > right after it sends its answer in the 180 and then it can just > > resend the 180 if the INFOs result in a 481 response. > > > > > > Personally I think this could potentially be made to work, but > it > > would imply a level of complexity that considerably exceeds PRACK > > support. > > > > > > Opinions? > > > > > > Q2: How do we send INFOs? Are they blocking or do we just send > > them in parallel? If the latter, then what happens when an INFO > > fails because it is received out of order? Do we just tell the > > application to resend the candidates asap? > > > > > > This also leads to the following question: > > > > > > Q3: What exactly do we send in INFOs? Just the latest batch of > > freshly learned candidates or all candidates we've learned so > far? > > Dale suggested that if we do this cumulatively we wouldn't need > to > > worry about the case with the out-of-order INFOs from Q2 since > the > > information gets resent anyway. A drawback here would obviously > be > > that this adds more complexity for trickle ICE users (WebRTC > > applications specifically) > > > > > > A third option would be to allow both and leave it to the > > application. > > > > > > Comments are most welcome! > > > > > > Emil > > > > > > -- > > > https://jitsi.org > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > >=20 > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Sun Jul 28 10:57: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 804F521F9C82 for ; Sun, 28 Jul 2013 10:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 zNE2KMeTFDn2 for ; Sun, 28 Jul 2013 10:57:27 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58E21F9BC3 for ; Sun, 28 Jul 2013 10:57:26 -0700 (PDT) Received: from userPC (unknown [122.179.103.198]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id B375B6381E6; Sun, 28 Jul 2013 17:57:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375034246; bh=xetd7rdwagimoumNaOTKyIraaxpsKeOGC+QQH1571Dw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kODEJSxbixloaJyDUS9uTd+zhtms4FnZtTCMuZOwTOUYNS+xsRnXVs3R/4+4NWRHr jE28p1JnuonedBfX2UFzHsia8OsPIE8zrzXb6J2vBxlx4e0q6RuHbPi6InGz8Eo46f IL0fjmU/m8pTfKY1Z8thJx6pFJE6niQ7hWAcXmvg= From: "Parthasarathi R" To: "'Emil Ivov'" , "'MMUSIC IETF WG'" References: <1CDFD781608D924094E43F573C351961BDE2DC@xmb-rcd-x13.cisco.com> <51F03DC8.70908@jitsi.org> <00d401ce894e$70aa81c0$51ff8540$@co.in> <51F15478.3060104@jitsi.org> In-Reply-To: <51F15478.3060104@jitsi.org> Date: Sun, 28 Jul 2013 23:27:16 +0530 Message-ID: <000101ce8bbb$ea33eda0$be9bc8e0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6JVWiSsRcuVEzCRmWbkqNTTdREgAA1Os4w Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.51F55B85.0125, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: 'Alan Johnston' , "'Dale R. Worley'" Subject: [MMUSIC] UPDATE vs INFO for SIP Trickle ICE [was RE: Trickle ICE for SIP 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: Sun, 28 Jul 2013 17:57:31 -0000 Hi Emil & all, I had gone through UPDATE vs INFO argument for SIP trickle ICE. As Trickle ICE is candidate sharing only and also shall happen incrementally, so the INFO based back channel mechanism was preferred. I have concern with SDP back channel mechanism after the first O/A is complete as there are more possibity for race conditions between INFO from UAS and UPDATE from UAC. UPDATE from UAC is sent across for multiple reasons and I'll list update few of the scenarios which come to my mind immediately : 1) Bundle 2) ICE restart 3) Commit for the single codec after negotiation INFO for trickle ICE leads to confusion due to race conditions between UPDATE from UAC and un-ordered INFO from UAS. Also, it is not clear to me how media IP address as part back channel as it is part of SDP O/A. In case SDP is designed to carry to media codec negotiation & media IP address separately (like Jingle/H.245), back channel mechanism works well Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Thursday, July 25, 2013 10:08 PM > To: 'MMUSIC IETF WG' > Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > > Hey Partha, > > On 25.07.13, 17:48, Parthasarathi R wrote: > > Hi Emil, > > > > In the mentioned situation, different To-tag with same contact header > for > > trickled SDP, So there will be no "N" locations. > > Having the same contact header does not automatically suggest that this > is somehow a fake fork (unless I am missing the text that says this in > 3261). You could potentially have this if the fork is done by a B2BUA > or > a PSTN gateway for example. > > > My reading of the draft is that this draft is not required in case > UPDATE > > (RFC 3311) method is supported. UPDATE with SDP will update trickle > > candidate within 18x. > > Use of UPDATE has already been discussed and we pretty much agreed not > to go that way. > > A mail from Alan and the preceding discussion: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html > > A follow up with a nice summary from Dale: > http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html > > > The aim of the draft is to support Trickle ICE for SIP user agent > which does > > not support RFC 3311 for last 11 years. AFAIK, different "to tag" is > the > > simpler way to solve the problem in UAS side. I have concern w.r.t > INFO > > mechanism as it adds one method for handling SDP and complicates the > > existing SDP O/A handling (RFC 6337). > > That's the thing, trickle ICE is not part of Offer/Answer. It's a > separate channel for agent-to-agent communication. Use of SDP is just a > convenient coincidence. > > > Including Christer in this mail thread as he replied in the parallel > mail > > thread. > > I believe he is on the list I don't think that's an issue :) > > Cheers, > Emil > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: Thursday, July 25, 2013 2:19 AM > >> To: Cullen Jennings (fluffy) > >> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; > MMUSIC > >> IETF WG > >> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions > >> > >> > >> > >> On 24.07.13, 21:56, Cullen Jennings (fluffy) wrote: > >>> > >>> On Jul 24, 2013, at 12:22 PM, Vijaya Mandava (vimandav) > >> wrote: > >>> > >>>> 180 with different to-tag would mean call is forked. > >>>> If uac side do not support call forking, then we cannot use this > 180 > >>>> response to collect trickled candidates. > >>> > >>> If it is a UAC, it supports this so I don't see the problem. > >> > >> One problem is that the UAC could support it to the extent of making > it > >> visible to the user: > >> > >> "Your contact is being alerted on these N locations" > >> > >> And of course there's also the fact that we would be creating > several > >> dialogs per call, that we'd then need to clean and garbage collect. > >> > >> Why would we want to go there? > >> > >> Emil > >> > >> -- > >> https://jitsi.org > > > > > > -- > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Mon Jul 29 00:53: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 CE9AB21F9B28 for ; Mon, 29 Jul 2013 00:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 1zjcbDqooqOe for ; Mon, 29 Jul 2013 00:53:43 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C10321F918C for ; Mon, 29 Jul 2013 00:53:41 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-0d-51f61f843b5f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 36.C5.11907.48F16F15; Mon, 29 Jul 2013 09:53:40 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Mon, 29 Jul 2013 09:53:40 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4B19B11043A; Mon, 29 Jul 2013 10:53:40 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EB008557C5; Mon, 29 Jul 2013 10:53:35 +0300 (EEST) Received: from dhcp-64a1.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8A9DB53B6E; Mon, 29 Jul 2013 10:53:35 +0300 (EEST) Message-ID: <51F61F88.1000503@ericsson.com> Date: Mon, 29 Jul 2013 09:53:44 +0200 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic References: <20130718161212.19084.19711.idtracker@ietfa.amsl.com> In-Reply-To: <20130718161212.19084.19711.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvrW6L/LdAg5ebdS3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfF8fidjwX2+iq7HH5kbGLfzdDFyckgImEg8 ubmUDcIWk7hwbz2QzcUhJHCUUeLVt8tMEM4GRomZayawQDh7GSUaD36CctYxSqx++hfBOTX5 ItgwXgFtidaVC5lBbBYBVYkLew+wg9hsArYSq1/dBGrg4BAVSJZ4ecQIolxQ4uTMJywgtoiA jMTeTZvBWpmBxsy+M4sJxBYWyJXoWdkNFhcScJQ4tOoS2EhOASeJ6/1foeotJBa/OcgOYctL NG+dzQzxm5rE1XOboHpVJa7+e8U4gVF0FpLVs5C0z0LSvoCReRUjR3FqcVJuupHBJkZg4B/c 8ttiB+PlvzaHGKU5WJTEebfonQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOjptEP6xH/G aNs9J80NrhX5rPy2kGGiXv8OXYZlimtkXy0w+6wVufSX4ku/1Rm36jKq5xg++S7+9rquxLPf Z/zSr+4vv3WjhkszLjEtWsfWUmfJsrkf0qKS7D/wnxN4EPVI53l3mjenk8jVt3pHF/N94K9O ul+U/LXu0FKGuF0JZ5d+vsfc0qbEUpyRaKjFXFScCABlk3u3SgIAAA== Cc: Flemming Andreasen Subject: [MMUSIC] New Liaison Statement, "LS on Missing IANA Registration Information on SDP Attributes in RFC 2326" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 07:53:51 -0000 MMUSIC, We have received a liaison statement from 3GPP regarding missing SDP attributes at the IANA registry (see the e-mail below for details). As the statement says: > SA4 has identified that IANA registrations of three SDP attributes defined in RFC 2326, namely ‘control’, ‘range’ and ‘etag’, are missing As a solution, the RTSP 2.0 draft already registers 'control' and 'range' for RFC 2326 and RFC 2326bis (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-34#section-22.15). However, in RFC2326bis 'etag' is renamed into 'mtag'. Hence, it seems that we should also register 'etag' but for that reference RTSP 1.0 (RFC 2326) only. Please review the liaison statement and our proposed solution and send your comments to us and to the list. Thanks, Ari & Flemming (MMUSIC co-chairs) On 7/18/13 6:12 PM, Liaison Statement Management Tool wrote: > Title: LS on Missing IANA Registration Information on SDP Attributes in RFC 2326 > Submission Date: 2013-07-16 > URL of the IETF Web page: http://datatracker.ietf.org/liaison/1267/ > Please reply by 2013-09-17 > From: 3GPP TSG SA WG4 (Susanna Kooistra <3GPPLiaison@etsi.org>) > To: Multiparty Multimedia Session Control (Flemming Andreasen , Ari Keranen ) > Cc: Gonzalo Camarillo ,Richard Barnes ,Multiparty Multimedia Session Control Discussion List > Reponse Contact: Ozgur Oyman > Technical Contact: > Purpose: For action > > Body: > Attachments: > > LS on Missing IANA Registration Information on SDP Attributes in RFC 2326 > https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-16-3gpp-tsg-sa-wg4-mmusic-ls-on-missing-iana-registration-information-on-sdp-attributes-in-rfc-2326-attachment-1.doc > From ibc@aliax.net Mon Jul 29 02:33: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 84CBF21E8085 for ; Mon, 29 Jul 2013 02:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, 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 ES4mncKyk46w for ; Mon, 29 Jul 2013 02:33:11 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id BD1FA21E809E for ; Mon, 29 Jul 2013 02:32:29 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so771960qcx.4 for ; Mon, 29 Jul 2013 02:32:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zWNCKIW4AFLCsSQ9rO8jQ+a/i7Ks+CNZYpZJAbgduro=; b=nMdOekZFehmayGvRw4X1fXjd8VUbC/rhkVyhQyvoNVje+8ZOhf8izS+dIEgEujtehr RhzYgM98FaY3DhYX7q6YIZ/1nCTI6ug5TUSS6bev/t6ZNh3Qixr5Qi6EPSVTQCN86ygv 7vX9AK/fhAd0Ln1zcmnZuy+MItXooP3rLcYx9nqlOSG1Cl7XDSC8ga2uu2sZLcui2Uym KWBR/VlWIqQRhpuKbrjWZjsL4IQndn8r6C013bawTkTMa15GvHeTResT9h0yPSX2YKfi GMTSR9xmhE5PAVRL68DKT9xwHs0EPVOBQcAigkGkdU+3K1MFQ4QwcyaJb6IZPEYyxCMf Ux/A== X-Received: by 10.224.72.73 with SMTP id l9mr21111275qaj.115.1375090345504; Mon, 29 Jul 2013 02:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 02:32:05 -0700 (PDT) In-Reply-To: <51F4FAB5.2000507@jitsi.org> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 11:32:05 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlaYauek71Y3Q5mAMdADYul9Z/NzGjUIP4qOPs+C7oa1o8DhLnM2EINpUHOnmdF5eOUwOAd Cc: MMUSIC IETF WG , Christer Holmberg Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 09:33:17 -0000 2013/7/28 Emil Ivov : > This is a great example of how 3264 is not enough. > > Let's say for example that you want to add a new stream by switching an > a=3Dsendonly "m=3D" line to a=3Dsendrecv. However, I consider this line t= o be "on > hold" and I don't want you thinking that you can unhold it, so I reject i= t. > At the same time I am totally fine with you adding a new one for your > stream. > > Inversely, I might have sent you an offer with 8 "m=3D" lines as an indic= ation > that this is the maximum number of streams that I can deal with (this is > actually labelled as bad practice in unified but I didn't find an > alternative). In this case, I might be OK with you changing my directions= to > enable new streams but I would reject new "m=3D" lines because I don't wa= nt to > have any more streams than the 8 already in the SDP. > > In both of the above cases there are different ways of achieving the same > thing and each time one would work, while others wouldn't. Yet it would b= e > hard for the remote party to pick the right one. > > > Paul just made a case for using different sets of "m=3D" lines for either > direction. This is totally valid from a 3264 perspective, but without > further information, an implementation would have to go through a number = of > trials and errors until it figures out that this is how you expect things= to > happen. The problem of SDP is not just the format or the O/A mandate, but the fact that it was designed for legacy communications (i.e. single telephone call) in which it is 100% obvious that both parties would send audio to the other. It sometimes also works well when adding a video stream (not so well when disabling and re-enabling it again). So SDP assumes that a communication uses the same UDP IP:port tuple for sending audio and receiving its corresponding audio, and thus, SDP represents them in a single m=3Dline. Note however that in WebRTC we have multiplexed RTP. So now we have a powerfull scenario in which a conference server wants to send the client (browser) 8 audio tracks (from 8 participants) and the webcam video of 3 of them, and the client just wants to send its own audio and video track. This should be EASY: - The conference server offers 8 audio tracks + 3 video tracks. - The browser offers 1 audio track + 1 video track. But not... we are in SDP, things cannot be cool and modern. Instead: - The conference server offers 8 audio tracks + 3 video tracks. - The browser *answers* with 8 audio tracks + 3 videos tracks. (but most of them "a=3Drecvonly"). This is a hack. The 8 m=3Daudio lines offered by the server belong to 8 participants (from Alice, Bob, Carol...). Why should the browser *choose* one of those m=3Daudio lines for sending its own audio track? how can this stuff make sense in WebRTC where we have multiplexed RTP flows? Why should the browser set the "Alice's audio track" for sending and receiving and all the others for just receiving? And *worse*: - The conference server offers 8 audio tracks from 8 clients without webcam= . - The browser *wants* to offer 1 audio track + 1 video track (it does have webcam). FAIL !!! You cannot do that with SDP! The browser MUST reply with exactly 8 m=3Daudio lines and ZERO m=3Dvideo lines, so if the browser wants to add video it must re-negotiate later by adding a video track (a new SDP O/A round trip). So, leaving aside the SDP format and its O/A mandate, the fact is that SDP semantics (even with Plan-Unified) is bad for modern communications in which receiving a RTP flow does not mean that we also send a RTP flow (and vice versa). --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Mon Jul 29 04:29: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 8D21C21F9AEF for ; Mon, 29 Jul 2013 04:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 dw4JoXsolFJS for ; Mon, 29 Jul 2013 04:29:24 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5FC21F9BB1 for ; Mon, 29 Jul 2013 04:29:03 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so1584482qab.17 for ; Mon, 29 Jul 2013 04:29:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=blgiyY1T0B7zC10NkJg01ePJftTpr+2qqW2hMXCvRsU=; b=fdX3dXOo4h+3dhODwIY7zBxIiz2abmetYnQUdR0N417oXo3Mnuwqr8sGiXWQzx2dfd Gn49TNQKixtkQ0HtWhwTZtzRheF93irnUybnAIN6570rsXxqmXLd/AEBC0ocACgq394x q0/D4ljHjecI4ftQE7/mTXIMKODBv7kLryws0Gt1MfiwAmn1m3uX9sSpdjNYWZkzFL6C YYst8IpHK8S5DwpAeabFkO7A0l8RUEaFhAtcesL/ZoOPuN04sOkijpJmx3VW1FBaks9r I3DtC3u9sUZWboCmPuw2HyqgKPgm1EO1WRcSDWh4gXJBjF0mvQksEGDayYzuH5A09Ojc rVrg== X-Received: by 10.224.4.202 with SMTP id 10mr71560013qas.1.1375097342715; Mon, 29 Jul 2013 04:29:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 29 Jul 2013 04:28:22 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:5a55:caff:fef1:5a11] In-Reply-To: References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> From: Eric Rescorla Date: Mon, 29 Jul 2013 13:28:22 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c20dfea4fac704e2a4ccbc X-Gm-Message-State: ALoCoQlfH0kdwhaXoMEPiXHW0imGPZYCABlVoAl7+4hDfFReR7X2h9QbLVvO7M/MjYKpSMUkKTBb Cc: MMUSIC IETF WG , Christer Holmberg Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 11:29:29 -0000 --001a11c20dfea4fac704e2a4ccbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2013 at 11:32 AM, I=F1aki Baz Castillo wrot= e: > > - The conference server offers 8 audio tracks from 8 clients without > webcam. > - The browser *wants* to offer 1 audio track + 1 video track (it does > have webcam). > > FAIL !!! You cannot do that with SDP! The browser MUST reply with > exactly 8 m=3Daudio lines and ZERO m=3Dvideo lines, so if the browser > wants to add video it must re-negotiate later by adding a video track > (a new SDP O/A round trip). > Obviously the conference server could be foolish in this way, but in the type of scenario you suggest, the conference server would most likely offer 8 sendonly audio tracks (for sending audio to the client) and then one recvonly audio track and one recvonly video track to elicit the client's a/v session, which will work reasonably well. -Ekr > > --001a11c20dfea4fac704e2a4ccbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 29, 2013 at 11:32 AM, I=F1aki Baz Castillo <ibc@aliax.net<= /a>> wrote:

- The conference server offers 8 audio tracks from 8 clients without webcam= .
- The browser *wants* to offer 1 audio track + =A01 video track (it does have webcam).

FAIL !!! You cannot do that with SDP! The browser MUST reply with
exactly 8 m=3Daudio lines and ZERO m=3Dvideo lines, so if the browser
wants to add video it must re-negotiate later by adding a video track
(a new SDP O/A round trip).

Obviously t= he conference server could be foolish in this way, but in
the typ= e of scenario you suggest, the conference server would most
likely offer 8 sendonly audio tracks (for sending audio to the client)
and then one recvonly audio track and one recvonly video track
<= div>to elicit the client's a/v session, which will work reasonably well= .

-Ekr

--001a11c20dfea4fac704e2a4ccbc-- From ibc@aliax.net Mon Jul 29 05:09: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 DD28A21F9E43 for ; Mon, 29 Jul 2013 05:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 edC9A+jXFd7c for ; Mon, 29 Jul 2013 05:09:32 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0B21F9E15 for ; Mon, 29 Jul 2013 05:09:25 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m15so768852qcq.38 for ; Mon, 29 Jul 2013 05:09:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=l567kU89fsQ8/Hv2rrS7q6YD+MrD0b5CoUOyPjihTsY=; b=Ka9mnaphOzqKko1CsIbaGm7eAXp9Iwk65gTMTUGQzLknUNCMTFml0L0yY+hp8jHr3e zkvxTHHStTTBT0aFcMIol7m3PCCWpNhwWtpFHcy4goMdtuDO11Lm03VOsFyI0f4v0JA1 Ly+3S/ZoKN3KhDOVRrqgl4yhnkwVo/uwqy/shUAd9S6FzkOuHl6KYHPpRViSUmWLm/mz XGb2Pd69swg/NOm83rsxAtH5+rE9Im0jfvMFi9u/gAe8x9c/TB38/ch2YQBZGZ0HHjVI Pj+CHEa4p16jfL8+Ych92X5oCSG8bZLyzwNeDnqcDHHk+rURKRwTTgsrhIsPbghgKVPr +CVw== MIME-Version: 1.0 X-Received: by 10.229.16.207 with SMTP id p15mr5364478qca.47.1375099762854; Mon, 29 Jul 2013 05:09:22 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 05:09:22 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 05:09:22 -0700 (PDT) In-Reply-To: References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> Date: Mon, 29 Jul 2013 14:09:22 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=0015175df19ee5669904e2a55c54 X-Gm-Message-State: ALoCoQkCCIRzICuLm4Ww3SauP1c9jJTWpLvn41WQ/LCky07I1uilkhMZFxD7jC6IrIsvwEFZAt6Z Cc: MMUSIC IETF WG , Christer Holmberg Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 12:09:40 -0000 --0015175df19ee5669904e2a55c54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -- I=C3=B1aki Baz Castillo El 29/07/2013 13:29, "Eric Rescorla" escribi=C3=B3: > > > > > On Mon, Jul 29, 2013 at 11:32 AM, I=C3=B1aki Baz Castillo wrote: >> >> >> - The conference server offers 8 audio tracks from 8 clients without webcam. >> - The browser *wants* to offer 1 audio track + 1 video track (it does >> have webcam). >> >> FAIL !!! You cannot do that with SDP! The browser MUST reply with >> exactly 8 m=3Daudio lines and ZERO m=3Dvideo lines, so if the browser >> wants to add video it must re-negotiate later by adding a video track >> (a new SDP O/A round trip). > > > Obviously the conference server could be foolish in this way, but in > the type of scenario you suggest, the conference server would most > likely offer 8 sendonly audio tracks (for sending audio to the client) > and then one recvonly audio track and one recvonly video track > to elicit the client's a/v session, which will work reasonably well. And what about if the browser/device has two webcams (letf and right) and wants to send both? How can the server determine it? Or should the device does re-negotiation? I am pretty sure SDP semantics is bad for modern RTC communications like those we expect to take place in WebRTC. --0015175df19ee5669904e2a55c54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
El 29/07/2013 13:29, "Eric Rescorla" <ekr@rtfm.com> escribi=C3=B3:
>
>
>
>
> On Mon, Jul 29, 2013 at 11:32 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>>
>>
>> - The conference server offers 8 audio tracks from 8 clients witho= ut webcam.
>> - The browser *wants* to offer 1 audio track + =C2=A01 video track= (it does
>> have webcam).
>>
>> FAIL !!! You cannot do that with SDP! The browser MUST reply with<= br> >> exactly 8 m=3Daudio lines and ZERO m=3Dvideo lines, so if the brow= ser
>> wants to add video it must re-negotiate later by adding a video tr= ack
>> (a new SDP O/A round trip).
>
>
> Obviously the conference server could be foolish in this way, but in > the type of scenario you suggest, the conference server would most
> likely offer 8 sendonly audio tracks (for sending audio to the client)=
> and then one recvonly audio track and one recvonly video track
> to elicit the client's a/v session, which will work reasonably wel= l.

And what about if the browser/device has two webcams (letf a= nd right) and wants to send both? How can the server determine it? Or shoul= d the device does re-negotiation?

I am pretty sure SDP semantics is bad for modern RTC communi= cations like those we expect to take place in WebRTC.

--0015175df19ee5669904e2a55c54-- From christer.holmberg@ericsson.com Mon Jul 29 05: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 E8F0B21F85E6 for ; Mon, 29 Jul 2013 05:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.759 X-Spam-Level: X-Spam-Status: No, score=-3.759 tagged_above=-999 required=5 tests=[AWL=-2.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 MgoDDwiM0bLQ for ; Mon, 29 Jul 2013 05:24:34 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F37C21F9AB4 for ; Mon, 29 Jul 2013 05:24:25 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-1e-51f65ef619aa Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.48.11907.6FE56F15; Mon, 29 Jul 2013 14:24:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 14:24:22 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Eric Rescorla Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiHdm/eCEDVXXHUmH2aQmC+8qS5lzwdGAgAAcJYCAACd5gIAALo6AgAACo4CAAAmgAIAABawAgAAKVgCAABFYAIAENUUAgABffESAANubgIABeI2AgAAgfQCAAAt1AIAAJBdw Date: Mon, 29 Jul 2013 12:24:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C412B01ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre63uG+BBv33xCxWvD7HbrFm5wQW i+n7bCymLn/M4sDica7hPbvHkiU/mTz+vwn0mPy4jTmAJYrLJiU1J7MstUjfLoEr48OBVqaC XZkVD081sDQwnknrYuTkkBAwkfgzYy8jhC0mceHeerYuRi4OIYGjjBJNuzYzQjhLGCUuvLrJ 3MXIwcEmYCHR/U8bpEFEIEZi4cszjCBhZgFHiW+XweYIC7hJzFj+mRGixF1i/ZRHYGNEBKYx Svy7s4kZJMEioCpx4uc6FhCbV8BXYuLFA+wQu3rYJA4emgVWxCkQKLGu+TY7iM0IdN33U2uY QGxmAXGJDwevM0NcLSCxZM95KFtU4uXjf6wQtpLEjw2XWCDq8yUmPT/DBLFMUOLkzCcsExhF ZyEZNQtJ2SwkZbPAftOUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYOYpTi5Ny040MNjEC I+/glt8WOxgv/7U5xCjNwaIkzrtF70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsb6Esbf tRtVX/sHZruJ30yftefu1Ks5y2exOks77q7iULacEVbyvNftyJGVKoxcs9hcgzfzm05cm6mj njw36wer5JP3hkElB9dt3P9N8JG/fnOn3eXwmeqXnf5rXPd7GnFQ/+npWbv+zDU8tvaDRYdb lp+Iw6fSbevf8V99H3pj8cyXR/Ov9FYosRRnJBpqMRcVJwIAshwJGYoCAAA= Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 12:24:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C412B01ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vIG1hdHRlciB3aGF0IHByb3RvY29sIHlvdSB1c2UsIGhvdyBjYW4gdGhlIHNlcnZl ciBrbm93IHdoYXQgdGhlIGJyb3dzZXIg4oCcd2FudHMgdG8gZG/igJ0gYmVmb3JlIHRoZSBzZXJ2 ZXIgaGFzIGV2ZW4gY29udGFjdGVkIHRoZSBicm93c2VyPz8/DQoNCldoZW4gdXNpbmcgU0lQIG9u IHRoZSB3aXJlLCB0aGUgYnJvd3NlciBjb3VsZCBzZW5kIGEgUkVHSVNURVIgcmVxdWVzdCBhbmQg cHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCBpdHMgbWVkaWEgY2FwYWJpbGl0aWVzIChudW1iZXIg b2YgY2FtZXJhcyBldGMpLCB3aGljaCB0aGUgc2VydmVyIGNhbiB0aGVuIGxhdGVyIHVzZSB3aGVu IGdlbmVyYXRpbmcgdGhlIE9mZmVyIHRvd2FyZHMgdGhlIGJyb3dzZXIuDQoNCkFsdGVybmF0aXZl bHksIHRoZSBzZXJ2ZXIgY2FuIHNlbmQgYW4gT1BUSU9OUyB0byB0aGUgYnJvd3NlciwgY2FuIHRo ZSByZXNwb25zZSB3b3VsZCBjb250YWluIHNpbWlsYXIgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbi4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KTMOkaGV0dMOkasOkOiBJw7Fha2kgQmF6IENhc3Rp bGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCkzDpGhldGV0dHk6IDI5LiBoZWluw6RrdXV0YSAy MDEzIDE1OjA5DQpWYXN0YWFub3R0YWphOiBFcmljIFJlc2NvcmxhDQpLb3BpbzogRW1pbCBJdm92 OyBDaHJpc3RlciBIb2xtYmVyZzsgTU1VU0lDIElFVEYgV0cNCkFpaGU6IFJlOiBbTU1VU0lDXSBb cnRjd2ViXSBBYm91dCB1bmlmaWVkIFBsYW4gYW5kIG11bHRpcGxlIG0gbGluZXMNCg0KDQotLQ0K ScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ8bWFpbHRvOmliY0BhbGlheC5uZXQ+ Pg0KRWwgMjkvMDcvMjAxMyAxMzoyOSwgIkVyaWMgUmVzY29ybGEiIDxla3JAcnRmbS5jb208bWFp bHRvOmVrckBydGZtLmNvbT4+IGVzY3JpYmnDszoNCj4NCj4NCj4NCj4NCj4gT24gTW9uLCBKdWwg MjksIDIwMTMgYXQgMTE6MzIgQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ8 bWFpbHRvOmliY0BhbGlheC5uZXQ+PiB3cm90ZToNCj4+DQo+Pg0KPj4gLSBUaGUgY29uZmVyZW5j ZSBzZXJ2ZXIgb2ZmZXJzIDggYXVkaW8gdHJhY2tzIGZyb20gOCBjbGllbnRzIHdpdGhvdXQgd2Vi Y2FtLg0KPj4gLSBUaGUgYnJvd3NlciAqd2FudHMqIHRvIG9mZmVyIDEgYXVkaW8gdHJhY2sgKyAg MSB2aWRlbyB0cmFjayAoaXQgZG9lcw0KPj4gaGF2ZSB3ZWJjYW0pLg0KPj4NCj4+IEZBSUwgISEh IFlvdSBjYW5ub3QgZG8gdGhhdCB3aXRoIFNEUCEgVGhlIGJyb3dzZXIgTVVTVCByZXBseSB3aXRo DQo+PiBleGFjdGx5IDggbT1hdWRpbyBsaW5lcyBhbmQgWkVSTyBtPXZpZGVvIGxpbmVzLCBzbyBp ZiB0aGUgYnJvd3Nlcg0KPj4gd2FudHMgdG8gYWRkIHZpZGVvIGl0IG11c3QgcmUtbmVnb3RpYXRl IGxhdGVyIGJ5IGFkZGluZyBhIHZpZGVvIHRyYWNrDQo+PiAoYSBuZXcgU0RQIE8vQSByb3VuZCB0 cmlwKS4NCj4NCj4NCj4gT2J2aW91c2x5IHRoZSBjb25mZXJlbmNlIHNlcnZlciBjb3VsZCBiZSBm b29saXNoIGluIHRoaXMgd2F5LCBidXQgaW4NCj4gdGhlIHR5cGUgb2Ygc2NlbmFyaW8geW91IHN1 Z2dlc3QsIHRoZSBjb25mZXJlbmNlIHNlcnZlciB3b3VsZCBtb3N0DQo+IGxpa2VseSBvZmZlciA4 IHNlbmRvbmx5IGF1ZGlvIHRyYWNrcyAoZm9yIHNlbmRpbmcgYXVkaW8gdG8gdGhlIGNsaWVudCkN Cj4gYW5kIHRoZW4gb25lIHJlY3Zvbmx5IGF1ZGlvIHRyYWNrIGFuZCBvbmUgcmVjdm9ubHkgdmlk ZW8gdHJhY2sNCj4gdG8gZWxpY2l0IHRoZSBjbGllbnQncyBhL3Ygc2Vzc2lvbiwgd2hpY2ggd2ls bCB3b3JrIHJlYXNvbmFibHkgd2VsbC4NCg0KQW5kIHdoYXQgYWJvdXQgaWYgdGhlIGJyb3dzZXIv ZGV2aWNlIGhhcyB0d28gd2ViY2FtcyAobGV0ZiBhbmQgcmlnaHQpIGFuZCB3YW50cyB0byBzZW5k IGJvdGg/IEhvdyBjYW4gdGhlIHNlcnZlciBkZXRlcm1pbmUgaXQ/IE9yIHNob3VsZCB0aGUgZGV2 aWNlIGRvZXMgcmUtbmVnb3RpYXRpb24/DQoNCkkgYW0gcHJldHR5IHN1cmUgU0RQIHNlbWFudGlj cyBpcyBiYWQgZm9yIG1vZGVybiBSVEMgY29tbXVuaWNhdGlvbnMgbGlrZSB0aG9zZSB3ZSBleHBl Y3QgdG8gdGFrZSBwbGFjZSBpbiBXZWJSVEMuDQo= --_000_7594FB04B1934943A5C02806D1A2204B1C412B01ESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJTZWxpdGV0ZWtzdGkgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TZWxpdGV0ZWtzdGlDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJTZWxpdGV0ZWtzdGkgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOlNlbGl0ZXRla3N0aTsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Rkk7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIG1hdHRlciB3aGF0 IHByb3RvY29sIHlvdSB1c2UsIGhvdyBjYW4gdGhlIHNlcnZlciBrbm93IHdoYXQgdGhlIGJyb3dz ZXIg4oCcd2FudHMgdG8gZG/igJ0gYmVmb3JlIHRoZSBzZXJ2ZXIgaGFzIGV2ZW4gY29udGFjdGVk IHRoZSBicm93c2VyPz8/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4g dXNpbmcgU0lQIG9uIHRoZSB3aXJlLCB0aGUgYnJvd3NlciBjb3VsZCBzZW5kIGEgUkVHSVNURVIg cmVxdWVzdCBhbmQgcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCBpdHMgbWVkaWEgY2FwYWJpbGl0 aWVzIChudW1iZXIgb2YgY2FtZXJhcyBldGMpLA0KIHdoaWNoIHRoZSBzZXJ2ZXIgY2FuIHRoZW4g bGF0ZXIgdXNlIHdoZW4gZ2VuZXJhdGluZyB0aGUgT2ZmZXIgdG93YXJkcyB0aGUgYnJvd3Nlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWx0ZXJuYXRpdmVseSwgdGhlIHNl cnZlciBjYW4gc2VuZCBhbiBPUFRJT05TIHRvIHRoZSBicm93c2VyLCBjYW4gdGhlIHJlc3BvbnNl IHdvdWxkIGNvbnRhaW4gc2ltaWxhciBjYXBhYmlsaXR5IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Mw6RoZXR0w6Rq w6Q6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJ w7Fha2kgQmF6IENhc3RpbGxvIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxh IGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0Ij48c3BhbiBsYW5nPSJFTi1VUyI+bWFpbHRvOmli Y0BhbGlheC5uZXQ8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPkzDpGhldGV0dHk6PC9iPiAyOS4gaGVpbsOka3V1dGEg MjAxMyAxNTowOTxicj4NCjxiPlZhc3RhYW5vdHRhamE6PC9iPiBFcmljIFJlc2NvcmxhPGJyPg0K PGI+S29waW86PC9iPiBFbWlsIEl2b3Y7IENocmlzdGVyIEhvbG1iZXJnOyBNTVVTSUMgSUVURiBX Rzxicj4NCjxiPkFpaGU6PC9iPiBSZTogW01NVVNJQ10gW3J0Y3dlYl0gQWJvdXQgdW5pZmllZCBQ bGFuIGFuZCBtdWx0aXBsZSBtIGxpbmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4tLTxicj4NCknDsWFraSBCYXogQ2FzdGlsbG88YnI+ DQombHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+aWJjQGFsaWF4Lm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+ DQpFbCAyOS8wNy8yMDEzIDEzOjI5LCAmcXVvdDtFcmljIFJlc2NvcmxhJnF1b3Q7ICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPmVrckBy dGZtLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZXNjcmliacOzOjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1vbiwgSnVs IDI5LCAyMDEzIGF0IDExOjMyIEFNLCBJw7Fha2kgQmF6IENhc3RpbGxvICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPjxzcGFuIGxhbmc9IkVOLVVTIj5pYmNAYWxpYXgu bmV0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLSBUaGUgY29uZmVyZW5jZSBzZXJ2ZXIgb2Zm ZXJzIDggYXVkaW8gdHJhY2tzIGZyb20gOCBjbGllbnRzIHdpdGhvdXQgd2ViY2FtLjxicj4NCiZn dDsmZ3Q7IC0gVGhlIGJyb3dzZXIgKndhbnRzKiB0byBvZmZlciAxIGF1ZGlvIHRyYWNrICYjNDM7 ICZuYnNwOzEgdmlkZW8gdHJhY2sgKGl0IGRvZXM8YnI+DQomZ3Q7Jmd0OyBoYXZlIHdlYmNhbSku PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGQUlMICEhISBZb3UgY2Fubm90IGRvIHRoYXQg d2l0aCBTRFAhIFRoZSBicm93c2VyIE1VU1QgcmVwbHkgd2l0aDxicj4NCiZndDsmZ3Q7IGV4YWN0 bHkgOCBtPWF1ZGlvIGxpbmVzIGFuZCBaRVJPIG09dmlkZW8gbGluZXMsIHNvIGlmIHRoZSBicm93 c2VyPGJyPg0KJmd0OyZndDsgd2FudHMgdG8gYWRkIHZpZGVvIGl0IG11c3QgcmUtbmVnb3RpYXRl IGxhdGVyIGJ5IGFkZGluZyBhIHZpZGVvIHRyYWNrPGJyPg0KJmd0OyZndDsgKGEgbmV3IFNEUCBP L0Egcm91bmQgdHJpcCkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9idmlvdXNseSB0 aGUgY29uZmVyZW5jZSBzZXJ2ZXIgY291bGQgYmUgZm9vbGlzaCBpbiB0aGlzIHdheSwgYnV0IGlu PGJyPg0KJmd0OyB0aGUgdHlwZSBvZiBzY2VuYXJpbyB5b3Ugc3VnZ2VzdCwgdGhlIGNvbmZlcmVu Y2Ugc2VydmVyIHdvdWxkIG1vc3Q8YnI+DQomZ3Q7IGxpa2VseSBvZmZlciA4IHNlbmRvbmx5IGF1 ZGlvIHRyYWNrcyAoZm9yIHNlbmRpbmcgYXVkaW8gdG8gdGhlIGNsaWVudCk8YnI+DQomZ3Q7IGFu ZCB0aGVuIG9uZSByZWN2b25seSBhdWRpbyB0cmFjayBhbmQgb25lIHJlY3Zvbmx5IHZpZGVvIHRy YWNrPGJyPg0KJmd0OyB0byBlbGljaXQgdGhlIGNsaWVudCdzIGEvdiBzZXNzaW9uLCB3aGljaCB3 aWxsIHdvcmsgcmVhc29uYWJseSB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIj5BbmQgd2hhdCBhYm91dCBpZiB0aGUgYnJvd3Nlci9kZXZpY2UgaGFzIHR3 byB3ZWJjYW1zIChsZXRmIGFuZCByaWdodCkgYW5kIHdhbnRzIHRvIHNlbmQgYm90aD8gSG93IGNh biB0aGUgc2VydmVyIGRldGVybWluZSBpdD8gT3Igc2hvdWxkIHRoZSBkZXZpY2UgZG9lcyByZS1u ZWdvdGlhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ SSBhbSBwcmV0dHkgc3VyZSBTRFAgc2VtYW50aWNzIGlzIGJhZCBmb3IgbW9kZXJuIFJUQyBjb21t dW5pY2F0aW9ucyBsaWtlIHRob3NlIHdlIGV4cGVjdCB0byB0YWtlIHBsYWNlIGluIFdlYlJUQy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1C412B01ESESSMB209erics_-- From ibc@aliax.net Mon Jul 29 05:45: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 0405021F9C55 for ; Mon, 29 Jul 2013 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 EaQgUCxlZuPe for ; Mon, 29 Jul 2013 05:45:28 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE121F9F6F for ; Mon, 29 Jul 2013 05:45:26 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so856864qcx.32 for ; Mon, 29 Jul 2013 05:45:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=K7d//SPaXD7HA1bWEgrWHaZmypA62YL+W9A3n3I90MA=; b=Sywd0BfiFiA1txFYrE5VRFt6U6bXZGJbxeu8tqR0pEqFa4nET3f3Wci7T9tdIbn6Jx RQJ2wnefURnmFYU4h9aL+9W3W1lgYYQ2P4GzLtrbscGkv2t9Gy2dtI6Y5DlywBvNFE8R x/tuPsoZMTypV0QHgNVvvvRN1eMO+E/DOUd5+LJVPosfDFlom/myA1qxqGimJ7StNiqW LocYFnjKd7o65WM591nx6P9aTvfkoxjCVUKTOuIVF2GZnDeFqU7ewCT0cOnefXUI14vQ SU4w9n42/Q5puZ0cA8s/c0bEbr8P0U17zKG5SW/S0sypBzQ4KIuTy6A1c3LTebWSuuyR cu6g== X-Received: by 10.49.84.164 with SMTP id a4mr26209216qez.4.1375101925246; Mon, 29 Jul 2013 05:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 05:45:05 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 14:45:05 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQllb+uoriVrUWvpG5xmxlN7ufhXn8ymxCuxLGVT+Xvk1hzmASo6fDKrheyFO9YhKlq7yLOJ Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 12:45:35 -0000 2013/7/29 Christer Holmberg : > No matter what protocol you use, how can the server know what the browser > =E2=80=9Cwants to do=E2=80=9D before the server has even contacted the br= owser??? Exactly !!! That is the point Christer. The server (the offerer in this case) MAY NOT know what the browser/client wants to offer (unless there is some kind of announcement via previous registration or there is a hardcoded scenario which well-known/proprietary devices). So, if we assume that the "session offerer" (the server in this case) MAY NOT be able to know which kind of media and/or how many tracks the browser would like to send, why do we mandate a media signaling protocol (SDP) in which the offerer MUST tell the browser/client how many tracks (and which kind of media) it can send?? SDP is the problem here. A good design would be someone in which the offerer (server) tells the browser "I will send you 8 audio tracks and 3 videos tracks" and the browser would reply "OK, I will send you 1 audio track and 2 video tracks". Or a more complete one: - The offerer tells the browser "I will send you 8 audio tracks and 3 videos tracks". - The browser confirms all the audio tracks but tells the server to disable 2 video tracks". - The browser tells the server "I will send you 1 audio track and 2 video tracks". - The server accepts receiving all of them. This is: an unidirectional-track-negotiation media protocol. But that is not what SDP is, so here we are. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Jul 29 05:56: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 0F82721F9B12 for ; Mon, 29 Jul 2013 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.136, 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 SvYFkTkY5EXc for ; Mon, 29 Jul 2013 05:55:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51821F85F4 for ; Mon, 29 Jul 2013 05:55:52 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-7c-51f66657acd0 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 71.04.00725.75666F15; Mon, 29 Jul 2013 14:55:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 14:55:51 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiHdm/eCEDVXXHUmH2aQmC+8qS5lzwdGAgAAcJYCAACd5gIAALo6AgAACo4CAAAmgAIAABawAgAAKVgCAABFYAIAENUUAgABffESAANubgIABeI2AgAAgfQCAAAt1AIAAJBdw///l5ICAACJtEA== Date: Mon, 29 Jul 2013 12:55:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrW542rdAg7uXFCxWvD7HbrFm5wQW i+n7bCymLn/M4sDica7hPbvHkiU/mTz+vwn0mPy4jTmAJYrLJiU1J7MstUjfLoEr4/6MJ8wF P4Qquk/uYG5g3CHUxcjJISFgIjHnyX0WCFtM4sK99WxdjFwcQgKHGSU6d/xhh3CWMEo8m9nK 1MXIwcEmYCHR/U8bpEFEwEbi34UL7CA2s0CiRO/T/UwgtrCAm8SM5Z8ZIWrcJdZPecQIMkdE YBmjRPej+2wgCRYBVYnDt6Ywg8zkFfCVmPeIFWLXdHaJzxua2EHinAKBEv0PnUHKGYGO+35q DRPELnGJDwevM0McLSCxZM95KFtU4uXjf6wQtpLEjw2XWEDGMAtoSqzfpQ/Rqigxpfsh2Mm8 AoISJ2c+YZnAKDYLydRZCB2zkHTMQtKxgJFlFSN7bmJmTnq54SZGYAwd3PJbdwfjqXMihxil OViUxHk36Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIv4NDy/LfqusV3EH79yY3hDJV /i1OqLzp2P1XUnHb0ddHFi648uDRlo1R6rpcsR4pIREnTEXu7Mu+ltLl/WNiXv+hkJtrl7KG a1w91TjbYvndc7av1T0+TtY13Sn5+MvyRZd7L1sHbFDJEbA+WrrsWcrDK2V2dde3vDXOal9t dXHq3CpuS+98JZbijERDLeai4kQAEVUf5G8CAAA= Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 12:56:01 -0000 SGksDQoNCj4+IE5vIG1hdHRlciB3aGF0IHByb3RvY29sIHlvdSB1c2UsIGhvdyBjYW4gdGhlIHNl cnZlciBrbm93IHdoYXQgdGhlIA0KPj4gYnJvd3NlciDigJx3YW50cyB0byBkb+KAnSBiZWZvcmUg dGhlIHNlcnZlciBoYXMgZXZlbiBjb250YWN0ZWQgdGhlIGJyb3dzZXI/Pz8NCj4NCj4gRXhhY3Rs eSAhISENCj4NCj4gVGhhdCBpcyB0aGUgcG9pbnQgQ2hyaXN0ZXIuIFRoZSBzZXJ2ZXIgKHRoZSBv ZmZlcmVyIGluIHRoaXMgY2FzZSkgTUFZIE5PVCBrbm93IHdoYXQgdGhlIGJyb3dzZXIvY2xpZW50 IHdhbnRzIHRvIG9mZmVyICh1bmxlc3MgdGhlcmUgaXMgc29tZSBraW5kIG9mIGFubm91bmNlbWVu dCANCj4gdmlhIHByZXZpb3VzIHJlZ2lzdHJhdGlvbiBvciB0aGVyZSBpcyBhIGhhcmRjb2RlZCBz Y2VuYXJpbyB3aGljaCB3ZWxsLWtub3duL3Byb3ByaWV0YXJ5IGRldmljZXMpLg0KPg0KPiBTbywg aWYgd2UgYXNzdW1lIHRoYXQgdGhlICJzZXNzaW9uIG9mZmVyZXIiICh0aGUgc2VydmVyIGluIHRo aXMgY2FzZSkgTUFZIE5PVCBiZSBhYmxlIHRvIGtub3cgd2hpY2gga2luZCBvZiBtZWRpYSBhbmQv b3IgaG93IG1hbnkgdHJhY2tzIHRoZSBicm93c2VyIHdvdWxkIGxpa2UgDQo+IHRvIHNlbmQsIHdo eSBkbyB3ZSBtYW5kYXRlIGEgbWVkaWEgc2lnbmFsaW5nIHByb3RvY29sIChTRFApIGluIHdoaWNo IHRoZSBvZmZlcmVyIE1VU1QgdGVsbCB0aGUgYnJvd3Nlci9jbGllbnQgaG93IG1hbnkgdHJhY2tz IChhbmQgd2hpY2gga2luZCBvZiBtZWRpYSkgaXQgY2FuIHNlbmQ/Pw0KPg0KPlNEUCBpcyB0aGUg cHJvYmxlbSBoZXJlLg0KPg0KPiBBIGdvb2QgZGVzaWduIHdvdWxkIGJlIHNvbWVvbmUgaW4gd2hp Y2ggdGhlIG9mZmVyZXIgKHNlcnZlcikgdGVsbHMgdGhlIGJyb3dzZXIgIkkgd2lsbCBzZW5kIHlv dSA4IGF1ZGlvIHRyYWNrcyBhbmQgMyB2aWRlb3MgdHJhY2tzIiBhbmQgdGhlIGJyb3dzZXIgd291 bGQgcmVwbHkgIk9LLCBJIHdpbGwgc2VuZCB5b3UgMSBhdWRpbyB0cmFjayBhbmQgMiB2aWRlbyB0 cmFja3MiLiANCg0KU291bmRzIGxpa2UgSC4yNDUgOikNCg0KPiBPciBhIG1vcmUgY29tcGxldGUg b25lOg0KPg0KPiAtIFRoZSBvZmZlcmVyIHRlbGxzIHRoZSBicm93c2VyICJJIHdpbGwgc2VuZCB5 b3UgOCBhdWRpbyB0cmFja3MgYW5kIDMgdmlkZW9zIHRyYWNrcyIuDQo+DQo+IC0gVGhlIGJyb3dz ZXIgY29uZmlybXMgYWxsIHRoZSBhdWRpbyB0cmFja3MgYnV0IHRlbGxzIHRoZSBzZXJ2ZXIgdG8g ZGlzYWJsZSAyIHZpZGVvIHRyYWNrcyIuDQo+DQo+IC0gVGhlIGJyb3dzZXIgdGVsbHMgdGhlIHNl cnZlciAiSSB3aWxsIHNlbmQgeW91IDEgYXVkaW8gdHJhY2sgYW5kIDIgdmlkZW8gdHJhY2tzIi4N Cj4NCj4gLSBUaGUgc2VydmVyIGFjY2VwdHMgcmVjZWl2aW5nIGFsbCBvZiB0aGVtLg0KPg0KPiBU aGlzIGlzOiBhbiB1bmlkaXJlY3Rpb25hbC10cmFjay1uZWdvdGlhdGlvbiBtZWRpYSBwcm90b2Nv bC4gQnV0IHRoYXQgaXMgbm90IHdoYXQgU0RQIGlzLCBzbyBoZXJlIHdlIGFyZS4NCg0KWW91IENB TiBkbyB0aGlzIHdpdGggU0RQLCB1c2luZyB1bmktZGlyZWN0aW9uYWwgc3RyZWFtczogdGhlIHNl cnZlciBvZmZlciA4KzMgc2VuZG9ubHkgc3RyZWFtcywgYW5kIHRoZW4gdGhlIGJyb3dzZXIgb2Zm ZXJzIDEtMyBzZW5kb25seSBzdHJlYW1zLg0KDQooSSBETyBhZ3JlZSBpdCBpcyBub3QgaG93IFNE UCBoYXMgdHJhZGl0aW9uYWxseSBiZWVuIHVzZWQpDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg== From ibc@aliax.net Mon Jul 29 07:33: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 4FD8921F9BC4 for ; Mon, 29 Jul 2013 07:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 PjK4AS8600nq for ; Mon, 29 Jul 2013 07:33:15 -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 A342221F8AA1 for ; Mon, 29 Jul 2013 07:32:43 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f14so1717965qak.16 for ; Mon, 29 Jul 2013 07:32:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Y5PmVaWPJg+pOAcRqvTLZ6oZngccKYvFvEvZJQgoJqo=; b=jzmbVhTKMrHyvV5TmcHWZbAaZoLaQoQX7XdWuctrq8gaBPtXn0O+as5uDoSfR7ChHt L7HpMR0sngi2aSe1IZaQXiEHf3ecul/iNZKgARfeHCKtQpTO2k2caVt4j9XWOV2l0BbE db2LIu6ODuofq4eNQLMvu1f1lp5iQQzxBdTvW6JtglUUXIqra1QsFRII7CcG+nh+siZq v1k+yd4o1xXKXDbSDcEgqehv23K1eRrte2yzSAHwd07xojwjvMp9TSKmXhjLO1aoUCcV hMCb+2bLxUiv/0oQeb7rXNWLcHiATMttaZTl8Pndqivm9TM/CsXD11nkuQulFreHtX0Q IN9g== X-Received: by 10.49.116.176 with SMTP id jx16mr70801518qeb.52.1375108350897; Mon, 29 Jul 2013 07:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 07:32:10 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 16:32:10 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZr2m4Rx29UYW/JoYwuA1IB+zSWkDIqm0X8fHu8l0vjuDzfWryRv7bpnQ/ChdvPzzpMKzV Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 14:33:22 -0000 2013/7/29 Christer Holmberg : >> Or a more complete one: >> >> - The offerer tells the browser "I will send you 8 audio tracks and 3 vi= deos tracks". >> >> - The browser confirms all the audio tracks but tells the server to disa= ble 2 video tracks". >> >> - The browser tells the server "I will send you 1 audio track and 2 vide= o tracks". >> >> - The server accepts receiving all of them. >> >> This is: an unidirectional-track-negotiation media protocol. But that is= not what SDP is, so here we are. > > You CAN do this with SDP, using uni-directional streams: the server offer= 8+3 sendonly streams, and then the browser offers 1-3 sendonly streams. > > (I DO agree it is not how SDP has traditionally been used) And sure you agree that WebRTC browsers and devices will NOT allow that because, regardless how "flexible" SDP is, the fact is that devices do not allow all that flexibility. So my concerns (and Emil's ones) remain alive. But, for simplifying, I will summarize them in a single question: - Alice, using her browser, can enter in an *active* audio/video conference in which there are already 8 participants. - The browser sends the SDP offer to the conference server. - Should the browser *know* that there are 8 participants (so it should add 8 m=3Daudio and 8 m=3Dvideo lines)? - Or should it just add a single audio and video m lines? If so, could the server reply a SDP answer with 9 audio lines and 9 video lines? really? I am 100% sure that browsers will not understand it. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Mon Jul 29 07:49: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 7C7AB21F84EF for ; Mon, 29 Jul 2013 07:49:52 -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, 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 uk11jqjFf9MZ for ; Mon, 29 Jul 2013 07:49:46 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id 7958F21F997B for ; Mon, 29 Jul 2013 07:49:45 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 6Dve1m0051wfjNsA4EplXX; Mon, 29 Jul 2013 14:49:45 +0000 Received: from dhcp-43d2.meeting.ietf.org ([130.129.67.210]) by omta23.emeryville.ca.mail.comcast.net with comcast id 6Enb1m00R4YBfqS8jEneak; Mon, 29 Jul 2013 14:47:43 +0000 Message-ID: <51F68086.9050704@alum.mit.edu> Date: Mon, 29 Jul 2013 16:47:34 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375109385; bh=jremYQ2cbsmO85qsbBRZa9oDbqRr2m8KRtrQ1NkPO7I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BMLI9CD8QsG8fVZ7BpZC3Sovf9tPIG3Q4KjO6EKYn5K9+ErK7jjYgu78RJfAJP+AY Ud4l9YRGUW7FJY32qcfu4reNtt1fQ61grL3oZ1Q6ItBPbi3bFviGcOnVBsRejd2oh6 dUX5X1aDd0vZKh4KR2blPRXo7WpyZ60Dk19WnhjhQE7m32HEyJyZl4ga48MGzdht3V 0o/E7lBkF0P9HhOOTseqbFypskb8I9WHwqyhF/iSUR8bNn3d0tFLBDYej4/fg7TAWp qHm3e6vY7LAZOGCEMOOxAWFWmpcENQWmYIPC+oHnztpzimDeNxOWVzBJxk4XgMMQ2L bCCWDw+X9MEBg== Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 14:49:52 -0000 On 7/29/13 4:32 PM, Iñaki Baz Castillo wrote: > 2013/7/29 Christer Holmberg : >>> Or a more complete one: >>> >>> - The offerer tells the browser "I will send you 8 audio tracks and 3 videos tracks". >>> >>> - The browser confirms all the audio tracks but tells the server to disable 2 video tracks". >>> >>> - The browser tells the server "I will send you 1 audio track and 2 video tracks". >>> >>> - The server accepts receiving all of them. >>> >>> This is: an unidirectional-track-negotiation media protocol. But that is not what SDP is, so here we are. >> >> You CAN do this with SDP, using uni-directional streams: the server offer 8+3 sendonly streams, and then the browser offers 1-3 sendonly streams. >> >> (I DO agree it is not how SDP has traditionally been used) > > And sure you agree that WebRTC browsers and devices will NOT allow > that because, regardless how "flexible" SDP is, the fact is that > devices do not allow all that flexibility. > > So my concerns (and Emil's ones) remain alive. But, for simplifying, I > will summarize them in a single question: > > - Alice, using her browser, can enter in an *active* audio/video > conference in which there are already 8 participants. > > - The browser sends the SDP offer to the conference server. > > - Should the browser *know* that there are 8 participants (so it > should add 8 m=audio and 8 m=video lines)? Probably not. Maybe in some cases it can. (Because the web server told it.) > - Or should it just add a single audio and video m lines? This is certainly the straightforward thing to do. > If so, could > the server reply a SDP answer with 9 audio lines and 9 video lines? > really? I am 100% sure that browsers will not understand it. No, this is not valid SDP. The best that can be done is for the server to answer the two m-lines. And then to send another offer that adds the other m-lines. This is not ideal. But migrating away from SDP for sip has been tried and given up as infeasible. Conceivably something different can be done for rtcweb if it wants to diverge from SDP and/or O/A. But if so, then the gatewaying to sip will be harder. Perhaps we should reconstitute SDPng for rtcweb. :-) Thanks, Paul From christer.holmberg@ericsson.com Mon Jul 29 08: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 CB21D21F9C01 for ; Mon, 29 Jul 2013 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=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 94ai4ihhoDCi for ; Mon, 29 Jul 2013 08:03:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8601921F9017 for ; Mon, 29 Jul 2013 08:03:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-ce-51f6844956a0 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AF.01.00725.94486F15; Mon, 29 Jul 2013 17:03:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 17:03:36 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiHdm/eCEDVXXHUmH2aQmC+8qS5lzwdGAgAAcJYCAACd5gIAALo6AgAACo4CAAAmgAIAABawAgAAKVgCAABFYAIAENUUAgABffESAANubgIABeI2AgAAgfQCAAAt1AIAAJBdw///l5ICAACJtEP//+34AgAAoNAA= Date: Mon, 29 Jul 2013 15:03:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvra5ny7dAg79vlCxWvD7HbrFm5wQW i+n7bCymLn/M4sDica7hPbvHkiU/mTz+vwn0mPy4jTmAJYrLJiU1J7MstUjfLoEr48KiG0wF x8Qq7p9sZ2xg/CPaxcjJISFgItG6+hwrhC0mceHeerYuRi4OIYHDjBL/VnyCcpYwSjw+/JO5 i5GDg03AQqL7nzZIg4iAjcS/CxfYQWxmgUSJ3qf7mUBsYQE3iRnLPzNC1LhLrJ/yiBFkjojA JkaJ71tfMIMkWARUJf4unwG2mVfAV+LelcWsEMsWcUj86d/IBLKMUyBQYsl1F5AaRqDrvp9a wwSxTFziw8HrzBBXC0gs2XMeyhaVePn4H9Q3ShKNS56wgoxhFtCUWL9LH6JVUWJK90N2iLWC EidnPmGZwCg2C8nUWQgds5B0zELSsYCRZRUje25iZk56ueEmRmAUHdzyW3cH46lzIocYpTlY lMR5N+mdCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6D31fWLEfF4rdtnrrC826NV1Tc27 wP9aQcip4EXVL9aiQyEOerNP7zfunxkwed0ls8daLuU+1dN3X0led0h27psUs2OHD7tx1N4N XPl6r9UlwZcFWhfTDXntmQRFtjU3bDZhym5fF3Z1Xv3OzMuPn8y4pXO0yn2d8ASWj/8eP16T e0nMP8zyhBJLcUaioRZzUXEiABBp/MxwAgAA Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 15:03:52 -0000 SGksDQoNCj4+PiBPciBhIG1vcmUgY29tcGxldGUgb25lOg0KPj4+DQo+Pj4gLSBUaGUgb2ZmZXJl ciB0ZWxscyB0aGUgYnJvd3NlciAiSSB3aWxsIHNlbmQgeW91IDggYXVkaW8gdHJhY2tzIGFuZCAz IHZpZGVvcyB0cmFja3MiLg0KPj4+DQo+Pj4gLSBUaGUgYnJvd3NlciBjb25maXJtcyBhbGwgdGhl IGF1ZGlvIHRyYWNrcyBidXQgdGVsbHMgdGhlIHNlcnZlciB0byBkaXNhYmxlIDIgdmlkZW8gdHJh Y2tzIi4NCj4+Pg0KPj4+IC0gVGhlIGJyb3dzZXIgdGVsbHMgdGhlIHNlcnZlciAiSSB3aWxsIHNl bmQgeW91IDEgYXVkaW8gdHJhY2sgYW5kIDIgdmlkZW8gdHJhY2tzIi4NCj4+Pg0KPj4+IC0gVGhl IHNlcnZlciBhY2NlcHRzIHJlY2VpdmluZyBhbGwgb2YgdGhlbS4NCj4+Pg0KPj4+IFRoaXMgaXM6 IGFuIHVuaWRpcmVjdGlvbmFsLXRyYWNrLW5lZ290aWF0aW9uIG1lZGlhIHByb3RvY29sLiBCdXQg dGhhdCBpcyBub3Qgd2hhdCBTRFAgaXMsIHNvIGhlcmUgd2UgYXJlLg0KPj4NCj4+IFlvdSBDQU4g ZG8gdGhpcyB3aXRoIFNEUCwgdXNpbmcgdW5pLWRpcmVjdGlvbmFsIHN0cmVhbXM6IHRoZSBzZXJ2 ZXIgb2ZmZXIgOCszIHNlbmRvbmx5IHN0cmVhbXMsIGFuZCB0aGVuIHRoZSBicm93c2VyIG9mZmVy cyAxLTMgc2VuZG9ubHkgc3RyZWFtcy4NCj4+DQo+PiAoSSBETyBhZ3JlZSBpdCBpcyBub3QgaG93 IFNEUCBoYXMgdHJhZGl0aW9uYWxseSBiZWVuIHVzZWQpDQo+DQo+IEFuZCBzdXJlIHlvdSBhZ3Jl ZSB0aGF0IFdlYlJUQyBicm93c2VycyBhbmQgZGV2aWNlcyB3aWxsIE5PVCBhbGxvdyB0aGF0IGJl Y2F1c2UsIHJlZ2FyZGxlc3MgaG93ICJmbGV4aWJsZSIgU0RQIGlzLCB0aGUgZmFjdCBpcyB0aGF0 IGRldmljZXMgZG8gbm90IGFsbG93IGFsbCB0aGF0IGZsZXhpYmlsaXR5Lg0KPg0KPiBTbyBteSBj b25jZXJucyAoYW5kIEVtaWwncyBvbmVzKSByZW1haW4gYWxpdmUuIEJ1dCwgZm9yIHNpbXBsaWZ5 aW5nLCBJIHdpbGwgc3VtbWFyaXplIHRoZW0gaW4gYSBzaW5nbGUgcXVlc3Rpb246DQo+DQo+IC0g QWxpY2UsIHVzaW5nIGhlciBicm93c2VyLCBjYW4gZW50ZXIgaW4gYW4gKmFjdGl2ZSogYXVkaW8v dmlkZW8gY29uZmVyZW5jZSBpbiB3aGljaCB0aGVyZSBhcmUgYWxyZWFkeSA4IHBhcnRpY2lwYW50 cy4NCj4NCj4gLSBUaGUgYnJvd3NlciBzZW5kcyB0aGUgU0RQIG9mZmVyIHRvIHRoZSBjb25mZXJl bmNlIHNlcnZlci4NCj4NCj4gLSBTaG91bGQgdGhlIGJyb3dzZXIgKmtub3cqIHRoYXQgdGhlcmUg YXJlIDggcGFydGljaXBhbnRzIChzbyBpdCBzaG91bGQgYWRkIDggbT1hdWRpbyBhbmQgOCBtPXZp ZGVvIGxpbmVzKT8NCj4NCj4gLSBPciBzaG91bGQgaXQganVzdCBhZGQgYSBzaW5nbGUgYXVkaW8g YW5kIHZpZGVvIG0gbGluZXM/IElmIHNvLCBjb3VsZCB0aGUgc2VydmVyIHJlcGx5IGEgU0RQIGFu c3dlciB3aXRoIDkgYXVkaW8gbGluZXMgYW5kIDkgdmlkZW8gbGluZXM/DQo+IHJlYWxseT8gSSBh bSAxMDAlIHN1cmUgdGhhdCBicm93c2VycyB3aWxsIG5vdCB1bmRlcnN0YW5kIGl0Lg0KDQpUaGUg YnJvd3NlciBjYW4sIGluIHRoZSBmaXJzdCBPZmZlciwgb25seSBpbmNsdWRlIDErMSBtLSBsaW5l cy4gVGhlbiwgdGhlIHNlcnZlciBjYW4gaW5mb3JtIHRoZSBicm93c2VyIGFib3V0IHRoZSBudW1i ZXIgb2YgcGFydGljaXBhbnRzLCBhbmQgdGhlIGJyb3dzZXIgY2FuIGNyZWF0ZSBhIHNlY29uZCBv ZmZlciBhY2NvcmRpbmdseSwgZS5nLiB3aXRoIDgrOCBtLSBsaW5lcy4NCg0KKC4uLm9yLCB0aGUg bnVtYmVyIG9mIHBhcnRpY2lwYW50cyBtaWdodCBiZSBwcm92aWRlZCB0byB0aGUgYnJvd3NlciBi ZWZvcmUgaXQgc2VuZHMgdGhlIGZpcnN0IG9mZmVyLikNCg0KSSB0aGluayBvbmUgcHJvYmxlbSBp cyB0aGF0IHBlb3BsZSBvZnRlbiBhcmUgc28gImZpeGF0ZWQiIGluIGRvaW5nIGV2ZXJ5dGhpbmcg aW4gYSBzaW5nbGUgTy9BIHRyYW5zYWN0aW9uLiBEdXJpbmcgdGhlIHNlc3Npb24gZXN0YWJsaXNo bWVudCwgaXQgZG9lc24ndCByZWFsbHkgbWF0dGVyIGlmIHlvdSBoYXZlIHRvIHNlbmQgb25lIG9y IHR3byBtb3JlIE9mZmVycyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0K From ibc@aliax.net Mon Jul 29 08:23: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 A68E621E805A for ; Mon, 29 Jul 2013 08:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 PaIn0P5HRilp for ; Mon, 29 Jul 2013 08:23:21 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5934321F9EFE for ; Mon, 29 Jul 2013 08:23:20 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so1745106qab.18 for ; Mon, 29 Jul 2013 08:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=usLaVCnm5pDOZrLE+nEFq+EPnarE1Y0KHJj5hCX3hCk=; b=V9QmlIrHTdIO4UtI1In32xuA8KViYG4gActXxw8oxjI2M4PPpXKzOQyF6ANASpKQuY Nns8YDfFIrtagiqYU6O/2pSYSn+aNIP91+yuIpT3/7tgnZ8ZlQ1VgyBK/vUtxQKbBIaA 4BCaiuBgITMONxzNFxZaBEk/wmroJHr4+yCojHZ+Du8rZ6Pu6Q/2Yz4po+Wug6VlE60f fOnKGb0fSZJohudaMotfSJI3xu1OfvsWLMvYYNUPbi48/SUAKb+Ys8r4hwRycQT7ILt8 rRlKnQxZgSE4MWjh1YdcQoB+Q5QVF0sp176ZIYnCD/q+m+EM4fFItNh37jmJs06y73F6 bSVw== X-Received: by 10.49.0.170 with SMTP id 10mr21077958qef.3.1375111400485; Mon, 29 Jul 2013 08:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 08:22:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 17:22:59 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQntx0mTfnS9R6l/avOhGX0SILywVcVdlzYlZCiEmAst2WpDuaKxJvTKXhYjxdCddGB8P9Bq Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 15:23:28 -0000 2013/7/29 Christer Holmberg : >> So my concerns (and Emil's ones) remain alive. But, for simplifying, I w= ill summarize them in a single question: >> >> - Alice, using her browser, can enter in an *active* audio/video confere= nce in which there are already 8 participants. >> >> - The browser sends the SDP offer to the conference server. >> >> - Should the browser *know* that there are 8 participants (so it should = add 8 m=3Daudio and 8 m=3Dvideo lines)? >> >> - Or should it just add a single audio and video m lines? If so, could t= he server reply a SDP answer with 9 audio lines and 9 video lines? >> really? I am 100% sure that browsers will not understand it. > > The browser can, in the first Offer, only include 1+1 m- lines. Then, the= server can inform the browser about the number of participants, Via custom signaling, right? so we have a media session signaling mandate (SDP O/A) which is not suitable for properly negotiating my very basic scenario. > and the browser can create a second offer accordingly, e.g. with 8+8 m- l= ines. > > (...or, the number of participants might be provided to the browser befor= e it sends the first offer.) Again via custom signaling. > I think one problem is that people often are so "fixated" in doing everyt= hing in a single O/A transaction. During the session establishment, it does= n't really matter if you have to send one or two more Offers :) May be that si good enough for SIP, but may be not for other (future) RTC protocols. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Jul 29 08:41: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 5490E21F9C4E for ; Mon, 29 Jul 2013 08:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=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 YfadNoKYZDTf for ; Mon, 29 Jul 2013 08:40:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6921F9B58 for ; Mon, 29 Jul 2013 08:40:53 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-8f-51f68d04945e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.9E.05990.40D86F15; Mon, 29 Jul 2013 17:40:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 17:40:52 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] [rtcweb] About unified Plan and multiple m lines Thread-Index: AQHOiHdm/eCEDVXXHUmH2aQmC+8qS5lzwdGAgAAcJYCAACd5gIAALo6AgAACo4CAAAmgAIAABawAgAAKVgCAABFYAIAENUUAgABffESAANubgIABeI2AgAAgfQCAAAt1AIAAJBdw///l5ICAACJtEP//+34AgAAoNAD//+X/gAAEfz1w Date: Mon, 29 Jul 2013 15:40:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrS5L77dAg8aTIhYrXp9jt1izcwKL xfR9NhZTlz9mcWDxONfwnt1jyZKfTB7/3wR6TH7cxhzAEsVlk5Kak1mWWqRvl8CVsfPcCdaC DwIVxw6tZm1g3CHQxcjJISFgIrF/7TxGCFtM4sK99WwgtpDAYUaJpX/quxi5gOwljBJzvt5n 7mLk4GATsJDo/qcNUiMiYCPx78IFdhCbWSBRovfpfiYQW1jATWLG8s+MEDXuEuunPGIEmSMi sI9R4suXMywgCRYBVYkXc96CNfMK+Eo8u/eJGWLxWk6JuVesQGxOgUCJtQc+s4LYjEDHfT+1 hglimbjEh4PXmSGOFpBYsuc8lC0q8fLxP1YIW0micckTVpCbmQU0Jdbv0odoVZSY0v0Qaq2g xMmZT1gmMIrNQjJ1FkLHLCQds5B0LGBkWcXInpuYmZNebrSJERhDB7f8Vt3BeOecyCFGaQ4W JXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwtnjfZ8zJqJjdKbpKu5tn+/03TxzN 3wjciDkeuU3i+laWxzPVe6cyvb1Zo/Ahn9tn1c8ZCzqOfgyXiblqwTFjXkXuk86FZvd6N196 dHeJzSvzKZqt5jOXf57n+zBfgZP56M7YwytCxH0XH7+c8Fz59JQ1ZzY+aBINqSt7kTHlcv4/ dl+3p5E9F5VYijMSDbWYi4oTAVtqi/BvAgAA Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 15:41:00 -0000 SGksDQoNCj4+PiBTbyBteSBjb25jZXJucyAoYW5kIEVtaWwncyBvbmVzKSByZW1haW4gYWxpdmUu IEJ1dCwgZm9yIHNpbXBsaWZ5aW5nLCBJIHdpbGwgc3VtbWFyaXplIHRoZW0gaW4gYSBzaW5nbGUg cXVlc3Rpb246DQo+Pj4NCj4+PiAtIEFsaWNlLCB1c2luZyBoZXIgYnJvd3NlciwgY2FuIGVudGVy IGluIGFuICphY3RpdmUqIGF1ZGlvL3ZpZGVvIGNvbmZlcmVuY2UgaW4gd2hpY2ggdGhlcmUgYXJl IGFscmVhZHkgOCBwYXJ0aWNpcGFudHMuDQo+Pj4NCj4+PiAtIFRoZSBicm93c2VyIHNlbmRzIHRo ZSBTRFAgb2ZmZXIgdG8gdGhlIGNvbmZlcmVuY2Ugc2VydmVyLg0KPj4+DQo+Pj4gLSBTaG91bGQg dGhlIGJyb3dzZXIgKmtub3cqIHRoYXQgdGhlcmUgYXJlIDggcGFydGljaXBhbnRzIChzbyBpdCBz aG91bGQgYWRkIDggbT1hdWRpbyBhbmQgOCBtPXZpZGVvIGxpbmVzKT8NCj4+Pg0KPj4+IC0gT3Ig c2hvdWxkIGl0IGp1c3QgYWRkIGEgc2luZ2xlIGF1ZGlvIGFuZCB2aWRlbyBtIGxpbmVzPyBJZiBz bywgY291bGQgdGhlIHNlcnZlciByZXBseSBhIFNEUCBhbnN3ZXIgd2l0aCA5IGF1ZGlvIGxpbmVz IGFuZCA5IHZpZGVvIGxpbmVzPw0KPj4+IHJlYWxseT8gSSBhbSAxMDAlIHN1cmUgdGhhdCBicm93 c2VycyB3aWxsIG5vdCB1bmRlcnN0YW5kIGl0Lg0KPj4NCj4+IFRoZSBicm93c2VyIGNhbiwgaW4g dGhlIGZpcnN0IE9mZmVyLCBvbmx5IGluY2x1ZGUgMSsxIG0tIGxpbmVzLiBUaGVuLCANCj4+IHRo ZSBzZXJ2ZXIgY2FuIGluZm9ybSB0aGUgYnJvd3NlciBhYm91dCB0aGUgbnVtYmVyIG9mIHBhcnRp Y2lwYW50cywNCj4NCj4gVmlhIGN1c3RvbSBzaWduYWxpbmcsIHJpZ2h0PyBzbyB3ZSBoYXZlIGEg bWVkaWEgc2Vzc2lvbiBzaWduYWxpbmcgbWFuZGF0ZSAoU0RQIE8vQSkgd2hpY2ggaXMgbm90IHN1 aXRhYmxlIGZvciBwcm9wZXJseSBuZWdvdGlhdGluZyBteSB2ZXJ5IGJhc2ljIHNjZW5hcmlvLg0K DQpTRFAgTy9BIGlzIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSBtZWRpYSBjaGFubmVscyAtIG5vdCB0 byBleGNoYW5nZSBnZW5lcmljIGNhcGFiaWxpdGllcyAoZS5nLiBudW1iZXIgb2YgcGFydGljaXBh bnRzIGluIHRoZSBjb25mZXJlbmNlKS4NCg0KU28sIHRoaXMgaXMgeW91ciBjaGFuY2UgdG8gYmUg aW5ub3ZhdGl2ZSA6KQ0KDQo+PiBJIHRoaW5rIG9uZSBwcm9ibGVtIGlzIHRoYXQgcGVvcGxlIG9m dGVuIGFyZSBzbyAiZml4YXRlZCIgaW4gZG9pbmcgDQo+PiBldmVyeXRoaW5nIGluIGEgc2luZ2xl IE8vQSB0cmFuc2FjdGlvbi4gRHVyaW5nIHRoZSBzZXNzaW9uIA0KPj4gZXN0YWJsaXNobWVudCwg aXQgZG9lc24ndCByZWFsbHkgbWF0dGVyIGlmIHlvdSBoYXZlIHRvIHNlbmQgb25lIG9yIHR3byAN Cj4+IG1vcmUgT2ZmZXJzIDopDQo+DQo+IE1heSBiZSB0aGF0IHNpIGdvb2QgZW5vdWdoIGZvciBT SVAsIGJ1dCBtYXkgYmUgbm90IGZvciBvdGhlciAoZnV0dXJlKSBSVEMgcHJvdG9jb2xzLg0KDQpJ IGRvbid0IHJlYWxseSBzZWUgd2h5IGl0IHdvdWxkIGJlIGFueSBkaWZmZXJlbnQgZm9yIFJUQyBw cm90b2NvbHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From ibc@aliax.net Mon Jul 29 10:05: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 9214511E810C for ; Mon, 29 Jul 2013 10:05:49 -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.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 cdh+itPCCj6X for ; Mon, 29 Jul 2013 10:05:42 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1418E21F842A for ; Mon, 29 Jul 2013 10:01:24 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id bv4so1810579qab.20 for ; Mon, 29 Jul 2013 10:01:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=TEOLQy8gj8DHTzvZq1l26eIb2m4SEzkRBHmFmljFPHM=; b=Wt671QjX/L/yokEkwKAaQU/15Vdt91RvEr9GwpzhDHt2+xngG1KyAf/zF7dLzRtAWA C8hKaxKqrZNt2Bh4YOhS2Oe9v0RqNxYg4WfdWLxoWwTEUTkhgpWTekdw8ZPdN+T4Mcm6 J2LMTcpofJz27gp5jqvB+nKUufxmwE5/s54Xjvy3mY8r8FHfwv/qDKSwva7PRK9owCco YrHckoWgtes8/FhUzcPXhNi9GKJD267UVvASRFfn3trvbBWZqiV0uyq97McqQ4ohrIzV +DXzQX1gCvx3khNhDdPdgweoYtQX7laHleIWivZKGbnPlBIoWnOv/MFL9pHACX70vHog lIRA== X-Received: by 10.224.28.137 with SMTP id m9mr13394539qac.22.1375117283683; Mon, 29 Jul 2013 10:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:01:03 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> References: <51EFFC49.80305@jitsi.org> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 19:01:03 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl/Dt633NhacdE2V9WkFojwDCCEF1vL/vKY25zaFRVc/P6ZqnZHIn015PH9N7J9hViuZgE6 Cc: MMUSIC IETF WG Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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: Mon, 29 Jul 2013 17:05:54 -0000 2013/7/29 Christer Holmberg : >>> The browser can, in the first Offer, only include 1+1 m- lines. Then, >>> the server can inform the browser about the number of participants, >> >> Via custom signaling, right? so we have a media session signaling mandat= e (SDP O/A) which is not suitable for properly negotiating my very basic sc= enario. > > SDP O/A is used to negotiate the media channels - not to exchange generic= capabilities (e.g. number of participants in the conference). I was thinking in the "standard video conference server" (purchased by so many web providers) Cullen was talking about in other mail thread. Anyhow I don't know why the browser must know the exact number of participants in a conference before making its SDP offer and calling to the conference server. It just does not make sense. Nobody will comment it? - I'm Alice calling to the conference server. This is my audio and video track (2 m lines). - OK Alice, I'm the server. Take those 8 audio tracks and 3 video tracks from other participants already in the conference (so 11 m lines). Why something like this is not possible with SDP? Well, because SDP was designed assuming bidirectional tracks (single telephony audio track in which obviously both sides talk) and thus SDP is not good for WebRTC in which we expect servers providing many tracks to clients. --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Mon Jul 29 22:53: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 750BE11E81BE for ; Mon, 29 Jul 2013 22:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 451pnUuQ7ZFZ for ; Mon, 29 Jul 2013 22:53:47 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9892411E81B7 for ; Mon, 29 Jul 2013 22:53:47 -0700 (PDT) Received: from BLU169-W61 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 22:53:47 -0700 X-TMN: [Edf+UPz1Fg2/KtSE2ChCvemOXwxwREAs] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1cc26d09-89cb-431e-89ee-2bb48caceae8_" From: Bernard Aboba To: =?iso-8859-1?B?SfFha2kgQmF6IENhc3RpbGxv?= , "mmusic@ietf.org" Date: Mon, 29 Jul 2013 22:53:46 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2013 05:53:47.0550 (UTC) FILETIME=[288693E0:01CE8CE9] Subject: Re: [MMUSIC] SDP for conferencing scenario? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 05:53:53 -0000 --_1cc26d09-89cb-431e-89ee-2bb48caceae8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > - Web application with a SIP over WebSocket client running in the web. >=20 > - The web user is provided with a conference SIP URI in which there > are *already* 8 participants (5 of them emitting audio and video and 3 > just emitting audio). >=20 > - The user calls=2C from his webphone=2C to the given URI to join the con= ference. >=20 > Let's imagine that the JS app knows the number of participant in the conf= erence. > Let's imagine my browser have mic and webcam. >=20 > QUESTION: >=20 > How can my browser join the conference without requiring SDP > renegotiation from the server and=2C at the same time=2C being able to > send audio/video and receive audio/video from others (different tracks > / m=3Dlines)? I=F1aki -- =20 Is the term "conference" used here in the same way as in RFC 4353/4575/5239= ? Or are you envisaging a set of peer-to-peer conversations? =20 = --_1cc26d09-89cb-431e-89ee-2bb48caceae8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B - Web application wit= h a SIP over WebSocket client running in the web.
>=3B
>=3B - Th= e web user is provided with a conference SIP URI in which there
>=3B a= re *already* 8 participants (5 of them emitting audio and video and 3
&g= t=3B just emitting audio).
>=3B
>=3B - The user calls=2C from hi= s webphone=2C to the given URI to join the conference.
>=3B
>=3B= Let's imagine that the JS app knows the number of participant in the confe= rence.
>=3B Let's imagine my browser have mic and webcam.
>=3B >=3B QUESTION:
>=3B
>=3B How can my browser join the confere= nce without requiring SDP
>=3B renegotiation from the server and=2C at= the same time=2C being able to
>=3B send audio/video and receive audi= o/video from others (different tracks
>=3B / m=3Dlines)?

I=F1ak= i --
 =3B
Is the term "conference" used here in the same way as i= n RFC 4353/4575/5239? =3B Or are you envisaging a set of peer-to-peer c= onversations? =3B
= --_1cc26d09-89cb-431e-89ee-2bb48caceae8_-- From ibc@aliax.net Tue Jul 30 00:40: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 B229111E81C9 for ; Tue, 30 Jul 2013 00:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 ExGxkO-I-9k8 for ; Tue, 30 Jul 2013 00:40:48 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id C669411E80F4 for ; Tue, 30 Jul 2013 00:40:45 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id hu14so2201871qab.12 for ; Tue, 30 Jul 2013 00:40:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dRi8eEDeVOhPnWYG+JY1CeUsIr0nlZvEGWZU6i2dWGs=; b=FvLc6+/oBHqfjDitupIaEmpMBmoRCAEKlLUx2jfAv6NJwg5ZiBJYJTXX8M4HpQC2A5 o+JLdRzrivwiXt7PV376ix+6hNMsZwk3B5Lv2lY8NlpDhdse/trmh+u1K7vAXBz0NI/5 q1IffR6uiHiyOgohUzPlVLRxnaxP52IFs23QSlT9g49dn3ky8G3vKXMsgjRLvOzIcuIe TbDszQIWBk1DmiCvwR6E2ag0NprSUfV1eeZTj4RAhC3OQT45LOT76dAyC68KtYrC6fhE 8ftpwhAxsZkR2wqmUoxG78LVBJR4t6e5ToUx5Kkp+g2eWy30nlTThv5qtm4SkPFde+jK xXbg== X-Received: by 10.224.182.79 with SMTP id cb15mr77488425qab.48.1375170044064; Tue, 30 Jul 2013 00:40:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 00:40:24 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 09:40:24 +0200 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmJYPg3+9/3pDDejKLnzIWXU8eRzxuZADPFfzHAcIbNIwKzDU82Ia4r39WtDzMBnrZMCTd4 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP for conferencing scenario? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 07:40:53 -0000 2013/7/30 Bernard Aboba : >> - Web application with a SIP over WebSocket client running in the web. >> >> - The web user is provided with a conference SIP URI in which there >> are *already* 8 participants (5 of them emitting audio and video and 3 >> just emitting audio). >> >> - The user calls, from his webphone, to the given URI to join the >> conference. >> >> Let's imagine that the JS app knows the number of participant in the >> conference. >> Let's imagine my browser have mic and webcam. >> >> QUESTION: >> >> How can my browser join the conference without requiring SDP >> renegotiation from the server and, at the same time, being able to >> send audio/video and receive audio/video from others (different tracks >> / m=3Dlines)? > > I=C3=B1aki > > Is the term "conference" used here in the same way as in RFC 4353/4575/52= 39? > Or are you envisaging a set of peer-to-peer conversations? Not exaclty. It may be but it is not required. Let's imagine I don't use SIP but any other sig protocol (but still can be SIP). I just want to call from my browser to a conference server in which there is already an active conference with N participants. I want to be able to offer my audio/video tracks and the server to accept them by also telling me its N audio/video tracks. Without SDP renegotiation. Is it possible? No, it is not, due to SDP semantics. --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Tue Jul 30 01: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 1521611E8144 for ; Tue, 30 Jul 2013 01:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 caNJlweGDmjY for ; Tue, 30 Jul 2013 01:35:25 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55011E8133 for ; Tue, 30 Jul 2013 01:33:14 -0700 (PDT) Received: from BLU169-W106 ([65.55.111.73]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 01:33:14 -0700 X-TMN: [FalpW8/cwZ9sqIq/eynXzpF1N05MvLyT] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fd6ed277-24fa-433d-ab6e-f92f8391b6e2_" From: Bernard Aboba To: =?iso-8859-1?B?SfFha2kgQmF6IENhc3RpbGxv?= Date: Tue, 30 Jul 2013 01:33:13 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2013 08:33:14.0575 (UTC) FILETIME=[6EEABDF0:01CE8CFF] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP for conferencing scenario? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 08:35:41 -0000 --_fd6ed277-24fa-433d-ab6e-f92f8391b6e2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I just want to call from my browser to a conference server in which there= is > already an active conference with N participants. I want to be able to > offer my audio/video tracks and the server to accept them by also > telling me its N audio/video tracks. Without SDP renegotiation. [BA] Putting the SDP API issues aside for the moment=2C I can imagine an = on-the-wire SDP offer/answer exchange which could address your scenario. F= or example=2C one could envisage a "Plan B"-ish approach where we have an S= DP offer with two m lines (one for audio=2C one for video) and a max-recv-s= ource attribute=2C and an answer also with two m-lines. In a "mixer" topol= ogy where the SSRCs are known=2C a=3Dssrc attributes could be included. Fo= r an "RTP translator" topology as described in "No Plan" the SSRCs might no= t be known=2C so they couldn't be included.=20 =20 Note that even if you don't want SDP in-the-API=2C you'd still need to addr= ess the RTP issues=2C such as which RTP topologies are to be supported. S= ince interoperability among video conferencing systems is less than univers= al=2C these issues are non-trivial.=20 =20 =20 =20 =20 = --_fd6ed277-24fa-433d-ab6e-f92f8391b6e2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B I just want to call from = my browser to a conference server in which there is
>=3B already an ac= tive conference with N participants. I want to be able to
>=3B offer m= y audio/video tracks and the server to accept them by also
>=3B tellin= g me its N audio/video tracks. Without SDP renegotiation.

[BA] = =3B Putting the SDP API issues aside for the moment=2C =3B I can imagin= e an on-the-wire SDP offer/answer exchange which could address your scenari= o. =3B =3BFor example=2C one =3Bcould envisage a "Plan B"-ish&n= bsp=3Bapproach where we have an =3BSDP offer with two m lines (one for = audio=2C one for video) and a max-recv-source attribute=2C and an answer al= so with two m-lines. =3B In a "mixer" topology where the SSRCs are know= n=2C a=3Dssrc attributes could be included. =3B For an "RTP translator"= topology as described in "No Plan" the SSRCs might not be known=2C so they= couldn't be included.
 =3B
Note that even if you don't want SDP= in-the-API=2C you'd still need to address the RTP issues=2C such as which = RTP topologies are to be supported. =3B =3B Since interoperability = among video conferencing systems is less than universal=2C these issues are= non-trivial.
 =3B
 =3B
 =3B

 =3B
=
= --_fd6ed277-24fa-433d-ab6e-f92f8391b6e2_-- From harald@alvestrand.no Tue Jul 30 01:59: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 7006021F9E89 for ; Tue, 30 Jul 2013 01:59:11 -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 i3rOn-nCuaU4 for ; Tue, 30 Jul 2013 01:59:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9798021E80E4 for ; Tue, 30 Jul 2013 01:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59FB239E129 for ; Tue, 30 Jul 2013 10:57:40 +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 2iH1vnukVv86 for ; Tue, 30 Jul 2013 10:57:38 +0200 (CEST) Received: from [IPv6:2001:df8:0:16:b1e0:abc8:8c6a:54b0] (unknown [IPv6:2001:df8:0:16:b1e0:abc8:8c6a:54b0]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BFA6A39E0E1 for ; Tue, 30 Jul 2013 10:57:38 +0200 (CEST) Message-ID: <51F78002.80102@alvestrand.no> Date: Tue, 30 Jul 2013 10:57:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] [rtcweb] About unified Plan and 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 Jul 2013 08:59:14 -0000 Inaki, this is abuse of mailing lists. Raising the issue of "how do I do this with the current proposal made to MMUSIC" (aka "unified plan") is reasonable. You have been answered; there are multiple ways that are valid SDP, and it is reasonable to have a discussion on which ones to recommand, and if any of them should be recommended against. Your screed about how the fact that there's work to be done here "proves" that SDP is unsuitable for RTCWEB belongs in the WEBRTC mailing list. On 07/29/2013 07:01 PM, Iñaki Baz Castillo wrote: > 2013/7/29 Christer Holmberg : >>>> The browser can, in the first Offer, only include 1+1 m- lines. Then, >>>> the server can inform the browser about the number of participants, >>> Via custom signaling, right? so we have a media session signaling mandate (SDP O/A) which is not suitable for properly negotiating my very basic scenario. >> SDP O/A is used to negotiate the media channels - not to exchange generic capabilities (e.g. number of participants in the conference). > I was thinking in the "standard video conference server" (purchased by > so many web providers) Cullen was talking about in other mail thread. > > Anyhow I don't know why the browser must know the exact number of > participants in a conference before making its SDP offer and calling > to the conference server. It just does not make sense. Nobody will > comment it? > > > > - I'm Alice calling to the conference server. This is my audio and > video track (2 m lines). > > - OK Alice, I'm the server. Take those 8 audio tracks and 3 video > tracks from other participants already in the conference (so 11 m > lines). > > Why something like this is not possible with SDP? Well, because SDP > was designed assuming bidirectional tracks (single telephony audio > track in which obviously both sides talk) and thus SDP is not good for > WebRTC in which we expect servers providing many tracks to clients. > > > > > From ibc@aliax.net Tue Jul 30 02:32: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 5550E21F9E28 for ; Tue, 30 Jul 2013 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 cDN7aFfdtyh3 for ; Tue, 30 Jul 2013 02:32:38 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id DBC8C11E81DE for ; Tue, 30 Jul 2013 02:27:48 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id o19so2238419qap.14 for ; Tue, 30 Jul 2013 02:27:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qgtfFiX+EXJW8PgVu3csfSJoiZIpNCMxmvZdXqYIvug=; b=XhhZKLfYlZTh8M9CMo8fPmXu/jC01cgXGhSAnc+G8K0EqSSDEeBsOZsz8EvtGl2lq5 xbmYTRFYiV9L6YpuG/HrIoWRkqkjOd0vQ4HYXC9jL9QOc0vkeOUFCH5Nx0IEskMQzyIa SDi5nPv9659elM3JevXNv3Ct7RgytU04QTXkPW72ypkzKCfR7EZj5OWVM6Uaq1cdzJdH GzyLPw7FR9PseJkkGkw3nRAN5d4xaj4rGJzifa3AckM4LV2dW2Db4/FVQBPtVbqWqHfK uraHl5RsrNnawPBVsxW9HHe0uB0KLNkvjkThIU3IvBUrOkone57xBaQdj7ck5aWc3QBi 8foQ== X-Received: by 10.49.82.74 with SMTP id g10mr51430001qey.80.1375176460007; Tue, 30 Jul 2013 02:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 02:27:19 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 11:27:19 +0200 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnvjmxd72B1QZTpzArNP4g4q2vdwATFP4KWTLokFpyOqWX/Q315k6zowH/FxvrPerCG2Ne8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP for conferencing scenario? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 09:32:43 -0000 2013/7/30 Bernard Aboba : > Putting the SDP API issues aside for the moment, I can imagine an on-the= -wire SDP offer/answer exchange which could address your scenario. Of course, this is a SDP problem/limitation, a SDP problem which constrains the design of WebRTC applications. --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Tue Jul 30 04:30:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35A21F9E3F for ; Tue, 30 Jul 2013 04:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 qBoQlnLsXz-H for ; Tue, 30 Jul 2013 04:30:50 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by ietfa.amsl.com (Postfix) with ESMTP id 1479E21F9FF7 for ; Tue, 30 Jul 2013 04:30:42 -0700 (PDT) Received: from BLU169-W109 ([65.55.111.71]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 04:30:42 -0700 X-TMN: [CX4fxZ3jBtri/HNHHv2FmIyZ+p9y0pLx] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fdab3d2f-0c36-44b6-bd01-67d70156f6c4_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Tue, 30 Jul 2013 04:30:41 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2013 11:30:42.0208 (UTC) FILETIME=[39669A00:01CE8D18] Subject: [MMUSIC] Question on Section 4.7 of Unified Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:30:56 -0000 --_fdab3d2f-0c36-44b6-bd01-67d70156f6c4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a question on the SDP in Section 4.7 of Unified Plan. Looking at t= he SDP=2C I wasn't sure if this was attempting to illustrate a combination = of simulcast and layering=2C or just layering. Also=2C it wasn't clear to = me which sources corresponded to which layers. =20 m=3Dvideo 0 RTP/SAVPF 96 97 100 a=3Dmsid:ma tb a=3Dextmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 60725 b=3DAS:2500 a=3Dmid:m1 a=3Drtpmap:96 H264/90000 a=3Dfmtp:96 max-fr=3D30=3Bmax-fs=3D8040 [BA] Is this intended to be a simulcast or layered stream? If the former= =2C should it be H264-SVC?=20 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 max-fr=3D15=3Bmax-fs=3D1200 a=3Drtpmap:100 H264-SVC/90000 a=3Dfmtp:100 max-fr=3D30=3Bmax-fs=3D8040 a=3Ddepend:100 lay m1:96=2C97=3B a=3Dssrc:48970 a=3Dssrc:90898 a=3Dssrc:66997 [BA] What is the intended mapping between layers and sources?=20 a=3Dsendrecv a=3Drtcp-mux a=3Dbundle-only = --_fdab3d2f-0c36-44b6-bd01-67d70156f6c4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have =3Ba question on the = SDP in Section 4.7 of Unified Plan. =3B =3B =3BLooking at the S= DP=2C I wasn't sure if this was attempting to illustrate a combination of s= imulcast and layering=2C or just layering. =3B Also=2C it wasn't clear = to me which sources corresponded to which layers. =3B

 =3B&= nbsp=3B m=3Dvideo 0 RTP/SAVPF 96 97 100
 =3B =3B a=3Dmsid:ma tb<= br> =3B =3B a=3Dextmap:1 urn:ietf:params:rtp-hdrext:stream-correlat= or 60725
 =3B =3B b=3DAS:2500
 =3B =3B a=3Dmid:m1
=  =3B =3B a=3Drtpmap:96 H264/90000
 =3B =3B a=3Dfmtp:96 m= ax-fr=3D30=3Bmax-fs=3D8040
[BA] Is this =3Bintended to be =3Ba s= imulcast or layered stream? =3B =3BIf the former=2C should it be H2= 64-SVC?
 =3B =3B a=3Drtpmap:97 H264/90000
 =3B =3B a= =3Dfmtp:97 max-fr=3D15=3Bmax-fs=3D1200
 =3B =3B a=3Drtpmap:100 H= 264-SVC/90000
 =3B =3B a=3Dfmtp:100 max-fr=3D30=3Bmax-fs=3D8040<= br> =3B =3B a=3Ddepend:100 lay m1:96=2C97=3B
 =3B =3B a= =3Dssrc:48970
 =3B =3B a=3Dssrc:90898
 =3B =3B a=3Dss= rc:66997
[BA] =3BWhat is the intended mapping between layers and sou= rces?
 =3B =3B a=3Dsendrecv
 =3B =3B a=3Drtcp-mux =3B =3B a=3Dbundle-only

= --_fdab3d2f-0c36-44b6-bd01-67d70156f6c4_-- From richard.ejzak@alcatel-lucent.com Tue Jul 30 04:45: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 478E621F99D0; Tue, 30 Jul 2013 04:45:45 -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 Gm0fvBbDE3Z8; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 89E8B21F9E4F; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6UBjall017779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 06:45:36 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6UBjaVr018744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 07:45:36 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.98]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 07:45:36 -0400 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "dispatch@ietf.org" Thread-Topic: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels Thread-Index: AQHOjRpNvvdmZT6rGEqXeTPhf185Ug== Date: Tue, 30 Jul 2013 11:45:35 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D844196@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> <51F78002.80102@alvestrand.no> In-Reply-To: <51F78002.80102@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2013 11:45:45 -0000 QXMganVzdCBtZW50aW9uZWQgaW4gbW11c2ljLCB3ZSBhcmUgb3JnYW5pemluZyBhIGJhciBCT0Yg Zm9yIFRodXJzZGF5IGF0IDY6MzAgUE0gaW4gdGhlIE1hcmxlbmUgQmFyIHRvIGRpc2N1c3MgU0RQ IGFzcGVjdHMgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFy Y29uLW1zcnAtb3Zlci13ZWJydGMtZGF0YS1jaGFubmVscy0wMC50eHQuICBJbiBwYXJ0aWN1bGFy LCB0aGUgZHJhZnQgaW5jbHVkZXMgU0RQIHByb2NlZHVyZXMgdG8gbmVnb3RpYXRlIHRoZSB1c2Ug b2YgYW55IHN1Yi1wcm90b2NvbCAoZS5nLiwgbXNycCwgYmZjcCwgdDE0MCkgb3ZlciBEYXRhQ2hh bm5lbHMgKGZvciBzdWItcHJvdG9jb2xzIHRoYXQgbm9ybWFsbHkgdXNlIFNEUCBuZWdvdGlhdGlv biBmb3Igb3RoZXIgdHJhbnNwb3J0IG9wdGlvbnMpLiAgU29tZSBtaW5pbWFsIGFkZGl0aW9uYWwg c3ViLXByb3RvY29sIHNwZWNpZmljIHByb2NlZHVyZXMgbWlnaHQgYWxzbyBuZWVkIHRvIGJlIHNw ZWNpZmllZC4gIFRoZSBkcmFmdCBhbHNvIGluY2x1ZGVzIG1zcnAtc3BlY2lmaWMgcHJvY2VkdXJl cyBuZWVkZWQgZm9yIHRoZSB0cmFuc3BvcnQgb2YgbXNycCBvdmVyIERhdGFDaGFubmVscy4NCg0K VGhpcyBwcm9wb3NhbCBpcyBpbnRlbmRlZCB0byBjb21wbGVtZW50IHRoZSBjdXJyZW50IERhdGFD aGFubmVsIHByb2NlZHVyZXMgd2l0aG91dCByZXF1aXJpbmcgYW55IGJyb3dzZXIgc3VwcG9ydCwg d2hpY2ggaXMgd2h5IHRoaXMgd29yayBoYXMgbm90IGJlZW4gcmFpc2VkIGRpcmVjdGx5IGluIHJ0 Y3dlYi4NCg0KUGxlYXNlIGpvaW4gdXMgYXQgdGhlIE1hcmxlbmUgYmFyIG9yIGxldCBtZSBrbm93 IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBidXQgdW5hYmxlIHRvIHBhcnRpY2lwYXRlLg0KDQpUaGFu a3MsDQpSaWNoYXJkDQo= From fluffy@iii.ca Tue Jul 30 09:25: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 7751C11E80D7 for ; Tue, 30 Jul 2013 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 HYdfnWKJRXav for ; Tue, 30 Jul 2013 09:25:12 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 753CE21E8064 for ; Tue, 30 Jul 2013 09:25:09 -0700 (PDT) Received: from dhcp-10-61-98-51.cisco.com (unknown [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5F248509B8; Tue, 30 Jul 2013 12:25:08 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Tue, 30 Jul 2013 18:25:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1508) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Question on Section 4.7 of Unified Plan X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:25:19 -0000 Bernard, I think there are a few typos in this one as it got cut and = pasted around. I suspect it should be something more like below =85 On Jul 30, 2013, at 1:30 PM, Bernard Aboba = wrote: > I have a question on the SDP in Section 4.7 of Unified Plan. Looking = at the SDP, I wasn't sure if this was attempting to illustrate a = combination of simulcast and layering, or just layering. Also, it = wasn't clear to me which sources corresponded to which layers. =20 >=20 > m=3Dvideo 0 RTP/SAVPF 96 97 100 > a=3Dmsid:ma tb > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 60725 > b=3DAS:2500 > a=3Dmid:m1 > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 max-fr=3D30;max-fs=3D8040 > [BA] Is this intended to be a simulcast or layered stream? If the = former, should it be H264-SVC?=20 > a=3Drtpmap:97 H264/90000 Yes, seems to me that should be H264-SVC > a=3Dfmtp:97 max-fr=3D15;max-fs=3D1200 > a=3Drtpmap:100 H264-SVC/90000 > a=3Dfmtp:100 max-fr=3D30;max-fs=3D8040 > a=3Ddepend:100 lay m1:96,97; and I suspect the above line should be "a=3Ddepend:100 lay m1:96" > a=3Dssrc:48970 > a=3Dssrc:90898 > a=3Dssrc:66997 > [BA] What is the intended mapping between layers and sources?=20 > a=3Dsendrecv > a=3Drtcp-mux > a=3Dbundle-only >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Wed Jul 31 00:22: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 4DC9221F9E73 for ; Wed, 31 Jul 2013 00:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.235, 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 B3+q6jkoK70V for ; Wed, 31 Jul 2013 00:22:14 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4434D21F9DCA for ; Wed, 31 Jul 2013 00:22:14 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so274391wes.18 for ; Wed, 31 Jul 2013 00:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NjzoffeSlxURlFqkIaPq+zGV4vxRisFOgDloIOhfE3A=; b=baT9Fa06/Ba1TkPFVpqixf0yXKc21DbgHPHCd2tVgs8Toh8pDDSPKTD1nkvroajsOd LqGS5yssp8rOEtdxlRocjjLhWW8znHqs3U9lrtfZS+vMtaIhGJwPMnMP5QNTeXyVOvrT 5t652Xi5uet7/RE+fV5AFKaqHLsqGOidOOfbB302WQSKpL3v0wuhWF7felkFlgHle1wA laCBrKujJGtEWmDd/1I5On7Ju+n8CSMM3ALbSiURghn+Ar7xXF6E++XcfSLOo8wbppDh slJW4o9aurR1oZGrZjZxdz89LkphasLzvK4ga46s8NFHj0yVgZyFpJqkOp2GBUoRqDl/ ux4A== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr48888373wjw.5.1375255333429; Wed, 31 Jul 2013 00:22:13 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 00:22:13 -0700 (PDT) Date: Wed, 31 Jul 2013 09:22:13 +0200 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 07:22:15 -0000 http://tools.ietf.org/html/rfc5245#section-4.1.2.1 After talking to Jonathan, several things have become apparent. The prioritization calculation described in Section 4.1.2.1 of RFC 5245 is not mandatory, it's SHOULD only. This means that the guidance regarding prioritization of IPv6 over IPv4 is not applied as strictly and blindly as implied by the happy eyeballs draft. Implementations can choose a different prioritization. (I was under the misapprehension that only part of the priority was signaled, but that's clearly not the case.) That implies to me that the happy-eyeballs draft is, as best, only worth pursuing as an information addendum that provides guidance on non-stupid selection of priorities for dual-stack hosts. However, given the existence of an RFC5245bis effort, I am going to suggest that the guidance provided instead be folded into a revised Section 4.1.2.1. Another problem that can be addressed at the same time is a removal of all the normative language that surrounds this optional feature. The current 4.1.2.1 has lots of "MUST" statements that are both unnecessary and confusing. --Martin From bernard_aboba@hotmail.com Wed Jul 31 00:31: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 B19A011E80AD for ; Wed, 31 Jul 2013 00:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.237, 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 O+YXLr1Not8R for ; Wed, 31 Jul 2013 00:31:44 -0700 (PDT) Received: from blu0-omc4-s25.blu0.hotmail.com (blu0-omc4-s25.blu0.hotmail.com [65.55.111.164]) by ietfa.amsl.com (Postfix) with ESMTP id E355821F9BBD for ; Wed, 31 Jul 2013 00:31:43 -0700 (PDT) Received: from BLU169-W25 ([65.55.111.135]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Jul 2013 00:31:42 -0700 X-TMN: [soJF1S+tV0ytT9Mhuh1opOxzio1hirgj] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d3c1abc0-a21c-46e5-bba4-086d4c9efe8a_" From: Bernard Aboba To: Martin Thomson , "mmusic@ietf.org" Date: Wed, 31 Jul 2013 00:31:43 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2013 07:31:42.0956 (UTC) FILETIME=[00F422C0:01CE8DC0] Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 07:31:48 -0000 --_d3c1abc0-a21c-46e5-bba4-086d4c9efe8a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that it doesn't make sense to pursue the happy-eyeballs draft and t= hat folding fixes into RFC 5245bis is the best approach.=20 =20 A number of ICE implementations do not follow the priority guidance in RFC = 5245 Section 4.1.2.1 because it doesn't work=2C and also because guidelines= such as DoD 2008 UCR Change 3 require that implementations be able to prio= ritize IPv4 over IPv6. So in practice=2C the advice in RFC 5245 Section 4= .1.2.1 has long been overtaken by events.=20 =20 > http://tools.ietf.org/html/rfc5245#section-4.1.2.1 >=20 > After talking to Jonathan=2C several things have become apparent. >=20 > The prioritization calculation described in Section 4.1.2.1 of RFC > 5245 is not mandatory=2C it's SHOULD only. This means that the guidance > regarding prioritization of IPv6 over IPv4 is not applied as strictly > and blindly as implied by the happy eyeballs draft. Implementations > can choose a different prioritization. (I was under the > misapprehension that only part of the priority was signaled=2C but > that's clearly not the case.) >=20 > That implies to me that the happy-eyeballs draft is=2C as best=2C only > worth pursuing as an information addendum that provides guidance on > non-stupid selection of priorities for dual-stack hosts. >=20 > However=2C given the existence of an RFC5245bis effort=2C I am going to > suggest that the guidance provided instead be folded into a revised > Section 4.1.2.1. >=20 > Another problem that can be addressed at the same time is a removal of > all the normative language that surrounds this optional feature. The > current 4.1.2.1 has lots of "MUST" statements that are both > unnecessary and confusing. >=20 > --Martin > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --_d3c1abc0-a21c-46e5-bba4-086d4c9efe8a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree that it doesn't make sen= se to pursue the happy-eyeballs draft and that folding fixes into RFC 5245b= is is the best approach. =3B
 =3B
A number of ICE implementat= ions =3Bdo not follow the =3Bpriority guidance in RFC =3B5245 S= ection 4.1.2.1 because it doesn't =3Bwork=2C and also because guideline= s such as DoD 2008 UCR Change 3 require that implementations be able to pri= oritize IPv4 over IPv6. =3B =3B So in practice=2C the advice in RFC= 5245 Section 4.1.2.1 has =3Blong been overtaken by events.
 = =3B
>=3B http://tools.ietf.org/html/rfc5245#section-4.1.2.1
&g= t=3B
>=3B After talking to Jonathan=2C several things have become app= arent.
>=3B
>=3B The prioritization calculation described in Sec= tion 4.1.2.1 of RFC
>=3B 5245 is not mandatory=2C it's SHOULD only. T= his means that the guidance
>=3B regarding prioritization of IPv6 over= IPv4 is not applied as strictly
>=3B and blindly as implied by the ha= ppy eyeballs draft. Implementations
>=3B can choose a different prior= itization. (I was under the
>=3B misapprehension that only part of th= e priority was signaled=2C but
>=3B that's clearly not the case.)
&= gt=3B
>=3B That implies to me that the happy-eyeballs draft is=2C as = best=2C only
>=3B worth pursuing as an information addendum that provi= des guidance on
>=3B non-stupid selection of priorities for dual-stack= hosts.
>=3B
>=3B However=2C given the existence of an RFC5245bi= s effort=2C I am going to
>=3B suggest that the guidance provided inst= ead be folded into a revised
>=3B Section 4.1.2.1.
>=3B
>= =3B Another problem that can be addressed at the same time is a removal of<= br>>=3B all the normative language that surrounds this optional feature. = The
>=3B current 4.1.2.1 has lots of "MUST" statements that are both<= br>>=3B unnecessary and confusing.
>=3B
>=3B --Martin
>= =3B _______________________________________________
>=3B mmusic mailin= g list
>=3B mmusic@ietf.org
>=3B https://www.ietf.org/mailman/lis= tinfo/mmusic
= --_d3c1abc0-a21c-46e5-bba4-086d4c9efe8a_-- From ari.keranen@ericsson.com Wed Jul 31 02: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 4CA7421F893E for ; Wed, 31 Jul 2013 02:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.365, 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 r3fM66IAzjM9 for ; Wed, 31 Jul 2013 02:23:24 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A521F999E for ; Wed, 31 Jul 2013 02:19:50 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-af-51f8d6b515c9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.35.11907.5B6D8F15; Wed, 31 Jul 2013 11:19:50 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Wed, 31 Jul 2013 11:19: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 934F011043A; Wed, 31 Jul 2013 12:19:49 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1AA72551B9; Wed, 31 Jul 2013 12:19:45 +0300 (EEST) Received: from dhcp-64f5.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9E5EF546E3; Wed, 31 Jul 2013 12:19:44 +0300 (EEST) Message-ID: <51F8D6B6.6080109@ericsson.com> Date: Wed, 31 Jul 2013 11:19:50 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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 X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre62az8CDY5/YrLYv+Qys8W1M/8Y LaYuf8xicWL3NkYHFo8pvzeyeuycdZfd43HPGTaPJUt+MgWwRHHZpKTmZJalFunbJXBlzL97 irFgskjF9l1nmRoYWwS6GDk5JARMJLb/uskGYYtJXLi3Hsjm4hASOMoo8ezvE1YIZwOjxOKW bhYIZy+jxPojh6Ay6xgl/k3ZheDs/fiQuYuRg4NXQFtiwVcLkLksAqoSjS/nMYPYbAL2Ejcn XGcHKREVSJZ4ecQIJMwrIChxcuYTFhBbREBd4uveHmaQkcwCExglnrw8CJYQFgiQWPJ6A5gt JFAnsWLuKrCZnAJWEvNvTQf7gVnAVuLCnOssELa8xPa3c5ghflOTuHpuEzNEr6rE1X+vGCcw is5CsnsWkvZZSNoXMDKvYuQoTi1Oyk03MtjECIyRg1t+W+xgvPzX5hCjNAeLkjjvFr0zgUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYA8VTN7gt5Q72mrN1c3l6+BHRb49PV4m+Wvf1c5H3 od2nA25f3Kl0Ujjt6pWy3g0bWtsOPZy3dQ1fVVjsA46uhQzpn498uqz32WIrMw+ngPWV7icG GrEJ7ufP8sR4yVY2P3Kf9EjiZNCs2cJP5JUm+394ny3BxWjxaSn3Gv9yVqddwlwMjikdSizF GYmGWsxFxYkAk0vsR18CAAA= Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 09:23:41 -0000 Hi, If we can do this as updated recommendations on how to prioritize the candidates, then I think it makes a lot of sense to integrate this into 5245bis. If it gets much more complicated than this, probably separate document makes more sense. Tiru mentioned that simply tweaking the priorities may not work in all cases, so perhaps we should have a look at those cases and see if we can make them work. Cheers, Ari (as individual) On 7/31/13 9:31 AM, Bernard Aboba wrote: > I agree that it doesn't make sense to pursue the happy-eyeballs draft > and that folding fixes into RFC 5245bis is the best approach. > > A number of ICE implementations do not follow the priority guidance in > RFC 5245 Section 4.1.2.1 because it doesn't work, and also because > guidelines such as DoD 2008 UCR Change 3 require that implementations be > able to prioritize IPv4 over IPv6. So in practice, the advice in RFC > 5245 Section 4.1.2.1 has long been overtaken by events. > > > http://tools.ietf.org/html/rfc5245#section-4.1.2.1 > > > > After talking to Jonathan, several things have become apparent. > > > > The prioritization calculation described in Section 4.1.2.1 of RFC > > 5245 is not mandatory, it's SHOULD only. This means that the guidance > > regarding prioritization of IPv6 over IPv4 is not applied as strictly > > and blindly as implied by the happy eyeballs draft. Implementations > > can choose a different prioritization. (I was under the > > misapprehension that only part of the priority was signaled, but > > that's clearly not the case.) > > > > That implies to me that the happy-eyeballs draft is, as best, only > > worth pursuing as an information addendum that provides guidance on > > non-stupid selection of priorities for dual-stack hosts. > > > > However, given the existence of an RFC5245bis effort, I am going to > > suggest that the guidance provided instead be folded into a revised > > Section 4.1.2.1. > > > > Another problem that can be addressed at the same time is a removal of > > all the normative language that surrounds this optional feature. The > > current 4.1.2.1 has lots of "MUST" statements that are both > > unnecessary and confusing. > > > > --Martin > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Wed Jul 31 02:25: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 8541821F96DA for ; Wed, 31 Jul 2013 02:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dS3hljSbktuN for ; Wed, 31 Jul 2013 02:25:46 -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 34A2521F9984 for ; Wed, 31 Jul 2013 02:25:24 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so3111203wiw.2 for ; Wed, 31 Jul 2013 02:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=21u6hohFoCarHAqx0G9PC4fMbu4WTdRSVEPFcqoePrc=; b=LXd/b1cTV3+rvinGpK/uHodGds7kKJnpX9y6StlVckFTBaiZXWygwrWCt19QZ6Yx8d Hl2z8qClyDvXvrLU5OTfuiBHQLbifp1aU4qdPqdYwZArlRkBeD/OtyejqrXHq1EEjjwi XidfFYJhlCL0uqCbRZZHd7v72SNduCFbVQFUvm4ev5myjI6s1f4whde8MW9xwbL6nP8X EmAOU5Cj5eR+UiNpF/2jE0gk2IfH9H+qrxAxl3Idqmmy8xw55/f2Bj7CYTO+/T1HDH7g +PwqbbcBmkJ2cTMyRJGHMd2a9zcRpfWXkqhbFVGxHKADBb3+10E1sOmG4Ul04OyP0vVv RfOA== MIME-Version: 1.0 X-Received: by 10.180.83.163 with SMTP id r3mr3674926wiy.10.1375262723059; Wed, 31 Jul 2013 02:25:23 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 02:25:22 -0700 (PDT) In-Reply-To: <51F8D6B6.6080109@ericsson.com> References: <51F8D6B6.6080109@ericsson.com> Date: Wed, 31 Jul 2013 11:25:22 +0200 Message-ID: From: Martin Thomson To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 09:25:47 -0000 On 31 July 2013 11:19, Ari Ker=C3=A4nen wrote: > Tiru mentioned that simply tweaking the priorities may not work in all > cases, so perhaps we should have a look at those cases and see if we can > make them work. I don't believe that to be a problem. Obviously, unless both peers are doing the same sort of prioritization, you can get some silly results, but that's always going to be a hazard. I don't believe that we need any additional recommendations. From dwing@cisco.com Wed Jul 31 04: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 98D4011E80FA for ; Wed, 31 Jul 2013 04:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQoVN3zsKJDa for ; Wed, 31 Jul 2013 04:19:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE6421E8122 for ; Wed, 31 Jul 2013 04:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1467; q=dns/txt; s=iport; t=1375269570; x=1376479170; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=poOKvdqBiGgMn1TVDq/AUALo+5qUrjqXZjofEpfvbbI=; b=RFR6IJ2rER/3rRbykXxmyK1PqkGmqWXZ//qZyytPePH3T/LCCYSfHV1m MJXtJRsPvalL1AQWty2b2TqmgTN+Xv6sYY6wdLA+ZGtbPw7SieheGMyAy 82QisrNxXydBV9DJ5YT7We/8zCLleNhNHCWpyfJDGBjLLUZ74W6V7bKiK 0=; X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="scan'208";a="87989909" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 31 Jul 2013 11:19:29 +0000 Received: from sjc-vpn5-704.cisco.com (sjc-vpn5-704.cisco.com [10.21.90.192]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6VBJRsd022108; Wed, 31 Jul 2013 11:19:27 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 31 Jul 2013 13:19:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> References: <51F8D6B6.6080109@ericsson.com> To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic@ietf.org, "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 11:19:42 -0000 On Jul 31, 2013, at 11:25 AM, Martin Thomson = wrote: > On 31 July 2013 11:19, Ari Ker=E4nen wrote: >> Tiru mentioned that simply tweaking the priorities may not work in = all >> cases, so perhaps we should have a look at those cases and see if we = can >> make them work. >=20 > I don't believe that to be a problem. Obviously, unless both peers > are doing the same sort of prioritization, you can get some silly > results, but that's always going to be a hazard. >=20 > I don't believe that we need any additional recommendations. I agree the happy eyeballs recommendation (or, "non-stupid selection of = priorities for dual-stack hosts") would best be folded into RFC5245bis. However, about a year ago Jonathan Lennox had expressed some concern = that if the two peers have different ordering, their suicide packets = (necessary to create mappings in their own respective NATs) would have = to suffer an additional retry. I guess that is okay, and why you said = it isn't a problem. I'm fine with that, if that's what you meant. ICE = has its SHOULD for the ordering and chooses one end to be authoritative = for the ordering to avoid the problem of each peer using a different = order. If we're confident that guidance in ICE is over-stated and = unnecessary, that certainly makes things easier that the two ICE peers = can choose their own ordering willy-nilly. -d From jonathan@vidyo.com Wed Jul 31 04:51: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 BEBEC21E8114 for ; Wed, 31 Jul 2013 04:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 mvka73dLY-0i for ; Wed, 31 Jul 2013 04:51:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1158321F9EFB for ; Wed, 31 Jul 2013 04:51:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9090B41682F for ; Wed, 31 Jul 2013 07:51:01 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 30E2D416978 for ; Wed, 31 Jul 2013 07:51:01 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 31 Jul 2013 07:48:57 -0400 From: Jonathan Lennox To: "mmusic@ietf.org" Date: Wed, 31 Jul 2013 07:51:03 -0400 Thread-Topic: Proposed definition for "same codec configuration" Thread-Index: Ac6N5BtcLuepx57dSJqfmGKWfgpL+w== Message-ID: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 11:51:18 -0000 As I mentioned at the mic today, my straw-man proposed definition for "same= codec configuration" is: Two codec configurations are the same if the PT has the same value for the = "rtpmap" and "fmtp" SDP parameters. Known issues with this definition: Some codecs (notably H.264's sprop-* parameters, and all of Opus's paramete= rs) have fmtp parameters describe behavior of a sender, or else are non-nor= mative indications about the modes that would be most useful but aren't act= ually necessary to configure a decoder. So it's overly restrictive to insi= st that fmtp be identical between all the lines. Getting this to work would, I think, require analysis in the style of draft= -nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every cod= ec anyone cares about. The other issue is whether there are other SDP parameters (presumably ones = that are specified in terms of PT) that also need to be considered to be pa= rt of the "codec configuration" and needs to be aligned. Imageattr was pro= posed as one possibility. -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Wed Jul 31 04:51:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3721E8136 for ; Wed, 31 Jul 2013 04:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.218, 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 rsZRIkbKP0Az for ; Wed, 31 Jul 2013 04:51:37 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E486721E8139 for ; Wed, 31 Jul 2013 04:51:24 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so505504wes.18 for ; Wed, 31 Jul 2013 04:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BPn5lpqcQfjk4UafN9/WQOrpkWseAwg/x8ndAPuL4dQ=; b=Cn65WQNGPa8ZIhJOdleIqyrSmhrsAOtv5QFC8F8weP6nejAd6EaT8wUi3dF68nfNbt MKMcBr94v0zUxlzp+4Ulesv1dzcb1HxRLoVoN2dEN/HPng27yzL0Rw6LoERETqxbvY8I Mn5v/o7M8MMviN1GM9qB9luKpRcMDqlYu2iXtPPk7uvkC+TUc+8WinuXLYzocpzaoCeU Ft5JgMGjFjeeowyBMZHU7DcJu+ko4mE7KAeO9V74ZB9om+Bh9e2alFABod1YVAeJBiuS 8d9UgJmZWhyDuhrcYkYPWShVDa/HIBfTzroQ+OU0oO4wazzMkOMPjkZv6DbFphwufRSX LhaA== MIME-Version: 1.0 X-Received: by 10.180.73.68 with SMTP id j4mr4063670wiv.10.1375271483947; Wed, 31 Jul 2013 04:51:23 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 04:51:23 -0700 (PDT) In-Reply-To: <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> Date: Wed, 31 Jul 2013 13:51:23 +0200 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 11:51:39 -0000 On 31 July 2013 13:19, Dan Wing wrote: > I agree the happy eyeballs recommendation (or, "non-stupid selection of p= riorities for dual-stack hosts") would best be folded into RFC5245bis. Great. > However, about a year ago Jonathan Lennox had expressed some concern that= if the two peers have different ordering, their suicide packets (necessary= to create mappings in their own respective NATs) would have to suffer an a= dditional retry. I guess that is okay, and why you said it isn't a problem= . I'm fine with that, if that's what you meant. ICE has its SHOULD for th= e ordering and chooses one end to be authoritative for the ordering to avoi= d the problem of each peer using a different order. If we're confident tha= t guidance in ICE is over-stated and unnecessary, that certainly makes thin= gs easier that the two ICE peers can choose their own ordering willy-nilly. I don't believe that, except for the pathological case where there is a collision in priority values, this results in peers generating a different priority order for candidate pairs. Even in those pathological cases, the difference in times that arises from this (i.e., the 20ms pacing timer) is probably still *significantly* smaller than the delay that arises from the fact that the signaling information is complete at the answerer well before the signaling arrives at the offerer. From martin.thomson@gmail.com Wed Jul 31 05:02: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 501EE21F85C9 for ; Wed, 31 Jul 2013 05:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.207, 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 pkXxXIXXPfa6 for ; Wed, 31 Jul 2013 05:02:23 -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 96A7421F9BC1 for ; Wed, 31 Jul 2013 05:01:33 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so3796627wib.4 for ; Wed, 31 Jul 2013 05:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H0xv8Z9safirB44EAi5BP1e1VxEIphSCLpBE5A0sCmM=; b=LzPw08JJjWeeYI9BD3iR4uEWHmtCRI8736LnAgfxmQaTmsGfi7N3t29TevDY57r1sc b3G9Hykg9F933K+FH8iLL6eIeMPi1kWLN+ipDozJpJj2JYQrCyr3Th7js4zjcxOZMcmo Mn3IyuK9A/0YEZm9htLu+fCE6M0NprUB2UNItHQpd8FP0aQMTto9SHQuHz2V7Gvb1ofv ZGdfLrkf2mSV1TeQdPuDZYrqSyL0nVHWK8/Gam3jE3ETbsq/4hSbuqhzGQ2G0rLL4B2t byf8sbkgcBLihSt5g9XuSLtrYbZ/yEoYgh6aEKUDDRNM7+rKfLYa4TA1Vg/DHBQ84fwz tMXg== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr49668486wjw.5.1375272089635; Wed, 31 Jul 2013 05:01:29 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 05:01:29 -0700 (PDT) In-Reply-To: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> References: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> Date: Wed, 31 Jul 2013 14:01:29 +0200 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:02:34 -0000 On 31 July 2013 13:51, Jonathan Lennox wrote: > As I mentioned at the mic today, my straw-man proposed definition for "sa= me codec configuration" is: > > Two codec configurations are the same if the PT has the same value for th= e "rtpmap" and "fmtp" SDP parameters. This needs to also include the major type that is included in the m=3D line (i.e., "audio" or "video"). > Known issues with this definition: > > Some codecs (notably H.264's sprop-* parameters, and all of Opus's parame= ters) have fmtp parameters describe behavior of a sender, or else are non-n= ormative indications about the modes that would be most useful but aren't a= ctually necessary to configure a decoder. So it's overly restrictive to in= sist that fmtp be identical between all the lines. I don't believe that the utility provided by allowing the fmtp to be split in this way outweighs the costs. It's far simpler if this is just defined as above. > Getting this to work would, I think, require analysis in the style of dra= ft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every c= odec anyone cares about. Exactly. Let's not do that work. Just doing the work would be hard. Gaining consensus on it might also cause it to take some significant amount of time. If it's super-important, the rfc-to-be for bundle can be updated. > The other issue is whether there are other SDP parameters (presumably one= s that are specified in terms of PT) that also need to be considered to be = part of the "codec configuration" and needs to be aligned. Imageattr was p= roposed as one possibility. I don't believe imageattr to be relevant in this case. If it were relevant, it would only be because the codec in question didn't signal resolution in-band, but in that case, fmtp line should contain the resolution in that case. From martin.thomson@gmail.com Wed Jul 31 05:16: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 920FE21F9CAE for ; Wed, 31 Jul 2013 05:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_18=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 8-nRUx3Uvu9n for ; Wed, 31 Jul 2013 05:16:41 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E769621F841E for ; Wed, 31 Jul 2013 05:16:40 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so522661wgh.19 for ; Wed, 31 Jul 2013 05:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BrWQuSqasZyw+bpynNFiewkldpTbJAYfF8Hmy3ZQyIo=; b=rteaGxBw6PjgLBizAUS2+VwTzNslnP9gtdSIKwC94sE3J8nmdsLu49O+LnThvAHYKT gwszNQuauHkA0EyqN/tawerBxo7+PRLC49p7cJeyKmi5LcMcUL/D1EMsQkeuABdpPTHs uXHip4c7lAQPwJ6et50ZcAJCXj1trKGpOMKP8Vkha+Wp3pciuQGVyY+Ab7vLCAJGp5/x xYE/UylCPDyReIERDmoqi/T/0Ian6OATLzY6KyFCgdSBQRf9FHFrhvrwRRl1S0wgHSiI ooGcyUKps0gQ3PyO4GocWFIaxjphFNBowrrcXp5xnChLRg1aQs+5IhTUrHOWoIV7hySs n/Uw== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr2037637wic.65.1375272999950; Wed, 31 Jul 2013 05:16:39 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 05:16:39 -0700 (PDT) Date: Wed, 31 Jul 2013 14:16:39 +0200 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:16:41 -0000 The draft currently doesn't say much about how the glareless negotiation features relate to a=sendrecv/sendonly/etc... I think that using recvonly and sendonly could reduce the probability of encountering glare. It's a detail. And obviously, there are tradeoffs here. By choosing to use sendonly in an offer, you foreclose the ability of the answerer to use that m-line for their streams. So you would need to generate extra recvonly m-lines in order to enable the 1-RTT negotiation. There may be other implications that then stem from using extra m-lines, especially in legacy interop cases, e.g. where BUNDLE negotiation fails, or you can't access SSRCs etc..., each of which have various negative consequences. I think that the only guidance needed is something like: "Implementations MAY choose to exclusively use m-lines with a=sendonly or a=recvonly in order to further reduce the probably of encountering glare." From jonathan@vidyo.com Wed Jul 31 05:36: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 8D36D21F9D0D for ; Wed, 31 Jul 2013 05:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 ZX5RyJo5W97i for ; Wed, 31 Jul 2013 05:36:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3121F9D11 for ; Wed, 31 Jul 2013 05:33:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 639C07ABADF for ; Wed, 31 Jul 2013 08:28:20 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1B4AF7ABB58 for ; Wed, 31 Jul 2013 08:28:20 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 31 Jul 2013 08:31:33 -0400 From: Jonathan Lennox To: Martin Thomson Date: Wed, 31 Jul 2013 08:33:40 -0400 Thread-Topic: [MMUSIC] Proposed definition for "same codec configuration" Thread-Index: Ac6N6g7aC6uF8WguRWeKTWrNXbSqpQ== Message-ID: References: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:36:48 -0000 On Jul 31, 2013, at 2:01 PM, Martin Thomson wrot= e: > On 31 July 2013 13:51, Jonathan Lennox wrote: >> As I mentioned at the mic today, my straw-man proposed definition for "s= ame codec configuration" is: >>=20 >> Two codec configurations are the same if the PT has the same value for t= he "rtpmap" and "fmtp" SDP parameters. >=20 > This needs to also include the major type that is included in the m=3D > line (i.e., "audio" or "video"). Right. >> Known issues with this definition: >>=20 >> Some codecs (notably H.264's sprop-* parameters, and all of Opus's param= eters) have fmtp parameters describe behavior of a sender, or else are non-= normative indications about the modes that would be most useful but aren't = actually necessary to configure a decoder. So it's overly restrictive to i= nsist that fmtp be identical between all the lines. >=20 > I don't believe that the utility provided by allowing the fmtp to be > split in this way outweighs the costs. It's far simpler if this is > just defined as above. >=20 >> Getting this to work would, I think, require analysis in the style of dr= aft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every = codec anyone cares about. >=20 > Exactly. Let's not do that work. Just doing the work would be hard. > Gaining consensus on it might also cause it to take some significant > amount of time. If it's super-important, the rfc-to-be for bundle can > be updated. I'm inclined to agree, unless someone wants to do the work. (I don't want = to do the work.) But then, I didn't want to do the work for BUNDLE either,= and people decided it was important enough that they went ahead and did it= . >> The other issue is whether there are other SDP parameters (presumably on= es that are specified in terms of PT) that also need to be considered to be= part of the "codec configuration" and needs to be aligned. Imageattr was = proposed as one possibility. >=20 > I don't believe imageattr to be relevant in this case. If it were > relevant, it would only be because the codec in question didn't signal > resolution in-band, but in that case, fmtp line should contain the > resolution in that case. I'm inclined to agree here too. To a large extent, this overlaps with the work being done in draft-nandakum= ar-mmusic-sdp-mux-attributes. It really doesn't matter if we say that para= meters have to align per PT because "codec configuration" says so, or wheth= er parameters have to align per PT because the mux-attributes draft says so= . -- Jonathan Lennox jonathan@vidyo.com From dwing@cisco.com Wed Jul 31 05:39: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 2D30A21F9B81 for ; Wed, 31 Jul 2013 05:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.579 X-Spam-Level: X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 WE64QccDrNl9 for ; Wed, 31 Jul 2013 05:39:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A3F5C11E8178 for ; Wed, 31 Jul 2013 05:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1375274239; x=1376483839; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TF8IMOjYedeMpGgyYCsPTwP1XZwmzBZshFpyHXpan74=; b=lOB9Bae0MIImor3D/Yo+xOoLSzYK8R5WQH015iZkBoRwPHVTZcToxLrj Epnfl9fpiANaNyW7F1+NvRUfTEwnRCWahtzfSaSx+kj97L/fsuqz4Nb7X hom0b2nkEYO1BujS9a/BJyb+/6vVwtJdNAQcvu2lPBKwLfug7/jiJxCwX E=; X-IronPort-AV: E=Sophos;i="4.89,787,1367971200"; d="scan'208";a="88060405" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Jul 2013 12:37:17 +0000 Received: from sjc-vpn5-704.cisco.com (sjc-vpn5-704.cisco.com [10.21.90.192]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VCbFWw008192; Wed, 31 Jul 2013 12:37:16 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 31 Jul 2013 14:37:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:39:20 -0000 On Jul 31, 2013, at 1:51 PM, Martin Thomson = wrote: > On 31 July 2013 13:19, Dan Wing wrote: >> I agree the happy eyeballs recommendation (or, "non-stupid selection = of priorities for dual-stack hosts") would best be folded into = RFC5245bis. >=20 > Great. >=20 >> However, about a year ago Jonathan Lennox had expressed some concern = that if the two peers have different ordering, their suicide packets = (necessary to create mappings in their own respective NATs) would have = to suffer an additional retry. I guess that is okay, and why you said = it isn't a problem. I'm fine with that, if that's what you meant. ICE = has its SHOULD for the ordering and chooses one end to be authoritative = for the ordering to avoid the problem of each peer using a different = order. If we're confident that guidance in ICE is over-stated and = unnecessary, that certainly makes things easier that the two ICE peers = can choose their own ordering willy-nilly. >=20 > I don't believe that, except for the pathological case where there is > a collision in priority values, this results in peers generating a > different priority order for candidate pairs. Even in those > pathological cases, the difference in times that arises from this > (i.e., the 20ms pacing timer) is probably still *significantly* > smaller than the delay that arises from the fact that the signaling > information is complete at the answerer well before the signaling > arrives at the offerer. I agree, but I would like a careful analysis before we declare = ICE-CONTROLLED/ICE-CONTROLLING was an over-design of ICE, which is what = we're saying if both peers are allowed to choose their own priority = order. And whatever the result of that analysis it should become part = of rfc5245bis. -d From jonathan@vidyo.com Wed Jul 31 05:44: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 23D1021F9F1C for ; Wed, 31 Jul 2013 05:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 3OpP8u4kZmhB for ; Wed, 31 Jul 2013 05:44:09 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6107E21F9EFE for ; Wed, 31 Jul 2013 05:44:08 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0AE27552F7B; Wed, 31 Jul 2013 08:42:13 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8EF35552E4F; Wed, 31 Jul 2013 08:42:12 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 31 Jul 2013 08:41:58 -0400 From: Jonathan Lennox To: Dan Wing Date: Wed, 31 Jul 2013 08:44:05 -0400 Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: Ac6N64OuWazxnEpNSPKh0CV35weWyQ== Message-ID: References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> In-Reply-To: <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:44:15 -0000 On Jul 31, 2013, at 1:19 PM, Dan Wing wrote: > I agree the happy eyeballs recommendation (or, "non-stupid selection of p= riorities for dual-stack hosts") would best be folded into RFC5245bis. >=20 > However, about a year ago Jonathan Lennox had expressed some concern that= if the two peers have different ordering, their suicide packets (necessary= to create mappings in their own respective NATs) would have to suffer an a= dditional retry. I guess that is okay, and why you said it isn't a problem= . I'm fine with that, if that's what you meant. ICE has its SHOULD for th= e ordering and chooses one end to be authoritative for the ordering to avoi= d the problem of each peer using a different order. If we're confident tha= t guidance in ICE is over-stated and unnecessary, that certainly makes thin= gs easier that the two ICE peers can choose their own ordering willy-nilly. If the two peers have different ordering for their *check lists*, then yes,= you get a problem. However, if the two peers are both following the check list ordering algori= thm of section 5.7.2 of RFC 5245 -- based on the signaled candidate priorit= ies -- I think it doesn't matter whether they're both using the section 4.1= .2.1 algorithm to calculate their *candidate* priorities. This is confusing because section 4.1.2 claims there *will* be a problem. = I can't figure out why this would be true, though. I'm inclined to suspect= this is a mistake in RFC 5245. -- Jonathan Lennox jonathan@vidyo.com From dwing@cisco.com Wed Jul 31 05:56: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 D8F5F21F979E for ; Wed, 31 Jul 2013 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 AxQqsjjmv+5W for ; Wed, 31 Jul 2013 05:55:54 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8411E8109 for ; Wed, 31 Jul 2013 05:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1653; q=dns/txt; s=iport; t=1375275348; x=1376484948; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8Wjzhs2pLYxZRrSpciGG0M1hDKBrdS2mFqfllRHL2Fs=; b=Qpkwg0iU8zM1nxsgc3Ys7hnLVvnOr/YJeuB8i8HWMVKsHUoN/Cd93Vjw h1+7nnsb9VVp/sQKYhug02b2tAYYuh5ic5TPeUEVNvJn+jBG5fXM/0Z32 wl7bRhYIHCSpT2j+7L9viW7y4y3DsTbZrwKA1OuuLSVFY6KBMU+6WAjkO U=; X-IronPort-AV: E=Sophos;i="4.89,787,1367971200"; d="scan'208";a="85489441" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 31 Jul 2013 12:55:47 +0000 Received: from sjc-vpn5-704.cisco.com (sjc-vpn5-704.cisco.com [10.21.90.192]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6VCtAE0024310; Wed, 31 Jul 2013 12:55:45 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 31 Jul 2013 14:55:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FE7966D-B74A-4559-A9FC-6F17D5C64043@cisco.com> References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1508) Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:56:08 -0000 On Jul 31, 2013, at 2:44 PM, Jonathan Lennox wrote: >=20 > On Jul 31, 2013, at 1:19 PM, Dan Wing wrote: >=20 >> I agree the happy eyeballs recommendation (or, "non-stupid selection = of priorities for dual-stack hosts") would best be folded into = RFC5245bis. >>=20 >> However, about a year ago Jonathan Lennox had expressed some concern = that if the two peers have different ordering, their suicide packets = (necessary to create mappings in their own respective NATs) would have = to suffer an additional retry. I guess that is okay, and why you said = it isn't a problem. I'm fine with that, if that's what you meant. ICE = has its SHOULD for the ordering and chooses one end to be authoritative = for the ordering to avoid the problem of each peer using a different = order. If we're confident that guidance in ICE is over-stated and = unnecessary, that certainly makes things easier that the two ICE peers = can choose their own ordering willy-nilly. >=20 > If the two peers have different ordering for their *check lists*, then = yes, you get a problem. >=20 > However, if the two peers are both following the check list ordering = algorithm of section 5.7.2 of RFC 5245 -- based on the signaled = candidate priorities -- I think it doesn't matter whether they're both = using the section 4.1.2.1 algorithm to calculate their *candidate* = priorities. >=20 > This is confusing because section 4.1.2 claims there *will* be a = problem. I can't figure out why this would be true, though. I'm = inclined to suspect this is a mistake in RFC 5245. Works for me. -d From martin.thomson@gmail.com Wed Jul 31 05:57: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 7B72921F9F7A for ; Wed, 31 Jul 2013 05:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.171, 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 hb9EMOUp3xHZ for ; Wed, 31 Jul 2013 05:57:12 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5D921F9EDF for ; Wed, 31 Jul 2013 05:56:51 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so557146wes.6 for ; Wed, 31 Jul 2013 05:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bMfzQ1ef8M+zJOBDZvHyu0caNRrX2yF/hjSNXDnnTYA=; b=kO6qIc92PN8gzGlCOPLNjU/1v3WOd8pRffBcspkxJZK3KQJATGPFTkNw2OD2f5G5bZ LjU7qTvZGIamZ2vVoGgiJ0SWfFt4b5vat+12bUtDunZ//PJEzw1U1j4NmDUoRNdYYxiC yl9R9gtCNG3v5eapIaOrBCMwulBcdt5xK5rsTZrBOpkQX2y0DMT1aL9KFut2IvnNmWAK ZY0aZH9eeUK0QyRYF+4XsI4ZcDzAI3YAIlj/rzYtqGViZP1eG56tSn4JUNrYCk+GYyBZ wYwPSqeMn+ehliyiaWwNsBObg70Nngf71cy94XyLyxkl8GBcixybWFCxV3hq+16ac9nE ppMg== MIME-Version: 1.0 X-Received: by 10.180.187.2 with SMTP id fo2mr3199695wic.65.1375275410914; Wed, 31 Jul 2013 05:56:50 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 05:56:50 -0700 (PDT) In-Reply-To: References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> Date: Wed, 31 Jul 2013 14:56:50 +0200 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 12:57:38 -0000 On 31 July 2013 14:37, Dan Wing wrote: > I agree, but I would like a careful analysis before we declare ICE-CONTRO= LLED/ICE-CONTROLLING was an over-design of ICE, which is what we're saying = if both peers are allowed to choose their own priority order. And whatever= the result of that analysis it should become part of rfc5245bis. This has absolutely no impact on ICE-CONTROLLED/ICE-CONTROLLING roles or any of the other mandatory features of ICE. In ICE, both peers select a priority order for their own candidates. Check lists are ordered based on the mandatory formula described in Section 5.7.2. http://tools.ietf.org/html/rfc5245#section-5.7.2 ICE-CONTROLLED/ICE-CONTROLLING *is* over-designed, but that's never been brought up until you mentioned it. From jonathan@vidyo.com Wed Jul 31 06:02: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 D308611E8177 for ; Wed, 31 Jul 2013 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 bP0++JvyQ1gc for ; Wed, 31 Jul 2013 06:02:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42221F9E37 for ; Wed, 31 Jul 2013 06:02:19 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 55ADA5550DB; Wed, 31 Jul 2013 09:00:24 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D96FF555072; Wed, 31 Jul 2013 09:00:23 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 31 Jul 2013 09:00:09 -0400 From: Jonathan Lennox To: Dan Wing Date: Wed, 31 Jul 2013 09:02:16 -0400 Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: Ac6N7g39Rhh4qiu0RGeR9kehzI/pPA== Message-ID: <8E885029-CF2F-45C3-9121-9DBD2918E7A6@vidyo.com> References: <51F8D6B6.6080109@ericsson.com> <2444BF42-64BC-4286-9A0C-6A9D3D019D05@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:02:49 -0000 On Jul 31, 2013, at 2:37 PM, Dan Wing wrote: >=20 > I agree, but I would like a careful analysis before we declare ICE-CONTRO= LLED/ICE-CONTROLLING was an over-design of ICE, which is what we're saying = if both peers are allowed to choose their own priority order. And whatever= the result of that analysis it should become part of rfc5245bis. I know you sent this before my latest comment, but just to get it on the re= cord -- ICE-CONTROLLED/ICE-CONTROLLING affects the section 5.7.2 algorithm,= and so is important for the two sides to agree on a check list ordering. = It doesn't affect the section 4.1.2.1 algorithm. -- Jonathan Lennox jonathan@vidyo.com From suhasietf@gmail.com Wed Jul 31 06: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 9985B21F9ED1 for ; Wed, 31 Jul 2013 06:35:06 -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=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 vFN9Q26ZlL1g for ; Wed, 31 Jul 2013 06:35:06 -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 9B93721F9EE9 for ; Wed, 31 Jul 2013 06:35:00 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so599892wes.7 for ; Wed, 31 Jul 2013 06:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vjKFsSIBpzn8N3+BjoZgsu34foazaq37KJzIXqL0yNc=; b=H2E3B6XUEtNfzNzdh4PREJmt+wfVxfRCBzu/Hxi1eMvLlV/toxTFJ1dQrOnYqO6RgM Pl0Z52Xk42qY5UzuPStopwvs61WOmFzkWCzMy7l/CQ4DLotnCu8OEQtZ3T/C6e/VOnWV mov6+iEK7Dc79H9H+tPgbUyR5JFXFfYVFG0tF6OP3f6V4TU194typl4T+hmylE0+4ESW FsEXLj81IvSfVpyTxA1+e56xGtDqiRIWI5xtVZ3hB22b/leQW/blPi97noAds1L2my2Q hTT9Gn+FNv5JBFV7lzdvlE56WA8b9OpaVjRtOYNt/BRsdgHa9eUXNLL629Cg9d9LbKk7 vbig== MIME-Version: 1.0 X-Received: by 10.194.109.104 with SMTP id hr8mr49629159wjb.32.1375277698560; Wed, 31 Jul 2013 06:34:58 -0700 (PDT) Received: by 10.194.9.9 with HTTP; Wed, 31 Jul 2013 06:34:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 15:34:58 +0200 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bf10aeab0b91b04e2cecabc Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:35:06 -0000 --047d7bf10aeab0b91b04e2cecabc Content-Type: text/plain; charset=ISO-8859-1 I am not sure if this proposal answer this topic .. I had a similar proposal with uni-directional handling w.r.t glare ... http://tools.ietf.org/id/draft-nandakumar-rtcweb-glare-handling-00.txt Cheers ./S PS: Its been a while i read the above draft myself .. So please forgive me , if this is totally irrelevant :) On Wed, Jul 31, 2013 at 2:16 PM, Martin Thomson wrote: > The draft currently doesn't say much about how the glareless > negotiation features relate to a=sendrecv/sendonly/etc... I think > that using recvonly and sendonly could reduce the probability of > encountering glare. > > It's a detail. And obviously, there are tradeoffs here. By choosing > to use sendonly in an offer, you foreclose the ability of the answerer > to use that m-line for their streams. So you would need to generate > extra recvonly m-lines in order to enable the 1-RTT negotiation. > There may be other implications that then stem from using extra > m-lines, especially in legacy interop cases, e.g. where BUNDLE > negotiation fails, or you can't access SSRCs etc..., each of which > have various negative consequences. > > I think that the only guidance needed is something like: > "Implementations MAY choose to exclusively use m-lines with a=sendonly > or a=recvonly in order to further reduce the probably of encountering > glare." > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bf10aeab0b91b04e2cecabc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure if this proposal answer this topic .. I had a similar proposa= l with uni-directional handling w.r.t glare ...=A0


Cheers
./S
PS: Its been a while i r= ead the above draft myself .. So please forgive me , if this is totally irr= elevant :)



On Wed, Jul 31, 2013 at 2:16 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
The draft currently doesn't say much about how the glareless
negotiation features relate to a=3Dsendrecv/sendonly/etc... =A0I think
that using recvonly and sendonly could reduce the probability of
encountering glare.

It's a detail. =A0And obviously, there are tradeoffs here. =A0By choosi= ng
to use sendonly in an offer, you foreclose the ability of the answerer
to use that m-line for their streams. =A0So you would need to generate
extra recvonly m-lines in order to enable the 1-RTT negotiation.
There may be other implications that then stem from using extra
m-lines, especially in legacy interop cases, e.g. where BUNDLE
negotiation fails, or you can't access SSRCs etc..., each of which
have various negative consequences.

I think that the only guidance needed is something like:
"Implementations MAY choose to exclusively use m-lines with a=3Dsendon= ly
or a=3Drecvonly in order to further reduce the probably of encountering
glare."
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--047d7bf10aeab0b91b04e2cecabc-- From suhasietf@gmail.com Wed Jul 31 06:40: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 0F26021E8085 for ; Wed, 31 Jul 2013 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 2d+RJrlGtBCZ for ; Wed, 31 Jul 2013 06:40:18 -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 AAE5821E8083 for ; Wed, 31 Jul 2013 06:40:13 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id en1so663650wid.2 for ; Wed, 31 Jul 2013 06:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TwLyTSqcBjBruQnGlr4+CxX5EvdSZa6F9Xaz+Qr5Ovs=; b=SfB/f/v9VULsW3hrNOwToVqXSaRPl5eQFUU6hsfCctKOkHC4IcntXBq3ouMyqEdnN0 J1XXoUhZU4dwqgoFE9lAFaQrHw8DNJuIm+YisxVmyjhwYUSNAhraadTCWYg5EHLVQTfg pzB/D0nnZa+jApfOCB+GaQ+sfjN6psxpIwuHIEuKFoB6L9j3V3WWswSQPlPeLANVJKZ4 aCoShblNmaL5Cmz90QNGve8mcHXJXrSfMFa5FLXuGhzZKcGobbRhTJSdaIptLX9jdHN3 cmPivDxqGLJzydvBdDGO458//Y4JC6l91Ek1FO1hKGtN/fwWYt6365Y42+18pNtDntyz AEgw== MIME-Version: 1.0 X-Received: by 10.194.109.104 with SMTP id hr8mr49644972wjb.32.1375278012291; Wed, 31 Jul 2013 06:40:12 -0700 (PDT) Received: by 10.194.9.9 with HTTP; Wed, 31 Jul 2013 06:40:12 -0700 (PDT) In-Reply-To: References: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> Date: Wed, 31 Jul 2013 15:40:12 +0200 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bf10aea63e0db04e2cedd07 Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:40:20 -0000 --047d7bf10aea63e0db04e2cedd07 Content-Type: text/plain; charset=ISO-8859-1 Agreed !!! On Wed, Jul 31, 2013 at 2:01 PM, Martin Thomson wrote: > On 31 July 2013 13:51, Jonathan Lennox wrote: > > As I mentioned at the mic today, my straw-man proposed definition for > "same codec configuration" is: > > > > Two codec configurations are the same if the PT has the same value for > the "rtpmap" and "fmtp" SDP parameters. > > This needs to also include the major type that is included in the m= > line (i.e., "audio" or "video"). > > > > Known issues with this definition: > > > > Some codecs (notably H.264's sprop-* parameters, and all of Opus's > parameters) have fmtp parameters describe behavior of a sender, or else are > non-normative indications about the modes that would be most useful but > aren't actually necessary to configure a decoder. So it's overly > restrictive to insist that fmtp be identical between all the lines. > > I don't believe that the utility provided by allowing the fmtp to be > split in this way outweighs the costs. It's far simpler if this is > just defined as above. > > > Getting this to work would, I think, require analysis in the style of > draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of > every codec anyone cares about. > > Exactly. Let's not do that work. Just doing the work would be hard. > Gaining consensus on it might also cause it to take some significant > amount of time. If it's super-important, the rfc-to-be for bundle can > be updated. > > > The other issue is whether there are other SDP parameters (presumably > ones that are specified in terms of PT) that also need to be considered to > be part of the "codec configuration" and needs to be aligned. Imageattr > was proposed as one possibility. > > I don't believe imageattr to be relevant in this case. If it were > relevant, it would only be because the codec in question didn't signal > resolution in-band, but in that case, fmtp line should contain the > resolution in that case. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bf10aea63e0db04e2cedd07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed !!!

On Wed, Jul 31, 2013 at 2:01 P= M, Martin Thomson <martin.thomson@gmail.com> wrote:
On 31 July 2013 13:51, Jonathan Lennox <jonathan@vidyo.com> wrote:
> As I mentioned at the mic today, my straw-man proposed definition for = "same codec configuration" is:
>
> Two codec configurations are the same if the PT has the same value for= the "rtpmap" and "fmtp" SDP parameters.

This needs to also include the major type that is included in the m= =3D
line (i.e., "audio" or "video").


> Known issues with this definition:
>
> Some codecs (notably H.264's sprop-* parameters, and all of Opus&#= 39;s parameters) have fmtp parameters describe behavior of a sender, or els= e are non-normative indications about the modes that would be most useful b= ut aren't actually necessary to configure a decoder. =A0So it's ove= rly restrictive to insist that fmtp be identical between all the lines.

I don't believe that the utility provided by allowing the fmtp to= be
split in this way outweighs the costs. =A0It's far simpler if this is just defined as above.

> Getting this to work would, I think, require analysis in the style of = draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of ever= y codec anyone cares about.

Exactly. =A0Let's not do that work. =A0Just doing the work would = be hard.
Gaining consensus on it might also cause it to take some significant
amount of time. =A0If it's super-important, the rfc-to-be for bundle ca= n
be updated.

> The other issue is whether there are other SDP parameters (presumably = ones that are specified in terms of PT) that also need to be considered to = be part of the "codec configuration" and needs to be aligned. =A0= Imageattr was proposed as one possibility.

I don't believe imageattr to be relevant in this case. =A0If it w= ere
relevant, it would only be because the codec in question didn't signal<= br> resolution in-band, but in that case, fmtp line should contain the
resolution in that case.
___________________________________= ____________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--047d7bf10aea63e0db04e2cedd07-- From stefan.lk.hakansson@ericsson.com Wed Jul 31 06:45: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 B8F2611E8184 for ; Wed, 31 Jul 2013 06:45:09 -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, J_CHICKENPOX_18=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 DLV8eV38RL+7 for ; Wed, 31 Jul 2013 06:45:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6171411E817E for ; Wed, 31 Jul 2013 06:45:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-c3-51f914defc0f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 35.B0.00725.ED419F15; Wed, 31 Jul 2013 15:45:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 31 Jul 2013 15:45:01 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson Thread-Topic: [MMUSIC] unified plan glareless atomicity improvement Thread-Index: AQHOjefTFl0Fyhd390KvyYw0fHDYow== Date: Wed, 31 Jul 2013 13:45:01 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C341861@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre49kZ+BBlOniVtcO/OP0WLq8scs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGpdMX2AsOcVUs+veSvYHxAUcXIyeHhICJ xIOnV9ghbDGJC/fWs3UxcnEICRxmlJja/JYFwlnCKNF+azkrSBWbQKDE1n0L2EBsEQFdiUVn HwB1c3AwC6hLXF0cBBIWFnCS2D93OxtIWETAWWLOa1eIaj2JHRe7mUFsFgFViRlNKxlBbF4B X4mnF2ezgNhCAgESs848A7uHEeie76fWMIHYzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFs JYnGJU9YIer1JG5MncIGYWtLLFv4mhlil6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipE9 NzEzJ73ccBMjMBIObvmtu4Px1DmRQ4zSHCxK4ryb9M4ECgmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamCUzFDi21utsWCS3yexhFgxabsrCRUfS66/uPNj1/EyJtWi9etcknXUsiac1A+Snf+g 5o9usJzATV8XmU2Ckdf7LD2Xqb1kWiTaVTT519eezTkSZ5jfux4I9F/Xoxr0rZPhd5rBbPMG lecfzZTKL3O6zr29lnWep+Pt9FnNNoJ7EnTFE9dp8CqxFGckGmoxFxUnAgDoqugjUgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:45:09 -0000 On 2013-07-31 14:16, Martin Thomson wrote:=0A= > The draft currently doesn't say much about how the glareless=0A= > negotiation features relate to a=3Dsendrecv/sendonly/etc... I think=0A= > that using recvonly and sendonly could reduce the probability of=0A= > encountering glare.=0A= >=0A= > It's a detail. And obviously, there are tradeoffs here. By choosing=0A= > to use sendonly in an offer, you foreclose the ability of the answerer=0A= > to use that m-line for their streams. So you would need to generate=0A= > extra recvonly m-lines in order to enable the 1-RTT negotiation.=0A= > There may be other implications that then stem from using extra=0A= > m-lines, especially in legacy interop cases, e.g. where BUNDLE=0A= > negotiation fails, or you can't access SSRCs etc..., each of which=0A= > have various negative consequences.=0A= >=0A= > I think that the only guidance needed is something like:=0A= > "Implementations MAY choose to exclusively use m-lines with a=3Dsendonly= =0A= > or a=3Drecvonly in order to further reduce the probably of encountering= =0A= > glare."=0A= =0A= This proposal makes a lot of sense to me. Stefan=0A= =0A= > _______________________________________________=0A= > mmusic mailing list=0A= > mmusic@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/mmusic=0A= >=0A= =0A= From martin.thomson@gmail.com Wed Jul 31 06:45: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 9B44211E817D for ; Wed, 31 Jul 2013 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.143, 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 iLY0vfUhOMNr for ; Wed, 31 Jul 2013 06:45: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 64F8811E8178 for ; Wed, 31 Jul 2013 06:45:28 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so600173wes.26 for ; Wed, 31 Jul 2013 06:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QEKamRQ/OMJ8k23IkRLcHQ0oun2SV0YzQV4OMePbkV0=; b=qkN6Lbc7VOABBX4+7VSzz8CtvCm4PB8XuSnPXiuP/s9h49tV2352Of75EPHMgvhSPh rvGNjOuK0m781U5XE+CCioG7UUvau7YXTYrQLLAU3jr+9EbUTsmE2/HdYcJUAIS9wJRM X0N/U3b8zVqZw8Hq4Gwp0HPBEQLrNwAYX3Xu8xo7N/RSDTbDbRDulZw2SGDIPcakTvs4 2mVApiRXhvAEjeZ6PuGyg+MhM/aYIF32a+umkc7RHXukKqq4shrI7/exiwUXeBx36OTe i+qA8ws/LQHZbazWpnyln5vhVlEQIp+bCLvFjmlJwpc0odD3X3p7ZKx5KWCcWaJ9fmI8 DExw== MIME-Version: 1.0 X-Received: by 10.180.73.68 with SMTP id j4mr4426150wiv.10.1375278327451; Wed, 31 Jul 2013 06:45:27 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 06:45:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 15:45:27 +0200 Message-ID: From: Martin Thomson To: Suhas Nandakumar Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:45:29 -0000 On 31 July 2013 15:34, Suhas Nandakumar wrote: > I am not sure if this proposal answer this topic .. I had a similar proposal > with uni-directional handling w.r.t glare ... > > http://tools.ietf.org/id/draft-nandakumar-rtcweb-glare-handling-00.txt I think that in many respects, the unified approach to glare handling is similar to your glare draft. However, I believe that the unified plan approach doesn't mandate the crazy m-line reordering shenanigans you propose there :) Any unified plan implementation would no longer require a strictly ordered set of m-lines. From suhasietf@gmail.com Wed Jul 31 06:46: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 5884521F9B11 for ; Wed, 31 Jul 2013 06:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 G23j6dLECYxV for ; Wed, 31 Jul 2013 06:46:43 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A1CF821F9F5C for ; Wed, 31 Jul 2013 06:46:42 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so635003wes.15 for ; Wed, 31 Jul 2013 06:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SqZYtDk+zjdGrLxon5KYpzW/P/9ZOEug9JkJX2fL0tg=; b=LnA42Cz9LV+z95NjzINn79eDC8U88BsNZRNOiYvbPnCBolb1g4lqiz00frEESexcNn KlEbQuM7b/HDS8GXPLfAI/lTbPLMrSUVSfQbPpcnwnyIOXKVfOVk4GwuPbX6c+GSA4VM h+gsERCPfeymKFe/qcXqJpzi20m/j/zNrbSiAsRxJL8cjOYybENhQF0VTg3HLSiuGP+V NbVf2Wvaq2DLxCzUkA7GuMBFcLYHE2nRqB0gsOUTYfRAoD4Rl5AhQScSfFLRNOCmKLLR z43IKK1tLBNSBG6Ko9SBLgQHp+3gRBBd4gIpyb1Xyn9d1KHfkUCMfmISByXiCWdKEnkF qRCg== MIME-Version: 1.0 X-Received: by 10.194.81.39 with SMTP id w7mr28189197wjx.51.1375278401758; Wed, 31 Jul 2013 06:46:41 -0700 (PDT) Received: by 10.194.9.9 with HTTP; Wed, 31 Jul 2013 06:46:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 15:46:41 +0200 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bb70e129aabc404e2cef4ed Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 13:46:44 -0000 --047d7bb70e129aabc404e2cef4ed Content-Type: text/plain; charset=ISO-8859-1 100% Agreed on the martial arts issue. :-) Cheers Suhas On Wed, Jul 31, 2013 at 3:45 PM, Martin Thomson wrote: > On 31 July 2013 15:34, Suhas Nandakumar wrote: > > I am not sure if this proposal answer this topic .. I had a similar > proposal > > with uni-directional handling w.r.t glare ... > > > > http://tools.ietf.org/id/draft-nandakumar-rtcweb-glare-handling-00.txt > > I think that in many respects, the unified approach to glare handling > is similar to your glare draft. However, I believe that the unified > plan approach doesn't mandate the crazy m-line reordering shenanigans > you propose there :) Any unified plan implementation would no longer > require a strictly ordered set of m-lines. > --047d7bb70e129aabc404e2cef4ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 100% Agreed on the martial arts issue. :-) =A0

Cheers
Suhas

On Wed, Jul 31, 2013= at 3:45 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 31 July 2013 15:34, Suh= as Nandakumar <suhasietf@gmail.co= m> wrote:
> I am not sure if this proposal answer this topic .. I had a similar pr= oposal
> with uni-directional handling w.r.t glare ...
>
> http://tools.ietf.org/id/draft-nandakumar-rt= cweb-glare-handling-00.txt

I think that in many respects, the unified approach to glare handling=
is similar to your glare draft. =A0However, I believe that the unified
plan approach doesn't mandate the crazy m-line reordering shenanigans you propose there :) =A0Any unified plan implementation would no longer
require a strictly ordered set of m-lines.

--047d7bb70e129aabc404e2cef4ed-- From tireddy@cisco.com Wed Jul 31 07:13: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 22C4611E818B for ; Wed, 31 Jul 2013 07:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, OBSCURED_EMAIL=0.001, 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 mE0sqCacS+Tz for ; Wed, 31 Jul 2013 07:13:47 -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 DDA7311E81BC for ; Wed, 31 Jul 2013 07:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4529; q=dns/txt; s=iport; t=1375280027; x=1376489627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KYLAzA5ky5RvUyM+65LCJCzC1i8JdblgNIVd/qSpj1Q=; b=duDYNAN9AdbBWf+sBqx7k6gHIPowiKoA6lmFsKn6U6qnc+FQH0QEpP5d 9AEy02Uqg5ilJGsgOgWCKY/DRrbpISs+RsXlYmRVDeCN1jUmoZQJLa6+g 7e7hj6wc7tOa3TK4wvJ0a8mq4df4DnO3jnzfnEpTgGarLsyOKL/ygh17A g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAFIa+VGtJV2d/2dsb2JhbABbgwY1UL4dgRcWdIIkAQEBAwEBAQFrCwwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCIgCBgy4VY9WMQcGgxJzA4hykBaQJIMUgio X-IronPort-AV: E=Sophos;i="4.89,787,1367971200"; d="scan'208";a="241776168" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2013 14:13:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VEDkGD019570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 14:13:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 09:13:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOjc8e11SEQQIfXUy0NUn1kHVbfZl+uC4w Date: Wed, 31 Jul 2013 14:13:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> References: <51F8D6B6.6080109@ericsson.com> In-Reply-To: <51F8D6B6.6080109@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.96] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 14:13:52 -0000 > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Wednesday, July 31, 2013 2:50 PM > To: mmusic@ietf.org > Cc: Bernard Aboba; Martin Thomson; Tirumaleswar Reddy (tireddy) > Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and IC= E bis >=20 > Hi, >=20 > If we can do this as updated recommendations on how to prioritize the > candidates, then I think it makes a lot of sense to integrate this into > 5245bis. If it gets much more complicated than this, probably separate > document makes more sense. >=20 > Tiru mentioned that simply tweaking the priorities may not work in all > cases, so perhaps we should have a look at those cases and see if we can > make them work. Hi Ari, Using the formula in RFC 5245 priority =3D (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) Type preference of=20 Host candidates > Server-reflexive candidates > Relayed candidates (For example host candidate is 126, server-reflexive 105) that causes the problem that when candidate pair priority is calculated (pr= iority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)) The candidate pair IPv4 (host, server-reflexive) will only be tested only a= fter all IPv6 host candidate-pairs, IPv4 host candidate pairs. Even if policy table RFC 6724 is changed so that IPv4 addresses have higher= precedence that does not solve the problem, It will still result in IPv4 (= host, server-reflexive) to be tested only after all IPv4 host candidate pai= rs, IPv6 host candidate-pairs. Hence during the WG session, I had explained that by tweaking the candidate= priority will not solve the problem, but the candidate pair priority has t= o be adjusted after offer/exchange such that after NNN number of preferred = IPv6 candidate pairs the highest-priority IPv4 candidate-pair is tested and= the above adjustment continued until all candidate pairs of the preferred = address family are exhausted. This will gave a chance for candidate pair with server-reflexive candidates= to be tested earlier, which is not possible just by increasing the local c= andidate priority. Best Regards, --Tiru. >=20 >=20 > Cheers, > Ari (as individual) >=20 > On 7/31/13 9:31 AM, Bernard Aboba wrote: > > I agree that it doesn't make sense to pursue the happy-eyeballs draft > > and that folding fixes into RFC 5245bis is the best approach. > > > > A number of ICE implementations do not follow the priority guidance in > > RFC 5245 Section 4.1.2.1 because it doesn't work, and also because > > guidelines such as DoD 2008 UCR Change 3 require that implementations b= e > > able to prioritize IPv4 over IPv6. So in practice, the advice in RFC > > 5245 Section 4.1.2.1 has long been overtaken by events. > > > > > http://tools.ietf.org/html/rfc5245#section-4.1.2.1 > > > > > > After talking to Jonathan, several things have become apparent. > > > > > > The prioritization calculation described in Section 4.1.2.1 of RFC > > > 5245 is not mandatory, it's SHOULD only. This means that the guidanc= e > > > regarding prioritization of IPv6 over IPv4 is not applied as strictl= y > > > and blindly as implied by the happy eyeballs draft. Implementations > > > can choose a different prioritization. (I was under the > > > misapprehension that only part of the priority was signaled, but > > > that's clearly not the case.) > > > > > > That implies to me that the happy-eyeballs draft is, as best, only > > > worth pursuing as an information addendum that provides guidance on > > > non-stupid selection of priorities for dual-stack hosts. > > > > > > However, given the existence of an RFC5245bis effort, I am going to > > > suggest that the guidance provided instead be folded into a revised > > > Section 4.1.2.1. > > > > > > Another problem that can be addressed at the same time is a removal = of > > > all the normative language that surrounds this optional feature. The > > > current 4.1.2.1 has lots of "MUST" statements that are both > > > unnecessary and confusing. > > > > > > --Martin > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > From martin.thomson@gmail.com Wed Jul 31 07:34: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 083C021E8123 for ; Wed, 31 Jul 2013 07:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, OBSCURED_EMAIL=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 iMe71eOHTq9f for ; Wed, 31 Jul 2013 07:34:49 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 09A0D21E80F8 for ; Wed, 31 Jul 2013 07:34:48 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so3693565wiw.15 for ; Wed, 31 Jul 2013 07:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=57kvHTU483iiGV9tZK3YxhpwyoLudTcCuX9x2WH1kXw=; b=zZz0PLosarFSpHHVIGUzdNS4GZ42gRaBcYqcV/dw6FRIlH5HvDhdGXdLlwjMgkT2VJ OyBGmWPQWipVTbW5RAiuVyuOKS/TDRTq05cpGobtqcj5/Vmwo6QluZlKV7k25LERTm2B cBAmIdy/XH8fKjvTH7IM/YW0Y1YaozmH+mjix9GlTwpzD7H8sTJd8CPmo8QY4FM39PYl V51AUBaS8h28pPzFkHMc7huWGq00QukG5efwvjWx9wFRhERgqUZ4aSRK3863ppGcx7qP lS9VqPejYzb1ZGp6CWFXpXsSy+kj2V0FQKLkue5BpoRHkIfPO7OLsaflVZtPzqWU6LAq 0YUg== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr4541703wik.14.1375281288108; Wed, 31 Jul 2013 07:34:48 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 07:34:48 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> Date: Wed, 31 Jul 2013 16:34:48 +0200 Message-ID: From: Martin Thomson To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 14:34:50 -0000 On 31 July 2013 16:13, Tirumaleswar Reddy (tireddy) wrote: > Using the formula in RFC 5245 > > priority = (2^24)*(type preference) + > (2^8)*(local preference) + > (2^0)*(256 - component ID) This formula is just a recommendation (a SHOULD, to be fair). So the rest of your thesis isn't really valid. From jonathan@vidyo.com Wed Jul 31 07:45: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 6ED7111E818B for ; Wed, 31 Jul 2013 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, OBSCURED_EMAIL=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 xk9ofnjzLvev for ; Wed, 31 Jul 2013 07:45:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 460E321F9E3B for ; Wed, 31 Jul 2013 07:45:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F4C15536CE; Wed, 31 Jul 2013 10:43:35 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A2B315535C7; Wed, 31 Jul 2013 10:43:34 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 31 Jul 2013 10:43:02 -0400 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Date: Wed, 31 Jul 2013 10:45:08 -0400 Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: Ac6N/G2JUzjT5oveTOyOsrk6GOCXaw== Message-ID: <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 14:45:35 -0000 On Jul 31, 2013, at 4:13 PM, "Tirumaleswar Reddy (tireddy)" wrote: >=20 > Using the formula in RFC 5245 >=20 > priority =3D (2^24)*(type preference) + > (2^8)*(local preference) + > (2^0)*(256 - component ID) >=20 > Type preference of=20 > Host candidates > Server-reflexive candidates > Relayed candidates >=20 > (For example host candidate is 126, server-reflexive 105) >=20 > that causes the problem that when candidate pair priority is calculated (= priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)) > The candidate pair IPv4 (host, server-reflexive) will only be tested only= after all IPv6 host candidate-pairs, IPv4 host candidate pairs. >=20 > Even if policy table RFC 6724 is changed so that IPv4 addresses have high= er precedence that does not solve the problem, It will still result in IPv4= (host, server-reflexive) to be tested only after all IPv4 host candidate p= airs, IPv6 host candidate-pairs. >=20 > Hence during the WG session, I had explained that by tweaking the candida= te priority will not solve the problem, but the candidate pair priority has= to be adjusted after offer/exchange such that after NNN number of preferre= d IPv6 candidate pairs the highest-priority IPv4 candidate-pair is tested a= nd the above adjustment continued until all candidate pairs of the preferre= d address family are exhausted. The first formula you quote is the one that RFC 5245 defines as recommended= , not mandatory. What we're suggesting be changed is not the "local prefer= ence" field, but actually the calculated 32-bit "priority" field for the ca= ndidate. You can set your priorities such that some server-reflexive candi= dates have higher priority than some host candidates, and the calculation o= f the pair's 64-bit priority will still work. We need to be pretty careful when defining a new formula for how these prio= rities are set, though. > This will gave a chance for candidate pair with server-reflexive candidat= es to be tested earlier, which is not possible just by increasing the local= candidate priority. >=20 > Best Regards, > --Tiru. >=20 >>=20 >>=20 >> Cheers, >> Ari (as individual) >>=20 >> On 7/31/13 9:31 AM, Bernard Aboba wrote: >>> I agree that it doesn't make sense to pursue the happy-eyeballs draft >>> and that folding fixes into RFC 5245bis is the best approach. >>>=20 >>> A number of ICE implementations do not follow the priority guidance in >>> RFC 5245 Section 4.1.2.1 because it doesn't work, and also because >>> guidelines such as DoD 2008 UCR Change 3 require that implementations b= e >>> able to prioritize IPv4 over IPv6. So in practice, the advice in RFC >>> 5245 Section 4.1.2.1 has long been overtaken by events. >>>=20 >>>> http://tools.ietf.org/html/rfc5245#section-4.1.2.1 >>>>=20 >>>> After talking to Jonathan, several things have become apparent. >>>>=20 >>>> The prioritization calculation described in Section 4.1.2.1 of RFC >>>> 5245 is not mandatory, it's SHOULD only. This means that the guidance >>>> regarding prioritization of IPv6 over IPv4 is not applied as strictly >>>> and blindly as implied by the happy eyeballs draft. Implementations >>>> can choose a different prioritization. (I was under the >>>> misapprehension that only part of the priority was signaled, but >>>> that's clearly not the case.) >>>>=20 >>>> That implies to me that the happy-eyeballs draft is, as best, only >>>> worth pursuing as an information addendum that provides guidance on >>>> non-stupid selection of priorities for dual-stack hosts. >>>>=20 >>>> However, given the existence of an RFC5245bis effort, I am going to >>>> suggest that the guidance provided instead be folded into a revised >>>> Section 4.1.2.1. >>>>=20 >>>> Another problem that can be addressed at the same time is a removal of >>>> all the normative language that surrounds this optional feature. The >>>> current 4.1.2.1 has lots of "MUST" statements that are both >>>> unnecessary and confusing. >>>>=20 >>>> --Martin >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 -- Jonathan Lennox jonathan@vidyo.com From ari.keranen@ericsson.com Wed Jul 31 08:56: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 5018421F9981 for ; Wed, 31 Jul 2013 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.428 X-Spam-Level: X-Spam-Status: No, score=-4.428 tagged_above=-999 required=5 tests=[AWL=1.520, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, OBSCURED_EMAIL=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 iyi6671UIjZI for ; Wed, 31 Jul 2013 08:56:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7689021F847C for ; Wed, 31 Jul 2013 08:56:27 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-f9-51f933aa77f8 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1A.E3.05990.AA339F15; Wed, 31 Jul 2013 17:56:26 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Wed, 31 Jul 2013 17:56:25 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B2C8B110233; Wed, 31 Jul 2013 18:56:25 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3BD674FE29; Wed, 31 Jul 2013 18:56:21 +0300 (EEST) Received: from dhcp-431b.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C146A4FA79; Wed, 31 Jul 2013 18:56:20 +0300 (EEST) Message-ID: <51F933A8.2060504@ericsson.com> Date: Wed, 31 Jul 2013 17:56:24 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Lennox References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> In-Reply-To: <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.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+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre4q45+BBs/3K1rsX3ye2eLamX+M FlOXP2axOLF7G6MDi8eU3xtZPXbOusvusWTJTyaPtmd32ANYorhsUlJzMstSi/TtErgybvVc Zyq4LlTxqeMCWwNjL38XIyeHhICJxKF5G1kgbDGJC/fWs4HYQgKHGSWaJkh2MXIB2RsYJWZe P8oO4exllOhZ9BTKWcco8fzVfiaIFhBnuweIzSugLdFw+z/YKBYBVYk9CyczgthsAvYSNydc B2rm4BAVSJZ4ecQIolxQ4uTMJ2BXiAhoSFx89oENZD6zQAejxKxX7WAJYYEAiSWvN7BALJ7A JLH960SwoZwCthI/Vm9hBbGZgewLc66zQNjyEtvfzmGG+E1N4uq5TcwQh6pKXP33inECo+gs JMtnIWmfhaR9ASPzKkb23MTMnPRyo02MwAg5uOW36g7GO+dEDjFKc7AoifNu1jsTKCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoGRif3pe4F9XB3ZJfJbXLQKfthUfopl5C7vbphzvGCe3Icn i10vCzlNSHh7Zv6VV1/rl35lbVrqm/t1T/mtHdczFrlat/b+LnvQ3jvbPDflC4u7/H+ehxu3 CK96zv+Pdd2ilSU3JHa866z2EeG5oqMbP9V20tKH1/dPic3c3DCX8zNzwzLh2NfPlFiKMxIN tZiLihMBLeGGzV4CAAA= Cc: "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 15:56:46 -0000 On 7/31/13 4:45 PM, Jonathan Lennox wrote: > > On Jul 31, 2013, at 4:13 PM, "Tirumaleswar Reddy (tireddy)" wrote: >> >> Using the formula in RFC 5245 >> >> priority = (2^24)*(type preference) + >> (2^8)*(local preference) + >> (2^0)*(256 - component ID) >> >> Type preference of >> Host candidates > Server-reflexive candidates > Relayed candidates >> >> (For example host candidate is 126, server-reflexive 105) >> >> that causes the problem that when candidate pair priority is calculated (priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)) >> The candidate pair IPv4 (host, server-reflexive) will only be tested only after all IPv6 host candidate-pairs, IPv4 host candidate pairs. >> >> Even if policy table RFC 6724 is changed so that IPv4 addresses have higher precedence that does not solve the problem, It will still result in IPv4 (host, server-reflexive) to be tested only after all IPv4 host candidate pairs, IPv6 host candidate-pairs. >> >> Hence during the WG session, I had explained that by tweaking the candidate priority will not solve the problem, but the candidate pair priority has to be adjusted after offer/exchange such that after NNN number of preferred IPv6 candidate pairs the highest-priority IPv4 candidate-pair is tested and the above adjustment continued until all candidate pairs of the preferred address family are exhausted. > > The first formula you quote is the one that RFC 5245 defines as recommended, not mandatory. What we're suggesting be changed is not the "local preference" field, but actually the calculated 32-bit "priority" field for the candidate. You can set your priorities such that some server-reflexive candidates have higher priority than some host candidates, and the calculation of the pair's 64-bit priority will still work. > > We need to be pretty careful when defining a new formula for how these priorities are set, though. If it's only about updating that formula, this indeed looks like a good way forward. Just need to think how to get all we want to express (and what do we actually want to express) in a priority formula that isn't overly complex. Expressing things like "some IPv4 host-srvrflx should be prioritized over (some) IPv6 host-host but v4 host-host below (some) v6 host-host" etc may get a bit messy. Cheers, Ari From harald@alvestrand.no Wed Jul 31 09:02: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 328C421F9DD0 for ; Wed, 31 Jul 2013 09:02:31 -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 vhAgaRyc9cSC for ; Wed, 31 Jul 2013 09:02:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C82221F9A96 for ; Wed, 31 Jul 2013 09:02:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D75D339E128 for ; Wed, 31 Jul 2013 18:02:21 +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 zuHgVJm4GA1M for ; Wed, 31 Jul 2013 18:02:21 +0200 (CEST) Received: from [IPv6:2001:df8:0:16:b1e0:abc8:8c6a:54b0] (unknown [IPv6:2001:df8:0:16:b1e0:abc8:8c6a:54b0]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2418A39E0E1 for ; Wed, 31 Jul 2013 18:02:21 +0200 (CEST) Message-ID: <51F9350C.109@alvestrand.no> Date: Wed, 31 Jul 2013 18:02:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> In-Reply-To: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 16:02:33 -0000 On 07/31/2013 01:51 PM, Jonathan Lennox wrote: > As I mentioned at the mic today, my straw-man proposed definition for "same codec configuration" is: > > Two codec configurations are the same if the PT has the same value for the "rtpmap" and "fmtp" SDP parameters. > > > Known issues with this definition: > > Some codecs (notably H.264's sprop-* parameters, and all of Opus's parameters) have fmtp parameters describe behavior of a sender, or else are non-normative indications about the modes that would be most useful but aren't actually necessary to configure a decoder. So it's overly restrictive to insist that fmtp be identical between all the lines. > > Getting this to work would, I think, require analysis in the style of draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every codec anyone cares about. > > The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be aligned. Imageattr was proposed as one possibility. > With regard to imageattr, draft-nandakumar classifies it as NORMAL, which I think means that it only applies to flows that are mapped to the M-line in which the attribute occurs. So in the SDP fragment m=video 1234 RTP/AVPF 97 a=ssrc:9876 a=rtpmap:97 VP8 a=imageattr:97 [x=1280,y=720] m=video 2345 RTP/AVPF 97 a=ssrc:5432 a=rtpmap:97 VP8 a=imageattr:97 [x=640,y=360] I think it is clear which flow each imageattr is intended to point to. From martin.thomson@gmail.com Wed Jul 31 09:16: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 A1F7221F8D96 for ; Wed, 31 Jul 2013 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 PI-IjshRGdNv for ; Wed, 31 Jul 2013 09:16:24 -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 000C821F8D10 for ; Wed, 31 Jul 2013 09:16:23 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so855863wib.4 for ; Wed, 31 Jul 2013 09:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xg6Y+JFuDphcPXFADpQ5Cbx8K1Y+ZvL6afJksV/oRiA=; b=iDuM7b3IR/N06tOaaRoFvMTO5L1wMWEXDiHydiyh2p0V1fJAz6CcC9BkV5CWsqnqME MsJqQxl+fJhON3g1eiNVpvbqykJrlVxK1rFrvZDviL5YB+3C0aZJ3VBDdlXakF5KeOLL 0wCOBd7kMmuaKUwct4sQstYuMK7HCXS6+GPBOqqiMDOlB3AB3UlIQ9kohRHXHln+xAtT zIxWt17cmM24CNCk72p2jZb5Rfz0bdjKROZND1S78XiQ67kewotR+X0efvs0Mhx+tjRp t5d6VuvfbIqt+7HI861nOCam5EWaK3Zi3oQq+GUESwCHH+CZMUAjg65ctj2F5+8JgEWe sCCg== MIME-Version: 1.0 X-Received: by 10.180.92.1 with SMTP id ci1mr4848501wib.14.1375287381874; Wed, 31 Jul 2013 09:16:21 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 09:16:21 -0700 (PDT) In-Reply-To: <51F933A8.2060504@ericsson.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> Date: Wed, 31 Jul 2013 18:16:21 +0200 Message-ID: From: Martin Thomson To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 16:16:24 -0000 On 31 July 2013 17:56, Ari Ker=C3=A4nen wrote: > overly complex Yes. Given that this is a very small part of a spec that already fits that description, we need to be careful. From pkyzivat@alum.mit.edu Wed Jul 31 09:44: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 334B221F9F8A for ; Wed, 31 Jul 2013 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 NgrxPodD9S08 for ; Wed, 31 Jul 2013 09:44:27 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8168D21F9F8F for ; Wed, 31 Jul 2013 09:44:27 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 72eT1m00317UAYkA64kTM3; Wed, 31 Jul 2013 16:44:27 +0000 Received: from dhcp-4066.meeting.ietf.org ([130.129.64.102]) by omta13.emeryville.ca.mail.comcast.net with comcast id 74iH1m00f2CN8kq8Z4iL7G; Wed, 31 Jul 2013 16:42:25 +0000 Message-ID: <51F93E68.20705@alum.mit.edu> Date: Wed, 31 Jul 2013 18:42:16 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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=1375289067; bh=GgTWfJ9lNhf+aG1dKC2EwETsv/N9Qo4xeO3RNRKWZSo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JvHD3gGsCDEMBSD05ui6gtDX4dayzEB0ztxSNi8hsflVZk0Qw3ssP7ry76XdcReum KRGBB/Lg3oyOOnkaCnNLwkZ2zyTX2jhFrbYqKY1G39yE2U0RwatFeYdMEMQbDSndaA J0TUIFKvpkOJK6pgDUjYsB3cZnzOSZxN6o5wDvN149ijxSJunI9r9Y6a+1vgR0Biyd Js9gJLsIVcmRKphv21yOkg5j+3wuh9FCVTGvy1hds5DtCnsDYOWddGCmEi7Lya9mhC PxWCFrXqrNT4PIYTcmkckv5+TAUkx4CcSib12HcZHTq/d8I5QTi3qkNzVmG0L6Ed3C cvlwEIFUI4xYw== Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 16:44:32 -0000 I don't understand how sendonly and recvonly reduce glare. If I offer a sendonly m-line, it still must be answered. And subsequently an offer for that m-line can come from either side, possibly producing glare. ISTM that you should offer a sendrecv m-line iff you intend a bidirectional flow, where the two sides are related, will have common properties and lifetimes. There is still a problem if both sides want a bidirectional flow, but aren't agreed on who should initiate it. In that case they both might offer and glare. And there there remains the question of whether they recognize this as glare, rather than thinking they need both flows. Thanks, Paul On 7/31/13 2:16 PM, Martin Thomson wrote: > The draft currently doesn't say much about how the glareless > negotiation features relate to a=sendrecv/sendonly/etc... I think > that using recvonly and sendonly could reduce the probability of > encountering glare. > > It's a detail. And obviously, there are tradeoffs here. By choosing > to use sendonly in an offer, you foreclose the ability of the answerer > to use that m-line for their streams. So you would need to generate > extra recvonly m-lines in order to enable the 1-RTT negotiation. > There may be other implications that then stem from using extra > m-lines, especially in legacy interop cases, e.g. where BUNDLE > negotiation fails, or you can't access SSRCs etc..., each of which > have various negative consequences. > > I think that the only guidance needed is something like: > "Implementations MAY choose to exclusively use m-lines with a=sendonly > or a=recvonly in order to further reduce the probably of encountering > glare." > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Wed Jul 31 10:08: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 5CCAD21E80CA for ; Wed, 31 Jul 2013 10:08:22 -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 j0y1JUDnqMSc for ; Wed, 31 Jul 2013 10:08:16 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7DE21E80B1 for ; Wed, 31 Jul 2013 10:08:09 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 72as1m0060lTkoCA7589Zq; Wed, 31 Jul 2013 17:08:09 +0000 Received: from dhcp-4066.meeting.ietf.org ([130.129.64.102]) by omta04.emeryville.ca.mail.comcast.net with comcast id 755z1m00R2CN8kq8Q5623p; Wed, 31 Jul 2013 17:06:06 +0000 Message-ID: <51F943F6.7050904@alum.mit.edu> Date: Wed, 31 Jul 2013 19:05:58 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.com> In-Reply-To: <1EEEAEB9-F659-4D3B-A141-9A054891FD60@vidyo.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=1375290489; bh=CZgnaDQchTGBuaHqz4mUa9MsuAMX+95u7B4UvZANQzU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cf/YpYLv6GiVIZ4zRNjYLScL4JJJRKC/RTbDBzk+OyBmaqjoMjrOdxsPyRolHXYVd c4T/MtFjFmWJptfvuAFzhAgnC4eQw5nEz81HSr0C/eyMK/UCr3Ns4aqnuKhJK+eK5w bb2JdyfVcjcJXI9fQG2n9r8R8KlWegmyyarwcqjUvwNMaaClU8iPVEAXVnqvEDLhfy crn7rKgutTSdnYZGU6UKz0F7I1W/Bv7tAWFz8xBjbgF4/uGNm5ag4fxyFz9GhOOBgt 34rE+sllDespMGzYaytcmc/qdZzfOyDucUK+nnU+qVRpGCtBwk/q0oPNVfQayX50Qi k6kOQJAHRVE6w== Subject: Re: [MMUSIC] Proposed definition for "same codec configuration" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 17:08:22 -0000 On 7/31/13 1:51 PM, Jonathan Lennox wrote: > As I mentioned at the mic today, my straw-man proposed definition for "same codec configuration" is: > > Two codec configurations are the same if the PT has the same value for the "rtpmap" and "fmtp" SDP parameters. > > > Known issues with this definition: > > Some codecs (notably H.264's sprop-* parameters, and all of Opus's parameters) have fmtp parameters describe behavior of a sender, or else are non-normative indications about the modes that would be most useful but aren't actually necessary to configure a decoder. So it's overly restrictive to insist that fmtp be identical between all the lines. > > Getting this to work would, I think, require analysis in the style of draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every codec anyone cares about. > > The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be aligned. Imageattr was proposed as one possibility. I have a couple of questions: When configuring encoder/decoder parameters, regardless of what sort of line does it: AFAIK there is separate encoder/decoder state for each SSRC, right? So these parameters are just templates that are used for however many encoders &/ decoders are set up for that m-line. (Each with a different SSRC.) If you are mapping packets to m-lines by SSRC, then having different values per-m-line works. Now suppose you were mapping packets to m-lines via appid rather than SSRC. And suppose initially all packets having appid X have SSID 1111, and that is the first appearance of 1111. Then presumably the attributes of the m-line corresponding to appid X will determine how the decoder are initialized. Then SSID 1111 is reassigned to appid Y, and is mapped to a different m-line. That m-line has different decoder parameters. Should the decoder for 1111 be reconfigured? Thanks, Paul From martin.thomson@gmail.com Wed Jul 31 10:47: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 BED3621F9C13 for ; Wed, 31 Jul 2013 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_18=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 CJL-a2JnDZQa for ; Wed, 31 Jul 2013 10:47:23 -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 2744911E818F for ; Wed, 31 Jul 2013 10:47:16 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so3659143wiw.2 for ; Wed, 31 Jul 2013 10:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cxwPTgvTW+TuyjSwRJoaIQsg1e9QRwTq69sKg+tsMcY=; b=OkqA/rwXeO2oaCd/Mm6tlLA/eKko+FS0kPqrc4lWhet2TXOiYcJvyCBrNb7QtP/3ov K6un8kWPwppJugSOtV0B6GkWl5yer282f45Q/Iifz2kN4fBWNtJoYunuGp0i83wkvhvZ dPBOUF2pY5/z8shcfKUFrokCDHzgF00jgKkanMwBu4pIojV4w3EYiWhmB/jp3ksVF2kU DJENDNM4vQZJQNi49+SFXKVdvyDrwkyYKetni8hNODYC1qnyo4dJvs35FKI3FdMesAzX O+3hZxwK6yjP7bkYBz82nOGlRnn8i5opPSjiNwsBVZSncBtaNZmhSv+Ec0qGTXocra04 dRoA== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr3018594wic.65.1375292836225; Wed, 31 Jul 2013 10:47:16 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 31 Jul 2013 10:47:16 -0700 (PDT) In-Reply-To: <51F93E68.20705@alum.mit.edu> References: <51F93E68.20705@alum.mit.edu> Date: Wed, 31 Jul 2013 19:47:16 +0200 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2013 17:47:24 -0000 On 31 July 2013 18:42, Paul Kyzivat wrote: > I don't understand how sendonly and recvonly reduce glare. It just reduces the probability of a change collision by further increasing the atomicity of the overall fragmented document. For a bi-directional line in a=sendrecv, there is more *stuff*. There really isn't such a thing as a bidirectional flow once you are talking about BUNGLE.