From tim@phonefromhere.com Tue May 1 02:04:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D121F8718 for ; Tue, 1 May 2012 02:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, 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 n2b+BT3laz9Q for ; Tue, 1 May 2012 02:04:14 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0577221F8713 for ; Tue, 1 May 2012 02:04:13 -0700 (PDT) Received: from [192.168.157.66] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id F3B2C37A90A; Tue, 1 May 2012 10:13:19 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Tue, 1 May 2012 10:04:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88BF36F4-AF20-433D-A641-86206775C53D@phonefromhere.com> References: To: Stephan Wenger X-Mailer: Apple Mail (2.1257) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 09:04:14 -0000 To be a little clearer.=20 If what the use case describes is a 1-for-1 replacement of an (0)800 = number with a rtcWeb call, (no context share, no leveraging of web identity) into a=20 standard current call center. I don't think that this case is worthwhile = to add. If the usecase describes how context sharing, web identity might be used = in a call center scenario - I'm all for it.=20 All I am saying is that if rtcWeb doesn't add any user benefits over = (0)800 then, based on my experience, almost no one will use it. So we should not = allow the like-for-like replacement case to unduly set requirements T. On 30 Apr 2012, at 23:27, Stephan Wenger wrote: > Hi Randell, > I don't buy this argument. > Speakers are a standard piece of equipment now; almost everyone with a = PC > has them in some form. Without a webcam, webrtc would be pretty = useless, > and every webcam nowadays has a microphone. > I have no reason to distrust Tim's assessment, but the reason for the = lack > of success of PC facilitated sales doers you cited, IMO, cannot be the > main reason, and certainly not among the expected users of webrtc (who > WILL have speakers, camera and mic set up, ready to go, and used to = make > calls from their machine). And if your argument refers to the call = center > site--well, those guys will get their equipment right and train their > employees, or go out of business. > Lets not dismiss a use case based on short term observations. > Stephan >=20 > On 4.30.2012 23:09 , "Randell Jesup" wrote: >=20 >> On 4/30/2012 9:54 AM, Tim Panton wrote: >>>=20 >>> On 30 Apr 2012, at 09:42, Ravindran, Parthasarathi wrote: >>=20 >>>> My experience is different. Click-to-call is attractive in case of >>>> toll-free number in the site. WebRTC provides complete free call >>>> without any toll. >>>=20 >>> I can't tell you the actual numbers, but when presented with the = choice >>> of calling a toll free number >>> or clicking a button marked "free internet call" - almost no-one on = a >>> real, busy site clicked the button. >>> ( for every button click there were several orders of magnitude more >>> 0800 calls from that page). >>>=20 >>>=20 >>> So from my perspective this is a legacy interop use case with almost >>> zero user acceptance. >>=20 >> How many people browsing have mic, speakers, or headphones, set up, = and >> are comfortable with it? >>=20 >> Things are changing, but a friend who consults for non-tech small >> businesspeople and individual home-based businesses avoids using = audio >> when doing screen-share type stuff and instead starts a parallel = audio >> POTS call, because it's too frequently a waste of time for them to = find >> and set up headphones, get their mic to work. >>=20 >> If it's people who are already using Skype/etc, there's a better = chance >> - but they still may only be comfortable with Skype for "calls". >>=20 >>=20 >> --=20 >> Randell Jesup >> randell-ietf@jesup.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Jim.Barnett@genesyslab.com Tue May 1 05:05:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7C21F8917 for ; Tue, 1 May 2012 05:05:18 -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 xzeec+dIwGeY for ; Tue, 1 May 2012 05:05:17 -0700 (PDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB3421F8912 for ; Tue, 1 May 2012 05:05:16 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q41C5DSe024265; Tue, 1 May 2012 05:05:13 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 05:05:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 05:05:10 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Use Case draft Thread-Index: Ac0nTFLl/9EbPL8aSUuAPFBnyrc69QARAfSw References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com><2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com><387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com><4F9EC0B2.10903@alcatel-lucent.com><101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> From: "Jim Barnett" To: "Marshall Eubanks" , "Hutton, Andrew" X-OriginalArrivalTime: 01 May 2012 12:05:14.0734 (UTC) FILETIME=[AAC4B8E0:01CD2792] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 12:05:18 -0000 One way to describe the use case is to let the contact center's media = server/gateway serve as the webRTC endpoint. Then all the issues of = call delivery, call monitoring, etc. disappear. They are handled by = application software that sits behind the webRTC endpoint. The company = I work for makes a good living selling software that deals with all = these issues - including bathroom breaks - and that's how we would tend = to think of this case. To us, it's a new kind of call/connection coming = into the contact center, which we translate into SIP at the border and = then handle normally.=20 It's not clear to me if this use case adds any extra requirements. We = would just have to be careful not to assume that a webRTC endpoint is = always a person/browser-based user agent. It may seem a bit unsettling = that the webRTC endpoint can distribute the call somewhere else and let = others listen in, but as far as I can tell that is already the case. If = Bob calls Alice with full authentication and security, he can be sure = that he is connected to Alice's user agent and that no one in between = can listen in, but there's nothing stopping Alice from recording the = audio, or forwarding it to a third party. So Bob could in fact be = talking to Mary if that's how Alice wants to arrange things (_behind_ = her user agent). In general, Bob is assured only that he is talking to = someone Alice wants him to talk to, and that no one can snoop without = Alice's permission. That's very much the way things work with the call = center - you are sure that you are 1) connected securely to your bank 2) = talking to someone that the bank wants you to talk to 3) being recorded = or snooped on only when the bank explicitly chooses to do so. =20 - Jim=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Marshall Eubanks Sent: Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft On Mon, Apr 30, 2012 at 2:31 PM, Hutton, Andrew = wrote: > Whether anybody has been successful in the past with this type of use=20 > case is I think irrelevant. > > > > The enterprise call centre use case is I think a vital use case=20 > because it is a scenario in which one user is only concerned that they = > can securely reach an organization/domain and is not concerned about=20 > the individual within that domain=A0 that they communicate with.=A0 A=20 > suspect quite a large percentage of RTCWEB applications will be like=20 > this and it is not covered in the current use case draft. I agree that this is a very useful use case and one I think is going to = get a lot of traction. There is a very solid business case for this. = However, I have a fair amount of experience with a video call center for = a client, and it is not as simple as it might seem. The essence of course is that you get the next available person, i.e., = it is anycast. Determining who the next available person is is not = trivial, nor is error recovery. (If I call you, and you don't answer or = the call drops or whatever, I can leave a message or try later. If I = call a help desk, and this happens, I want a new agent, ideally automatically.) Call forwarding (e.g., first tier to second tier = technical support) is essential, and it may be anycast or directed. There are also some security oddities - if I am connecting from home, I = may need to authenticate, use a credit card, etc. If I am connecting = from inside a store, and providing in store video technical support is = big part of the market, then the store authenticates me off line and the = call really should just be a button push, which implies that the store = has previously authenticated some sort of master session. In addition, = unlike most video calls, in the enterprise call center a supervisor may = need to be able to monitor (i.e., watch) a call, and in some = circumstances (financial or medical calls, for example) there will need = to be third party recording. I believe that these details would be = different from the typical RTCWEB scenario. Also, there will be a temptation to do the anycasting by the techniques = used to load balance servers in a data center, but I think that may not = be sufficient. The call "center" may in fact be spread completely across = the planet (daytime support in the US, nighttime support in India, for = example) and be on multiple autonomous systems (and even from people's = homes), which gives rise to some of the transport issues NVO3 may face, = but without any opportunity for packet tagging. Plus, there will = complicated rules about who can be selected next. RTCWEB shouldn't worry = about the intricacies of bathroom break policies; these complexities = should be dealt with by an enterprise-side database, which to me = (together with some of the other issues above) suggests that this would = probably benefit from API support. Regards Marshall > > > > So I think we need it. > > > > Regards > > Andy > > > > > > > > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Igor Faynberg > Sent: 30 April 2012 17:41 > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] Use Case draft > > > > Without numbers it is impossible to argue, but, if we talk about the=20 > perceived need, I disagree.=A0 Think of the people who travel abroad = and=20 > cannot call the 800 number. (I routinely use Web interface for calls=20 > when > traveling.) > > > > I am all for=A0 the use case, as described by Jim. > > Igor > > On 4/30/2012 9:54 AM, Tim Panton wrote: > > ... > > I can't tell you the actual numbers, but when presented with the=20 > choice of calling a toll free number > > or clicking a button marked "free internet call" - almost no-one on a=20 > real, busy site clicked the button. > > ( for every button click there were several orders of magnitude more=20 > 0800 calls from that page). > > > > > > So from my perspective this is a legacy interop use case with almost=20 > zero user acceptance. > > > > (as far as I can see no-one has made this use-case desirable in=20 > practice > yet.) > > Tim. > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Jim.Barnett@genesyslab.com Tue May 1 05:10:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1458B21E8155 for ; Tue, 1 May 2012 05:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, 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 qaJ3-CVrNGv5 for ; Tue, 1 May 2012 05:10:16 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id F145521E8163 for ; Tue, 1 May 2012 05:10:15 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q41CACwr023794; Tue, 1 May 2012 05:10:13 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 05:10:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 05:10:10 -0700 Message-ID: In-Reply-To: <88BF36F4-AF20-433D-A641-86206775C53D@phonefromhere.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Use Case draft Thread-Index: Ac0neWQuOC7dClJqRiCVT7fVSQ/MAQAGWe6A References: <88BF36F4-AF20-433D-A641-86206775C53D@phonefromhere.com> From: "Jim Barnett" To: "Tim Panton" , "Stephan Wenger" X-OriginalArrivalTime: 01 May 2012 12:10:13.0877 (UTC) FILETIME=[5D125250:01CD2793] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 12:10:20 -0000 I work for a contact center call center company, and we are interested in the 1-for-1 replacement case. However, we and our customers, are _much more_ interested in the case including context sharing and web identity, so I think that it should be part of the use case. But an optional part - we would like the scenario to work in the simple PSTN-replacement case as well. Futhermore, even without web context, the ability to include video already gives us something valuable that you can't get with the PSTN. - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Tim Panton Sent: Tuesday, May 01, 2012 5:04 AM To: Stephan Wenger Cc: Randell Jesup; rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft To be a little clearer.=20 If what the use case describes is a 1-for-1 replacement of an (0)800 number with a rtcWeb call, (no context share, no leveraging of web identity) into a standard current call center. I don't think that this case is worthwhile to add. If the usecase describes how context sharing, web identity might be used in a call center scenario - I'm all for it.=20 All I am saying is that if rtcWeb doesn't add any user benefits over (0)800 then, based on my experience, almost no one will use it. So we should not allow the like-for-like replacement case to unduly set requirements T. On 30 Apr 2012, at 23:27, Stephan Wenger wrote: > Hi Randell, > I don't buy this argument. > Speakers are a standard piece of equipment now; almost everyone with a > PC has them in some form. Without a webcam, webrtc would be pretty=20 > useless, and every webcam nowadays has a microphone. > I have no reason to distrust Tim's assessment, but the reason for the=20 > lack of success of PC facilitated sales doers you cited, IMO, cannot=20 > be the main reason, and certainly not among the expected users of=20 > webrtc (who WILL have speakers, camera and mic set up, ready to go,=20 > and used to make calls from their machine). And if your argument=20 > refers to the call center site--well, those guys will get their=20 > equipment right and train their employees, or go out of business. > Lets not dismiss a use case based on short term observations. > Stephan >=20 > On 4.30.2012 23:09 , "Randell Jesup" wrote: >=20 >> On 4/30/2012 9:54 AM, Tim Panton wrote: >>>=20 >>> On 30 Apr 2012, at 09:42, Ravindran, Parthasarathi wrote: >>=20 >>>> My experience is different. Click-to-call is attractive in case of=20 >>>> toll-free number in the site. WebRTC provides complete free call=20 >>>> without any toll. >>>=20 >>> I can't tell you the actual numbers, but when presented with the=20 >>> choice of calling a toll free number or clicking a button marked=20 >>> "free internet call" - almost no-one on a real, busy site clicked=20 >>> the button. >>> ( for every button click there were several orders of magnitude more >>> 0800 calls from that page). >>>=20 >>>=20 >>> So from my perspective this is a legacy interop use case with almost >>> zero user acceptance. >>=20 >> How many people browsing have mic, speakers, or headphones, set up,=20 >> and are comfortable with it? >>=20 >> Things are changing, but a friend who consults for non-tech small=20 >> businesspeople and individual home-based businesses avoids using=20 >> audio when doing screen-share type stuff and instead starts a=20 >> parallel audio POTS call, because it's too frequently a waste of time >> for them to find and set up headphones, get their mic to work. >>=20 >> If it's people who are already using Skype/etc, there's a better=20 >> chance >> - but they still may only be comfortable with Skype for "calls". >>=20 >>=20 >> -- >> Randell Jesup >> randell-ietf@jesup.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From marshall.eubanks@gmail.com Tue May 1 05:33:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8421E8179 for ; Tue, 1 May 2012 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, 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 w8Z9yV-tAX0a for ; Tue, 1 May 2012 05:33:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D79E21E8198 for ; Tue, 1 May 2012 05:33:01 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so82843lbb.31 for ; Tue, 01 May 2012 05:33:00 -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=3laG949M3OeY2MsgMUBSnZE2z54vTObIGJ0pvBHMCF8=; b=kW8S/UvAtRcBRt/YQItNfVQafJfwkM4SqOZ3OwhpWDFI0tu3KWzwodu1CYOUVReQdw bYHcmTpnw5GXj1oDvS555kKERdPtb4eqI2Ra5Ds+5k9WiKRAgd2adjctfGKAVVY0f+30 2gZfcldho4n5tUrLPdVqi6PuNRBqq5ofml1kKo/CWT5ZZyKv7KK5QG3v1nSbksl6yI+i DwrNoWCpgyYzHuxnHjaAk5w2XWp2SU9xGy/6O2AG9zViYsJ9gWn+KV9VckBb+bmpa5xg JmM0FqToVvwcCvWiUo+4H9Mv7Fl3+NayQg+CtJhCyEdJ2iz0R+0gx2D/qp27aLa3crFH Z+BA== MIME-Version: 1.0 Received: by 10.112.98.162 with SMTP id ej2mr12393887lbb.98.1335875580805; Tue, 01 May 2012 05:33:00 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Tue, 1 May 2012 05:33:00 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> Date: Tue, 1 May 2012 08:33:00 -0400 Message-ID: From: Marshall Eubanks To: Jim Barnett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 12:33:04 -0000 Dear Jim; I think that we are mostly in agreement here. One point. On Tue, May 1, 2012 at 8:05 AM, Jim Barnett wr= ote: > One way to describe the use case is to let the contact center's media ser= ver/gateway serve as the webRTC endpoint. =A0Then all the issues of call de= livery, call monitoring, etc. disappear. =A0They are handled by application= software that sits behind the webRTC endpoint. =A0The company I work for m= akes a good living selling software that deals with all these issues - incl= uding bathroom breaks - and that's how we would tend to think of this case.= =A0To us, it's a new kind of call/connection coming into the contact cente= r, which we translate into SIP at the border and then handle normally. > > It's not clear to me if this use case adds any extra requirements. =A0We = would just have to be careful not to assume that a webRTC endpoint is alway= s a person/browser-based user agent. =A0It may seem a bit unsettling that t= he webRTC endpoint can distribute the call somewhere =A0else and let others= listen in, but as far as I can tell that is already the case. =A0If Bob ca= lls Alice with full authentication and security, he can be sure that he is = connected to Alice's user agent and that no one in between can listen in, b= ut there's nothing stopping Alice from recording the audio, or forwarding i= t to a third party. =A0So Bob could in fact be talking to Mary if that's ho= w Alice wants to arrange things (_behind_ her user agent). =A0In general, B= ob is assured only that he is talking to someone Alice wants him to talk to= , and that no one can snoop without Alice's permission. =A0That's very much= the way things work with the call center - you are sure that you are 1) co= nnected securely to your bank 2) talking to someone that the bank wants you= to talk to 3) being recorded or snooped on only when the bank explicitly c= hooses to do so. The slight difference here is that if I call Alice at home, I have end to end security (encryption) to Alice and the call only gets recorded or snooped from her machine. That may not be sufficient in the distributed call center case - the "supervisor" needs to be able to monitor _without the cooperation of either end user_. The threat model is Alice (on the inside) and Eve (on the outside) are in cahoots on some bad deed and want to cover their tracks. The call monitoring should be done outside of Alice's sphere of influence. Say Alice is working in a SOHO and is alone some of the time. Monitoring / recording shouldn't rely on any of the equipment under her potential control, which means it should occur in route, which means you probably won't really have end to end encryption in this case. Regards Marshall > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Marshall Eubanks > Sent: Monday, April 30, 2012 11:42 PM > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Use Case draft > > On Mon, Apr 30, 2012 at 2:31 PM, Hutton, Andrew wrote: >> Whether anybody has been successful in the past with this type of use >> case is I think irrelevant. >> >> >> >> The enterprise call centre use case is I think a vital use case >> because it is a scenario in which one user is only concerned that they >> can securely reach an organization/domain and is not concerned about >> the individual within that domain=A0 that they communicate with.=A0 A >> suspect quite a large percentage of RTCWEB applications will be like >> this and it is not covered in the current use case draft. > > I agree that this is a very useful use case and one I think is going to g= et a lot of traction. There is a very solid business case for this. =A0Howe= ver, I have a fair amount of experience with a video call center for a clie= nt, and it is not as simple as it might seem. > > The essence of course is that you get the next available person, i.e., it= is anycast. Determining who the next available person is is not trivial, n= or is error recovery. (If I call you, and you don't answer or the call drop= s or whatever, =A0I can leave a message or try later. If I call a help desk= , and this happens, I want a new agent, ideally > automatically.) Call forwarding (e.g., first tier to second tier technica= l support) is essential, and it may be anycast or directed. > There are also some security oddities =A0- if I am connecting from home, = I may need to authenticate, use a credit card, etc. If I am connecting from= inside a store, and providing in store video technical support is big part= of the market, then the store authenticates me off line and the call reall= y should just be a button push, which implies that the store has previously= authenticated some sort of master session. In addition, unlike most video = calls, in the enterprise call center a supervisor may need to be able to mo= nitor (i.e., watch) a call, and in some circumstances (financial or medical= calls, for example) there will need to be third party recording. I believe= that =A0these details would be different from the typical RTCWEB scenario. > > Also, there will be a temptation to do the anycasting by the techniques u= sed to load balance servers in a data center, but I think that may not be s= ufficient. The call "center" may in fact be spread completely across the pl= anet (daytime support in the US, nighttime support in India, for example) a= nd be on multiple autonomous systems (and even from people's homes), which = gives rise to some of the transport issues NVO3 may face, but without any o= pportunity for packet tagging. Plus, there will complicated rules about who= can be selected next. RTCWEB shouldn't worry about the intricacies of bath= room break policies; these complexities should be dealt with by an enterpri= se-side database, which to me (together with some of the other issues above= ) suggests that this would probably benefit from =A0API support. > > Regards > Marshall > > >> >> >> >> So I think we need it. >> >> >> >> Regards >> >> Andy >> >> >> >> >> >> >> >> >> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Igor Faynberg >> Sent: 30 April 2012 17:41 >> To: rtcweb@ietf.org >> >> >> Subject: Re: [rtcweb] Use Case draft >> >> >> >> Without numbers it is impossible to argue, but, if we talk about the >> perceived need, I disagree.=A0 Think of the people who travel abroad and >> cannot call the 800 number. (I routinely use Web interface for calls >> when >> traveling.) >> >> >> >> I am all for=A0 the use case, as described by Jim. >> >> Igor >> >> On 4/30/2012 9:54 AM, Tim Panton wrote: >> >> ... >> >> I can't tell you the actual numbers, but when presented with the >> choice of calling a toll free number >> >> or clicking a button marked "free internet call" - almost no-one on a >> real, busy site clicked the button. >> >> ( for every button click there were several orders of magnitude more >> 0800 calls from that page). >> >> >> >> >> >> So from my perspective this is a legacy interop use case with almost >> zero user acceptance. >> >> >> >> (as far as I can see no-one has made this use-case desirable in >> practice >> yet.) >> >> Tim. >> >> >> >> >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Tue May 1 06:14:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A383721E80C8 for ; Tue, 1 May 2012 06:14:22 -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 5CyzuUryrlgx for ; Tue, 1 May 2012 06:14:21 -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 93D4C21E8053 for ; Tue, 1 May 2012 06:14:21 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4B57323F04A8; Tue, 1 May 2012 15:14:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 1 May 2012 15:14:20 +0200 From: "Hutton, Andrew" To: Ted Hardie , "rtcweb@ietf.org" Date: Tue, 1 May 2012 15:14:18 +0200 Thread-Topic: [rtcweb] Use Case draft - Eavesdropping. Thread-Index: Ac0kkPiuwYinP6GjTFWYkg4o1GLBJQDCjZYg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> 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 Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:14:22 -0000 Hi, A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements-0= 7 contain the statement "It is essential that the communication cannot be e= avesdropped" however there is no definition of what is actually meant by "e= avesdropped" although I think we all have an idea of what it means. Maybe it would be better to replace these statements with something that re= fers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of= wiretapping. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ted Hardie > Sent: 27 April 2012 17:15 > To: rtcweb@ietf.org > Subject: [rtcweb] Use Case draft >=20 > The chairs would like to ask the working group to focus on the use > case draft. If you have use cases that need to be added to the > document or text changes you'd like to suggest, please send them in > for discussion before May 15th. After this round, we will look toward > having a working group last call on the document (hopefully before the > interim meeting). >=20 > regards, >=20 > Ted, Magnus, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lists@infosecurity.ch Tue May 1 06:26:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40EF21E805F for ; Tue, 1 May 2012 06:26:47 -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 yZmatmyH16aZ for ; Tue, 1 May 2012 06:26:47 -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 325AD21E8053 for ; Tue, 1 May 2012 06:26:46 -0700 (PDT) Received: by werb10 with SMTP id b10so2965543wer.31 for ; Tue, 01 May 2012 06:26:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=gAm/V4hVNpH8ixzOfTgHkZkDJMYZ78GFUAwXl1JcvQ4=; b=dsTpXIa9nYmx950yEvAiASFtpcxt1H2GKS4e2/P9wQBT4jwoBV3SyCtscnz5uZn6Qq Ddm8m5mCqXXrMl9pRo3naQI6sHUd/apKGDGmFP54Izb9oiaaEyssSQBDYWoGig05j1qB rgRHiOHwtknLzdVxKTXMc3+DJzr81G2qgHqmRSOOCxKucYOExUoEkJDkJHEfKr1NTi+b OUEaKiiDwtQPWjWwRM6DU1q31y/iGGrH1bJWn34TlIE8FfEIUIKzadSdHPZVSerCYy9R XwrEBysfEIBPqr6XuWgNIGomHM+silbV4YMSIMzc6orTyg3wgRND7TI5lzRYxNQEilX8 B9Eg== Received: by 10.216.137.22 with SMTP id x22mr1936530wei.69.1335878805797; Tue, 01 May 2012 06:26:45 -0700 (PDT) Received: from sonyvaiop13.local (93-32-132-142.ip33.fastwebnet.it. [93.32.132.142]) by mx.google.com with ESMTPS id ff9sm36428748wib.2.2012.05.01.06.26.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 06:26:44 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4F9FE493.7050501@infosecurity.ch> Date: Tue, 01 May 2012 15:26:43 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnD0xK9iSRmRmqU699GrBqz/8etzj1VHp1QS11D9YgtMlZgkzW3rdXGF0MMzrOYeJKsT4xg Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:26:48 -0000 On 5/1/12 3:14 PM, Hutton, Andrew wrote: > Hi, > > A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements-07 contain the statement "It is essential that the communication cannot be eavesdropped" however there is no definition of what is actually meant by "eavesdropped" although I think we all have an idea of what it means. > > Maybe it would be better to replace these statements with something that refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of wiretapping. That's a core topic imho, especially because WebRTC would like to make it appear like carrying on end-to-end security. If WebRTC provide full end-to-end security no wiretapping should be possible. Because WebRTC, from the discussion done in this mailing lists, cannot satisfy end-to-end security requirements (no wiretapping) in many cases, then it's highly relevant that the user is aware if the connection is secured peer-to-peer (so between the end-user-device of the parties that are talking together) or if there's a gateway in the middle decrypting/deciphering the call, and so potentially eavesdropping it. I think that to avoid a "shame" on the reputation of WebRTC, it's very and highly important to clearly state and explain how/when/who can do eavesdropping. At least to know "when" it's end-to-end security and when it's not, in a clear, unique, identifiable way. Fabio From richard.ejzak@alcatel-lucent.com Tue May 1 06:57:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9619B21E82C5 for ; Tue, 1 May 2012 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 nnacU6B7fEhg for ; Tue, 1 May 2012 06:57:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D59D621E82BB for ; Tue, 1 May 2012 06:57:45 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q41DvhO7025831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 08:57:43 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q41DvghR023631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 May 2012 08:57:43 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 1 May 2012 08:57:42 -0500 From: "Ejzak, Richard P (Richard)" To: Justin Uberti , "Nataraju A.B" Date: Tue, 1 May 2012 08:57:40 -0500 Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0nRUzcKWbc33ZVRO+KqwMZL0Xe+QAWQKOQ Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.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_6F428EFD2B8C2F49A2FB1317291A76C1136029362AUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:57:48 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C1136029362AUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Justin, Partha, The call flow from Partha is a very reasonable one in the presence of SIP f= orking. Let's assume that a first target responded with an SDP answer in a= 183 that must be treated as a PRANSWER since other targets have not yet ha= d a chance to respond. Then the first target sends an UPDATE with offer2. As far as SIP is concerned, there is no such thing as a PRANSWER. The firs= t target already responded with an SDP ANSWER and wants to UPDATE with a ne= w offer. This is perfectly legitimate and common SIP usage. PRANSWER is a= local construct that should be usable by the application to support more c= omplex offer/answer cases like forking. You must respond to this offer by cloning the peer connection, closing the = clone with an ANSWER identical to the previous PRANSWER and then applying o= ffer2 to the clone (or just applying the offer2 directly with the understan= ding that the previous transaction is closed). The original peer connectio= n must revert to the original OFFER state to allow for other targets to res= pond. Alternately, the original peer connection can support the first target and = a new clone created if there is the potential for other forked responses to= the original offer. Either way can be made to work. This is a perfectly reasonable SIP use case that explains why we need to be= able to clone the peer connection. Richard ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Justin Uberti Sent: Monday, April 30, 2012 9:51 PM To: Nataraju A.B Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Yes, I was under the impression that SIP enforced this requirement, althoug= h I am probably not aware of all the corner cases. Is there a real-world sc= enario where this flow is required? On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B > wrote: If the scenario considered is without reliable provisional responses. Then = the first ANSWER must be in 200-INV and no more O/A allowed during INVITE(i= nitial) transaction. Basic requirement for reliable and unambiguous O/A is - At any point in tim= e there could be only one O/A open. Also only one O/A suggested during INVITE(initial) transaction. For reference, rfc6337, list outs different O/A models... Offer Answer RFC Ini Est Early ------------------------------------------------------------------- 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y Table 1: Summary of SIP Usage of the Offer/Answer Model Thanks, Nataraju A B On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi > wrote: Justin/Cullen, Could you please explain in case for an SDP_OFFER(1), the remote entity rep= lies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the expected b= ehavior. The exact callflow is as follows: Browser1-------------------------Browser2(SIP-JSEP gateway) | SDP_OFFER(1) | INV with offer1 |------------------------------->|---> | SDP_PRANSWER(1) | 183 with answer1 |<-------------------------------|<--- | SDP_OFFER(2) | UPDATE with offer2 |<-------------------------------|<--- | SDP_ANSWER(2?) | |--------------------->? The reason for this O/A callflow is due to UPDATE method (RFC 3311) mapping= in Browser 2 (SIP-JSEP gateway). Thanks Partha PS: For simplicity, PRACK message exchange is not chosen in SIP side. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Thanks, Nataraju A.B. --_000_6F428EFD2B8C2F49A2FB1317291A76C1136029362AUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Justin, Partha,

The call flow from Partha is a very reasonable one in the presence of SIP forking.  Let’s assume tha= t a first target responded with an SDP answer in a 183 that must be treated as = a PRANSWER since other targets have not yet had a chance to respond.  Th= en the first target sends an UPDATE with offer2.

 

As far as SIP is concerned, there is n= o such thing as a PRANSWER.  The first target already responded with an = SDP ANSWER and wants to UPDATE with a new offer.  This is perfectly legiti= mate and common SIP usage.  PRANSWER is a local construct that should be us= able by the application to support more complex offer/answer cases like forking.=

 

You must respond to this offer by clon= ing the peer connection, closing the clone with an ANSWER identical to the prev= ious PRANSWER and then applying offer2 to the clone (or just applying the offer2 directly with the understanding that the previous transaction is closed). &= nbsp;The original peer connection must revert to the original OFFER state to allow f= or other targets to respond.

 

Alternately, the original peer connect= ion can support the first target and a new clone created if there is the potent= ial for other forked responses to the original offer.  Either way can be made = to work.

 

This is a perfectly reasonable SIP use case that explains why we need to be able to clone the peer connection.

 

Richard

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, April 30, 2012= 9:51 PM
To: Nataraju A.B
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PR= ANSWER followed by SDP_OFFER scenario in JSEP

 

Yes, I was under = the impression that SIP enforced this requirement, although I am probably not a= ware of all the corner cases. Is there a real-world scenario where this flow is required?

On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B <nataraju.sip@gmail= .com> wrote:

If the scenario considered is without reliable provisional response= s. Then the first ANSWER must be in 200-INV and no more O/A allowed during INV= ITE(initial) transaction.

 

Basic requirement for reliable and unambiguous O/A is - At any point in time there could be only one O/= A open. 

 

Also only one O/A suggested during INVITE(initial) transaction= .

 

For reference, rfc6337, list outs different O/A models...

 

<rfc6337>

 
 <=
/o:p>
  =
          Offer  &nb=
sp;            =
 Answer           &n=
bsp; RFC    Ini Est Early
  =    --------------------------------------------------------------= -----
  =
   1. INVITE Req.        =
  2xx INVITE Resp.     RFC 3261  Y  =
; Y    N
  =
   2. 2xx INVITE Resp.     ACK Req. &nbs=
p;           RFC 3261&nbs=
p; Y   Y    N
<=
font
size=3D2 face=3D"Courier New">  =
   3. INVITE Req.        =
  1xx-rel INVITE Resp. RFC 3262  Y   Y   =
; N
  =
   4. 1xx-rel INVITE Resp. PRACK Req.    &nbs=
p;      RFC 3262  Y   Y  =
  N
  =
   5. PRACK Req.        &=
nbsp;  200 PRACK Resp.      RFC 3262  N&=
nbsp;  Y    Y
  =
   6. UPDATE Req.        =
  2xx UPDATE Resp.     RFC 3311  N  =
; Y    Y
 <=
/o:p>
  =
        Table 1: Summary of SIP Usage of=
 the Offer/Answer Model 

</rfc6337>

 

Thanks,

Nataraju A B

 

On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi <pravindran@sonusn= et.com> wrote:

Justin/Cullen,
Could you please explain in case for an SDP_OFFER(1), the remote entity rep= lies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the expected behavi= or. The exact callflow is as follows:


Browser1-------------------------Browser2(SIP-JSEP gateway)
   |        SDP_OFFER(1)            |  INV with offer1
   |------------------------------->|--->
   |       SDP_PRANSWER(1)       &n= bsp;  |  183 with answer1
   |<-------------------------------|<---
   |       SDP_OFFER(2)        = ;     |   UPDATE with offer2
   |<-------------------------------|<---
   |       SDP_ANSWER(2?)       &nb= sp;   |
   |--------------------->?

The reason for this O/A callflow is due to UPDATE method (RFC 3311) mapping= in Browser 2 (SIP-JSEP gateway).

Thanks
Partha

PS: For simplicity, PRACK message exchange is not chosen in SIP side.




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



 

--
Thanks,

Nataraju A.B.=

 

 

--_000_6F428EFD2B8C2F49A2FB1317291A76C1136029362AUSNAVSXCHMBSA_-- From ekr@rtfm.com Tue May 1 07:05:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F0321E8384 for ; Tue, 1 May 2012 07:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MRhCJ6ifbbfv for ; Tue, 1 May 2012 07:05:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDEE621E835A for ; Tue, 1 May 2012 07:05:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3236660vbb.31 for ; Tue, 01 May 2012 07:05:40 -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:content-transfer-encoding :x-gm-message-state; bh=Pb8OYFF5S0Feqe1blQ9N/piZFHBiwuVR6CPDGmvrFz4=; b=fyIJmO4r08t6AKN9e7JSxlqJg32pcm14UiuESssov9xRHONvJj2ZDYA80PugwOAU3X Bigyw9uetBI+artZBwXHsaWNOPmfwO4P5iKGJ/nXP4ks1GDUN1DrZXb39Iv4xaEEEanx ThDGMxIxa6nD4n/Ype51DWHUxSf5sML7+TftYV9Y4N5rGMv+3ulzm6222PJ7HXj9mwOx GcxisPiygYUpTpbP9QY1R8vgxvRcFp1Ua5ZslUrbt3yYUjTaGGdUCmcwZuYZaT915WWR 739w7845ZzDDYvaKBXN7PEXZG7AD7fsbwuHp03SM8mIAq90R20NR9iCs98B/UIV613d4 lpjQ== Received: by 10.220.150.12 with SMTP id w12mr24952001vcv.39.1335881140479; Tue, 01 May 2012 07:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 1 May 2012 07:05:00 -0700 (PDT) X-Originating-IP: [128.107.46.83] In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> From: Eric Rescorla Date: Tue, 1 May 2012 07:05:00 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmPlIdkFiUpXk8upCXiidt4p6GjpOFD7zbA2pSbodiPUus9EN7jbCrVsoJZQ/Ybko6cDf5O Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 14:05:41 -0000 On Tue, May 1, 2012 at 6:14 AM, Hutton, Andrew wrote: > Hi, > > A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements= -07 contain the statement "It is essential that the communication cannot be= eavesdropped" however there is no definition of what is actually meant by = "eavesdropped" although I think we all have an idea of what it means. > > Maybe it would be better to replace these statements with something that = refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition = of wiretapping. This seems like it's creeping into the security requirements question. Rather than try to make the use cases document more precise, I'd prefer to have those statements be in draft-ietf-rtcweb-security, which actually has (or at least is intended to) have fairly precise descriptions of what the relevant security properties are. -Ekr From chris.cavigioli@intel.com Tue May 1 07:14:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0021E83D4 for ; Tue, 1 May 2012 07:14:44 -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 sO+O8+NinKis for ; Tue, 1 May 2012 07:14:43 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0121E83C4 for ; Tue, 1 May 2012 07:14:43 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 01 May 2012 07:14:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="160435679" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga002.fm.intel.com with ESMTP; 01 May 2012 07:14:43 -0700 Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 May 2012 07:14:42 -0700 Received: from orsmsx104.amr.corp.intel.com ([169.254.3.216]) by ORSMSX102.amr.corp.intel.com ([169.254.1.202]) with mapi id 14.01.0355.002; Tue, 1 May 2012 07:14:41 -0700 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Use Case draft - Eavesdropping. Thread-Index: Ac0kkPiuwYinP6GjTFWYkg4o1GLBJQDCjZYgAAI8ByA= Date: Tue, 1 May 2012 14:14:41 +0000 Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 14:14:44 -0000 Wording needs to be clarified. - "Eavesdropping" has a negative connotation of someone inappropriately lis= tening in to another communication. This should not happen. - "Lawful intercept" is something telecom service providers are required to= provide to law enforcement with all appropriate safeguards in place http:/= /en.wikipedia.org/wiki/Lawful_interception=20 -chris -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, May 01, 2012 6:14 AM To: Ted Hardie; rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft - Eavesdropping. Hi, A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements-0= 7 contain the statement "It is essential that the communication cannot be e= avesdropped" however there is no definition of what is actually meant by "e= avesdropped" although I think we all have an idea of what it means. Maybe it would be better to replace these statements with something that re= fers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of= wiretapping. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ted Hardie > Sent: 27 April 2012 17:15 > To: rtcweb@ietf.org > Subject: [rtcweb] Use Case draft >=20 > The chairs would like to ask the working group to focus on the use > case draft. If you have use cases that need to be added to the > document or text changes you'd like to suggest, please send them in > for discussion before May 15th. After this round, we will look toward > having a working group last call on the document (hopefully before the > interim meeting). >=20 > regards, >=20 > Ted, Magnus, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From marshall.eubanks@gmail.com Tue May 1 07:35:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E9B21E808F for ; Tue, 1 May 2012 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, 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 VgXcLtHu8iVM for ; Tue, 1 May 2012 07:35:19 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5C21E808E for ; Tue, 1 May 2012 07:35:18 -0700 (PDT) Received: by lagj5 with SMTP id j5so2825032lag.31 for ; Tue, 01 May 2012 07:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2LGnp4PDB2qclAt6KxDV5muQ/inG9LLjU+1E9OjXKa0=; b=nEz3Vf2wG/vIoV32pDKIY3+s0AjiIQyXOUw+s8VIF0mFJ66nwGPa3ZcLDDb/MJ59Vx xE3PN8PEaTQq8HGjC4LfcHQ1sGmfb2qcm75VybEQcBEFXZEMsKZBPpbQ4tZoFuIMgmje Dit+Sx1g8ED0EMg3Mg3p+Q6BQllKB6GDVhRRHo8IcVUt6riUfs1AhCDNCiUubIV+Tviw R4Z/XGeZ+tqpkUh4jyBQjriGLPoNijWmg5UJK+UppdOXyMPSyvX825u+WkySArJh9qmL MDwfViXvDU/CLdT4Ty2QDwg5cRUTZR0XALMtbJUd2NmkC3VrDh14HeFrSf04uIc6sJSp Q0GQ== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr23284533lab.19.1335882917492; Tue, 01 May 2012 07:35:17 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Tue, 1 May 2012 07:35:17 -0700 (PDT) In-Reply-To: References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> Date: Tue, 1 May 2012 10:35:17 -0400 Message-ID: From: Marshall Eubanks To: "Cavigioli, Chris" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 14:35:20 -0000 On Tue, May 1, 2012 at 10:14 AM, Cavigioli, Chris wrote: > Wording needs to be clarified. > - "Eavesdropping" has a negative connotation of someone inappropriately l= istening in to another communication. =A0This should not happen. > - "Lawful intercept" is something telecom service providers are required = to provide to law enforcement with all appropriate safeguards in place http= ://en.wikipedia.org/wiki/Lawful_interception Lawful intercept is a legal term, which in my opinion the IETF should stay away from. You will go into the weeds amazing fast otherwise. I prefer "monitoring," which can be done for many reasons (see the parallel discussion on enterprise call centers). Regards Marshall > -chris > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Hutton, Andrew > Sent: Tuesday, May 01, 2012 6:14 AM > To: Ted Hardie; rtcweb@ietf.org > Subject: Re: [rtcweb] Use Case draft - Eavesdropping. > > Hi, > > A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements= -07 contain the statement "It is essential that the communication cannot be= eavesdropped" however there is no definition of what is actually meant by = "eavesdropped" although I think we all have an idea of what it means. > > Maybe it would be better to replace these statements with something that = refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition = of wiretapping. > > Regards > Andy > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Ted Hardie >> Sent: 27 April 2012 17:15 >> To: rtcweb@ietf.org >> Subject: [rtcweb] Use Case draft >> >> The chairs would like to ask the working group to focus on the use >> case draft. =A0If you have use cases that need to be added to the >> document or text changes you'd like to suggest, please send them in >> for discussion before May 15th. =A0After this round, we will look toward >> having a working group last call on the document (hopefully before the >> interim meeting). >> >> regards, >> >> Ted, Magnus, Cullen >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Tue May 1 08:57:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ACA21E813B for ; Tue, 1 May 2012 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 IggxXLy5HJCs for ; Tue, 1 May 2012 08:57:10 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5382021E8134 for ; Tue, 1 May 2012 08:57:10 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SPFRt-0004ko-Fr for rtcweb@ietf.org; Tue, 01 May 2012 10:57:09 -0500 Message-ID: <4FA0079B.3080609@jesup.org> Date: Tue, 01 May 2012 11:56:11 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F9ACCC9.2040508@mozilla.com> <4F9E7A7E.1020600@ericsson.com> <4F9EFD60.6000809@jesup.org> <4F9F6F4C.5060902@ericsson.com> In-Reply-To: <4F9F6F4C.5060902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:57:10 -0000 On 5/1/2012 1:06 AM, Stefan Hakansson LK wrote: > On 04/30/2012 11:00 PM, Randell Jesup wrote: >> The game case can need both reliable and unreliable data at the same >> time, which gets us reliable, unreliable and multiple streams. > > You're right; but currently only game state updates is mentioned. > Probably that use case should be updated. Game state updates for a real online game can involve both reliable and unreliable data. Some state can be out-of-date (player positions, visual state issues (lighting), etc) and the game will extrapolate positions; others (global critical state (live, dead, etc)) must be reliable. -- Randell Jesup randell-ietf@jesup.org From nataraju.sip@gmail.com Tue May 1 09:12:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA46F21E8271 for ; Tue, 1 May 2012 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 TavW1DworgcK for ; Tue, 1 May 2012 09:12:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0428721E8134 for ; Tue, 1 May 2012 09:12:29 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so222181lbb.31 for ; Tue, 01 May 2012 09: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=DzGPA8p+hYETaxUJJCL20Qr1JrSAJBJJVXavAsFvYNo=; b=ksElVXGkmquue4O8nc7rlwiZnlP+ePUr7cpqwRSyFPomkdDu/pwcyBTYVOkwAHoDu7 HbAMTJhwGsT8DXfmZ+fEMPPcJiFOhG9QyloKsE1+AibwVW5xrh820zhCHKd0nXHz5Ug1 0uazmJvYTTiEJphadLajH4chH0OlB+Wc0zxwHqdarQ9OPJxtz6jTMAI4gPHyE9NUvHrk ar9E/ZYZY6K/UAtR7Y5V0V1U+0lV2gc1rCG+fndydSlf+oX+3LRfU3awcyNNOog8tFV9 9Ri7F+yIrRxxk8tCGPuR/mfVzTQS/R46t+Q8Wb3kd1SpDZ65wwMJIH4iWAomeSR4yL1W 9uMw== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr23544740lab.19.1335888748739; Tue, 01 May 2012 09:12:28 -0700 (PDT) Received: by 10.112.86.129 with HTTP; Tue, 1 May 2012 09:12:28 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 1 May 2012 21:42:28 +0530 Message-ID: From: "Nataraju A.B" To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=f46d0407152953fddc04befbd608 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:12:31 -0000 --f46d0407152953fddc04befbd608 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The original scenario mentioned by Partha is quite logical and acceptable, since there is only one O/A open all the times. If not handled properly, this additional UPDATE (with OFFER2) during the lifetime of INVITE transaction lead to ambiguities. Hence rfc6337, don't support this as a valid O/A. On Tue, May 1, 2012 at 7:27 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Hi Justin, Partha,**** > > The call flow from Partha is a very reasonable one in the presence of SIP > forking. Let=92s assume that a first target responded with an SDP answer= in > a 183 that must be treated as a PRANSWER since other targets have not yet > had a chance to respond. Then the first target sends an UPDATE with offe= r2. > **** > > ** ** > > As far as SIP is concerned, there is no such thing as a PRANSWER. The > first target already responded with an SDP ANSWER and wants to UPDATE wit= h > a new offer. This is perfectly legitimate and common SIP usage. PRANSWE= R > is a local construct that should be usable by the application to support > more complex offer/answer cases like forking.**** > > ** ** > > You must respond to this offer by cloning the peer connection, closing th= e > clone with an ANSWER identical to the previous PRANSWER and then applying > offer2 to the clone (or just applying the offer2 directly with the > understanding that the previous transaction is closed). The original pee= r > connection must revert to the original OFFER state to allow for other > targets to respond.**** > > ** ** > > Alternately, the original peer connection can support the first target an= d > a new clone created if there is the potential for other forked responses = to > the original offer. Either way can be made to work.**** > > ** ** > > This is a perfectly reasonable SIP use case that explains why we need to > be able to clone the peer connection.**** > > ** ** > > Richard**** > > ** ** > ------------------------------ > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Monday, April 30, 2012 9:51 PM > *To:* Nataraju A.B > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in > JSEP**** > > ** ** > > Yes, I was under the impression that SIP enforced this requirement, > although I am probably not aware of all the corner cases. Is there a > real-world scenario where this flow is required?**** > > On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B > wrote:**** > > If the scenario considered is without reliable provisional responses. The= n > the first ANSWER must be in 200-INV and no more O/A allowed during > INVITE(initial) transaction.**** > > ** ** > > Basic requirement for reliable and unambiguous O/A is -* At any point in > time there could be only one O/A open. ***** > > ** ** > > Also only one O/A suggested during INVITE(initial) transaction.**** > > ** ** > > For reference, rfc6337, list outs different O/A models...**** > > ** ** > > **** > > ** ** > > ** ** > > Offer Answer RFC Ini Est Early*= *** > > -------------------------------------------------------------------*= *** > > 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N***= * > > 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N***= * > > 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N***= * > > 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N***= * > > 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y***= * > > 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y***= * > > ** ** > > Table 1: Summary of SIP Usage of the Offer/Answer Model **** > > **** > > ** ** > > Thanks,**** > > Nataraju A B**** > > ** ** > > On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Justin/Cullen, > > Could you please explain in case for an SDP_OFFER(1), the remote entity > replies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the > expected behavior. The exact callflow is as follows: > > > Browser1-------------------------Browser2(SIP-JSEP gateway) > | SDP_OFFER(1) | INV with offer1 > |------------------------------->|---> > | SDP_PRANSWER(1) | 183 with answer1 > |<-------------------------------|<--- > | SDP_OFFER(2) | UPDATE with offer2 > |<-------------------------------|<--- > | SDP_ANSWER(2?) | > |--------------------->? > > The reason for this O/A callflow is due to UPDATE method (RFC 3311) > mapping in Browser 2 (SIP-JSEP gateway). > > Thanks > Partha > > PS: For simplicity, PRACK message exchange is not chosen in SIP side. > > > > > **** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > > > **** > > ** ** > > -- > Thanks,**** > > Nataraju A.B.**** > > ** ** > > ** ** > --=20 Thanks, Nataraju A.B. --f46d0407152953fddc04befbd608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The original scenario mentioned by Partha is quite logical and acceptable, = since there is only one O/A open all the times.

If not h= andled properly, this additional UPDATE (with OFFER2) during the lifetime o= f INVITE transaction lead to ambiguities. Hence=A0rfc6337,=A0don't supp= ort this as a valid O/A.

On Tue, May 1, 2012 at 7:27 PM, Ejzak, = Richard P (Richard) <richard.ejzak@alcatel-lucent.com&g= t; wrote:

Hi Justin, Partha,<= /u>

The call flow from Partha is = a very reasonable one in the presence of SIP forking. =A0Let=92s assume that a first target responded with an SDP answer in a 183 that must be treated as = a PRANSWER since other targets have not yet had a chance to respond.=A0 Then the first target sends an UPDATE with offer2.

=A0

As far as SIP is concerned, t= here is no such thing as a PRANSWER. =A0The first target already responded with an SDP ANSWER and wants to UPDATE with a new offer. =A0This is perfectly legitimat= e and common SIP usage.=A0 PRANSWER is a local construct that should be usabl= e by the application to support more complex offer/answer cases like forking.=

=A0

You must respond to this offe= r by cloning the peer connection, closing the clone with an ANSWER identical to the prev= ious PRANSWER and then applying offer2 to the clone (or just applying the offer2 directly with the understanding that the previous transaction is closed). = =A0The original peer connection must revert to the original OFFER state to allow f= or other targets to respond.

=A0

Alternately, the original pee= r connection can support the first target and a new clone created if there is the potent= ial for other forked responses to the original offer. =A0Either way can be made to work.

=A0

This is a perfectly reasonabl= e SIP use case that explains why we need to be able to clone the peer connection.<= /u>

=A0

Richard<= /font>

=A0

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On= Behalf Of Justin Uberti
Sent: Monday, April 30, 2012= 9:51 PM
To: Nataraju A.B
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PR= ANSWER followed by SDP_OFFER scenario in JSEP

=A0

Yes, I was under the impression that SIP enforced this requirement, although I am probably not a= ware of all the corner cases. Is there a real-world scenario where this flow is required?

On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B <<= a href=3D"mailto:nataraju.sip@gmail.com" target=3D"_blank">nataraju.sip@gma= il.com> wrote:

If the scenario considered is without reliable provi= sional responses. Then the first ANSWER must be in 200-INV and no more O/A allowed during INV= ITE(initial) transaction.

=A0

Basic requirement for reliable and unambiguous O/A i= s - At any point in time there could be= only one O/A open.=A0

=A0

Also only one O/A suggested during INVITE(initial)= =A0transaction.

=A0

For reference, rfc6337, list outs different O/A mode= ls...

=A0

<rfc6337>

=A0
<=
u>=A0
=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 Offer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Answer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC=A0=A0=A0 Ini Est Early
=A0=A0=A0=A0 -------------------------------------------=
------------------------
=A0=A0=A0=
=A0 1. INVITE Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0 2xx INVITE Resp.=A0=A0=A0=A0 =
RFC 3261=A0 Y=A0=A0 Y=A0=A0=A0 N
=A0=A0=A0=A0 2. 2xx=
 INVITE Resp.=A0=A0=A0=A0 ACK Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC =
3261=A0 Y=A0=A0 Y=A0=A0=A0 N
=A0=A0=A0=
=A0 3. INVITE Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0 1xx-rel INVITE Resp. RFC 3262=
=A0 Y=A0=A0 Y=A0=A0=A0 N
=A0=A0=A0=A0 4. 1xx-rel I=
NVITE Resp. PRACK Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC 3262=A0 Y=A0=A0 Y=
=A0=A0=A0 N
=A0=A0=A0=
=A0 5. PRACK Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 200 PRACK Resp.=A0=A0=A0=A0=
=A0 RFC 3262=A0 N=A0=A0 Y=A0=A0=A0 Y
=
=A0=A0=A0=A0 6.=
 UPDATE Req.=A0=A0=A0=A0=A0=A0=A0=A0=A0 2xx UPDATE Resp.=A0=A0=A0=A0 RFC 33=
11=A0 N=A0=A0 Y=A0=A0=A0 Y
=A0=

=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 1: Summary of SIP Usage =
of the Offer/Answer Model=A0

</rfc6337>

=A0

Thanks,

Nataraju A B

=A0

On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthas= arathi <pra= vindran@sonusnet.com> wrote:

Justin/Cullen,

Could you please explain in case for an SDP_OFFER(1), the remote entity rep= lies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the expected behavi= or. The exact callflow is as follows:


Browser1-------------------------Browser2(SIP-JSEP gateway)
=A0 =A0| =A0 =A0 =A0 =A0SDP_OFFER(1) =A0 =A0 =A0 =A0 =A0 =A0| =A0INV with offer1
=A0 =A0|------------------------------->|--->
=A0 =A0| =A0 =A0 =A0 SDP_PRANSWER(1) =A0 =A0 =A0 =A0 =A0| =A0183 with answer1
=A0 =A0|<-------------------------------|<---
=A0 =A0| =A0 =A0 =A0 SDP_OFFER(2) =A0 =A0 =A0 =A0 =A0 =A0 | =A0 UPDATE with offer2
=A0 =A0|<-------------------------------|<---
=A0 =A0| =A0 =A0 =A0 SDP_ANSWER(2?) =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|--------------------->?

The reason for this O/A callflow is due to UPDATE method (RFC 3311) mapping= in Browser 2 (SIP-JSEP gateway).

Thanks
Partha

PS: For simplicity, PRACK message exchange is not chosen in SIP side.




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



=A0

--
Thanks,= =

Natar= aju A.B.

=A0

=A0




--
Tha= nks,
Nataraju A.B.

--f46d0407152953fddc04befbd608-- From randell-ietf@jesup.org Tue May 1 09:23:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE52421E81FF for ; Tue, 1 May 2012 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 gUBvVLILAkLo for ; Tue, 1 May 2012 09:23:39 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E45F021E8152 for ; Tue, 1 May 2012 09:23:38 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SPFrW-0005yc-Ju for rtcweb@ietf.org; Tue, 01 May 2012 11:23:38 -0500 Message-ID: <4FA00DD0.1030600@jesup.org> Date: Tue, 01 May 2012 12:22:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:23:39 -0000 On 5/1/2012 10:35 AM, Marshall Eubanks wrote: > On Tue, May 1, 2012 at 10:14 AM, Cavigioli, Chris > wrote: >> Wording needs to be clarified. >> - "Eavesdropping" has a negative connotation of someone inappropriately listening in to another communication. This should not happen. >> - "Lawful intercept" is something telecom service providers are required to provide to law enforcement with all appropriate safeguards in place http://en.wikipedia.org/wiki/Lawful_interception > > Lawful intercept is a legal term, which in my opinion the IETF should > stay away from. You will go into the weeds amazing fast otherwise. > > I prefer "monitoring," which can be done for many reasons (see the > parallel discussion on enterprise call centers). I'm fine with discussing call center monitoring, and believe the authentication should be to "Key Bank" or "Key Bank Customer Service", not to "station 27 Boise Key Bank Call Center", which implies the WebRTC connection would terminate at the call center 'PBX'-equivalent and then have media (etc) routed (even via a second WebRTC connection) to the agent. This means monitoring (and for financial firms, legally-required logging, etc) can occur via the PBX-equivalent (aka WebRTC Proxy). We have explicitly avoided discussion of "Lawful intercept", which would involve complex (changing) legal requirements from every major jurisdiction, and we should continue to avoid wrestling with that python. :-) -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Tue May 1 22:33:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AD21F8934 for ; Tue, 1 May 2012 22:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, 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 f88+ztubUMPL for ; Tue, 1 May 2012 22:33:30 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9F21F8925 for ; Tue, 1 May 2012 22:33:29 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT6DHKLz7igVmBBhNORPbC4bZMON/lqqJ@postini.com; Tue, 01 May 2012 22:33:29 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 May 2012 01:33:33 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 2 May 2012 11:02:58 +0530 From: "Ravindran, Parthasarathi" To: Nataraju A.B , "Ejzak, Richard P (Richard)" , Justin Uberti Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewALSsOAABK1rwAAF0kPAAAEtTUAACaRZ4A= Date: Wed, 2 May 2012 05:32:01 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23B519@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.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: [10.70.54.41] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E23B519inbamail01sonus_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 05:33:34 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E23B519inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nataraju, RFC 6337 supports early dialog UPDATE scenario which I mentioned in this ma= il. The exact RFC snippet with "Early column" explanation. Offer Answer RFC Ini Est Early ------------------------------------------------------------------- 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y The 'Early' column indicates which patterns may be used to modify the established session in an early dialog. There are two ways to exchange a subsequent offer/answer in an early dialog. Here, UPDATE MUST not be used for initiating the session but it shall be us= ed in the early dialog. AFAIK, UPDATE With SDP is mostly useful in early-dialog as RE-INVITE with S= DP is possible in the mid-dialog ("Est") Justin, Richard provided some of the usecase using forked responses. This usecase = is not the corner case and it is very normal scenario in SIP O/A. I'll add further usecase fo= r this scenario: One of the main usecase of UPDATE with SDP in the early dialog is remote ri= ngback tone (RRBT) from media server Usecase. Multiple scenario involved in this usecase: 1) First usecase, the first offer/answer is completed between Origina= ting endpoint and media server, UPDATE with second offer is sent towards Originating = endpoint to update SDP with terminating Endpoint. 2) Second usecase, the first offer/answer is completed with direction = attribute as Sendonly in the answer by which early dialog is only for remote ringback to= ne and not actual session establishment. second offer in UPDATE is updated the direct= ion attribute as "sendrecv". 3) Combination of First and second usecase wherein media server answer= with sendonly, UPDATE with SDP for "sendrecv". Common Topology: Originating Browser--------------Gateway---------SoftSwitch/PBX(B2BUA)-------SIP UA (Me= dia Server/IVR) = | = -------------------SIP UA (IP phone) RFC 6337 has lot of other corner scenario. Could you please let me know how= to map the second OFFER and in PRANSWER state of the Originating endpoint (webbrowser in JSEP= ). In case JSEP O/A is based on OFFER & ANSWER states only, this scenario will= not hit. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Nataraju A.B Sent: Tuesday, May 01, 2012 9:42 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP The original scenario mentioned by Partha is quite logical and acceptable, = since there is only one O/A open all the times. If not handled properly, this additional UPDATE (with OFFER2) during the li= fetime of INVITE transaction lead to ambiguities. Hence rfc6337, don't supp= ort this as a valid O/A. On Tue, May 1, 2012 at 7:27 PM, Ejzak, Richard P (Richard) > wrote: Hi Justin, Partha, The call flow from Partha is a very reasonable one in the presence of SIP f= orking. Let's assume that a first target responded with an SDP answer in a= 183 that must be treated as a PRANSWER since other targets have not yet ha= d a chance to respond. Then the first target sends an UPDATE with offer2. As far as SIP is concerned, there is no such thing as a PRANSWER. The firs= t target already responded with an SDP ANSWER and wants to UPDATE with a ne= w offer. This is perfectly legitimate and common SIP usage. PRANSWER is a= local construct that should be usable by the application to support more c= omplex offer/answer cases like forking. You must respond to this offer by cloning the peer connection, closing the = clone with an ANSWER identical to the previous PRANSWER and then applying o= ffer2 to the clone (or just applying the offer2 directly with the understan= ding that the previous transaction is closed). The original peer connectio= n must revert to the original OFFER state to allow for other targets to res= pond. Alternately, the original peer connection can support the first target and = a new clone created if there is the potential for other forked responses to= the original offer. Either way can be made to work. This is a perfectly reasonable SIP use case that explains why we need to be= able to clone the peer connection. Richard ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Justin Ube= rti Sent: Monday, April 30, 2012 9:51 PM To: Nataraju A.B Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Yes, I was under the impression that SIP enforced this requirement, althoug= h I am probably not aware of all the corner cases. Is there a real-world sc= enario where this flow is required? On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B > wrote: If the scenario considered is without reliable provisional responses. Then = the first ANSWER must be in 200-INV and no more O/A allowed during INVITE(i= nitial) transaction. Basic requirement for reliable and unambiguous O/A is - At any point in tim= e there could be only one O/A open. Also only one O/A suggested during INVITE(initial) transaction. For reference, rfc6337, list outs different O/A models... Offer Answer RFC Ini Est Early ------------------------------------------------------------------- 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y Table 1: Summary of SIP Usage of the Offer/Answer Model Thanks, Nataraju A B On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi > wrote: Justin/Cullen, Could you please explain in case for an SDP_OFFER(1), the remote entity rep= lies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the expected b= ehavior. The exact callflow is as follows: Browser1-------------------------Browser2(SIP-JSEP gateway) | SDP_OFFER(1) | INV with offer1 |------------------------------->|---> | SDP_PRANSWER(1) | 183 with answer1 |<-------------------------------|<--- | SDP_OFFER(2) | UPDATE with offer2 |<-------------------------------|<--- | SDP_ANSWER(2?) | |--------------------->? The reason for this O/A callflow is due to UPDATE method (RFC 3311) mapping= in Browser 2 (SIP-JSEP gateway). Thanks Partha PS: For simplicity, PRACK message exchange is not chosen in SIP side. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Thanks, Nataraju A.B. -- Thanks, Nataraju A.B. --_000_387F9047F55E8C42850AD6B3A7A03C6C0E23B519inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nataraju,

 <= /p>

RFC 6337 supports early d= ialog UPDATE scenario which I mentioned in this mail. The exact RFC

snippet with “Early= column” explanation.

 <= /p> 

            Off=
er            &=
nbsp;   Answer        &nb=
sp;    RFC    Ini Est Early
     ---------------------------------------------=
----------------------
     6. UPDATE Req.     &=
nbsp;    2xx UPDATE Resp.     RFC 3311&n=
bsp; N   Y    Y

 <= /p>

   The 'Early' column indicates which patterns m= ay be used to modify the

   established session in an early dialog. = There are two ways to

   exchange a subsequent offer/answer in an earl= y dialog.

 

Here, UPDATE MUST not be = used for initiating the session but it shall be used in the early dialog.

AFAIK, UPDATE With SDP is= mostly useful in early-dialog as RE-INVITE with SDP is possible in the

mid-dialog (“Est= 221;)

 

Justin,=

 <= /p>

Richard provided some of = the usecase using forked responses.  This usecase is not the corner

case and it is very norma= l scenario in SIP O/A. I’ll add further usecase for this scenario:

 <= /p>

One of the main usecase o= f UPDATE with SDP in the early dialog is remote ringback tone (RRBT)

from media server Usecase= . Multiple scenario involved in this usecase:     =     

 <= /p>

1) = ;     First usecase, th= e first offer/answer is completed between  Originating endpoint and

        media server, UPDATE with sec= ond offer is sent towards Originating endpoint to update

        SDP with terminating End= point.

2) = ;     Second usecase, t= he first offer/answer is completed with direction attribute as

Sendonly in the an= swer by which early dialog is only for remote ringback tone and  not

actual session est= ablishment.  second offer in UPDATE is updated the direction attribute=

as “sendrecv= ”.

3) = ;     Combination of Fi= rst and second usecase wherein media server answer with sendonly,

UPDATE with SDP fo= r “sendrecv”.

 <= /span>

Common Topology:

 <= /p>

Originating

Browser--------------Gate= way---------SoftSwitch/PBX(B2BUA)-------SIP UA (Media Server/IVR)

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      |      &n= bsp;            = ;        

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      -------------------SIP UA (IP phon= e)

 <= /p>

RFC 6337 has lot of other= corner scenario. Could you please let me know how to map the second

OFFER and in PRANSWER sta= te of the Originating endpoint (webbrowser in JSEP).

 <= /p>

In case JSEP O/A is based= on OFFER & ANSWER states only, this scenario will not hit.<= /span>

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

=

 

 <= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Nataraju A.B
Sent: Tuesday, May 01, 2012 9:42 PM
To: Ejzak, Richard P (Richard)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in= JSEP

 

The original scenario mentioned by Partha is quite l= ogical and acceptable, since there is only one O/A open all the times.=

 

If not handled properly, this additional UPDATE (wit= h OFFER2) during the lifetime of INVITE transaction lead to ambiguities. He= nce rfc6337, don't support this as a valid O/A.

 

On Tue, May 1, 2012 at 7:27 PM, Ejzak, Richard P (Ri= chard) <richard.ejzak@alcatel-lucent.com> wrote:

Hi Justin, Partha,

The call flow from Partha is a very reasonab= le one in the presence of SIP forking.  Let’s assume that a first target responded with an SDP answer in a 183 that must be treated = as a PRANSWER since other targets have not yet had a chance to respond.&nbs= p; Then the first target sends an UPDATE with offer2.

 

As far as SIP is concerned, there is no such= thing as a PRANSWER.  The first target already responded with an SDP ANSWER and wants to UPDATE with a new offer.  This is per= fectly legitimate and common SIP usage.  PRANSWER is a local construct= that should be usable by the application to support more complex offer/ans= wer cases like forking.

 

You must respond to this offer by cloning th= e peer connection, closing the clone with an ANSWER identical to the previous PRANSWER and then applying offer2 to the clone (or just ap= plying the offer2 directly with the understanding that the previous transac= tion is closed).  The original peer connection must revert to the orig= inal OFFER state to allow for other targets to respond.

 

Alternately, the original peer connection ca= n support the first target and a new clone created if there is the potential for other forked responses to the original offer.  E= ither way can be made to work.

 

This is a perfectly reasonable SIP use case = that explains why we need to be able to clone the peer connection.

 

Richard

 

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, April 30, 2012 9:51 PM
To: Nataraju A.B
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in= JSEP

 

Yes, I was under the impression that SIP enforced this requirement, alth= ough I am probably not aware of all the corner cases. Is there a real-world= scenario where this flow is required?

On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B <nataraju.sip@gmail.com>= wrote:

If the scenario considered is without reliable provisional respons= es. Then the first ANSWER must be in 200-INV and no more O/A allowed during= INVITE(initial) transaction.

 

Basic requirement for reliable and unambiguous O/A is - At any = point in time there could be only one O/A open. 

 

Also only one O/A suggested during INVITE(initial) transactio= n.

 

For reference, rfc6337, list outs different O/A models...

 

<rfc6337>

 <=
/pre>

 


            Off=
er            &=
nbsp;   Answer        &nb=
sp;    RFC    Ini Est Early


     ---------------------------------------------=
----------------------


     1. INVITE Req.     &=
nbsp;    2xx INVITE Resp.     RFC 3261&n=
bsp; Y   Y    N


     2. 2xx INVITE Resp.     A=
CK Req.           &n=
bsp; RFC 3261  Y   Y    N


     3. INVITE Req.     &=
nbsp;    1xx-rel INVITE Resp. RFC 3262  Y   Y=
    N


     4. 1xx-rel INVITE Resp. PRACK Req.  =
;         RFC 3262  Y &nb=
sp; Y    N


     5. PRACK Req.     &n=
bsp;     200 PRACK Resp.      =
RFC 3262  N   Y    Y


     6. UPDATE Req.     &=
nbsp;    2xx UPDATE Resp.     RFC 3311&n=
bsp; N   Y    Y


 


          Table 1: Summar=
y of SIP Usage of the Offer/Answer Model 

</rfc6337>

 

Thanks,

Nataraju A B

 

On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi <pravindran@sonusn= et.com> wrote:

Justin/Cullen,

Could you please explain in case for an SDP_OFFER(1), the remote entity rep= lies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the expected b= ehavior. The exact callflow is as follows:


Browser1-------------------------Browser2(SIP-JSEP gateway)
   |        SDP_OFFER(1)      =      |  INV with offer1
   |------------------------------->|--->
   |       SDP_PRANSWER(1)       &n= bsp;  |  183 with answer1
   |<-------------------------------|<---
   |       SDP_OFFER(2)        = ;     |   UPDATE with offer2
   |<-------------------------------|<---
   |       SDP_ANSWER(2?)       &nb= sp;   |
   |--------------------->?

The reason for this O/A callflow is due to UPDATE method (RFC 3311) mapping= in Browser 2 (SIP-JSEP gateway).

Thanks
Partha

PS: For simplicity, PRACK message exchange is not chosen in SIP side.



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



 

--
Thanks,

Nataraju A.B.

 

 



 

--
Thanks,

Nataraju A.B.

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E23B519inbamail01sonus_-- From stefan.lk.hakansson@ericsson.com Wed May 2 00:50:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9079121F8A47 for ; Wed, 2 May 2012 00:50:31 -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 ZV8Pak9cEBUS for ; Wed, 2 May 2012 00:50:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE6A521F8A41 for ; Wed, 2 May 2012 00:50:30 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-28-4fa0e74518ae Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 33.ED.03534.547E0AF4; Wed, 2 May 2012 09:50:29 +0200 (CEST) Received: from [150.132.142.229] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 09:50:29 +0200 Message-ID: <4FA0E744.9000506@ericsson.com> Date: Wed, 2 May 2012 09:50:28 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E312992828BD@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Use Case draft - Eavesdropping. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:50:31 -0000 On 05/01/2012 04:05 PM, Eric Rescorla wrote: > On Tue, May 1, 2012 at 6:14 AM, Hutton, Andrew > wrote: >> Hi, >> >> A number of use cases within Draft-ietf-rtcweb-use-cases-and-requirements-07 contain the statement "It is essential that the communication cannot be eavesdropped" however there is no definition of what is actually meant by "eavesdropped" although I think we all have an idea of what it means. >> >> Maybe it would be better to replace these statements with something that refers to wiretapping and RFC 2804 (RAVEN) which actually has a definition of wiretapping. > > This seems like it's creeping into the security requirements question. > Rather than try to make the use cases document more precise, I'd > prefer to have those statements be in draft-ietf-rtcweb-security, > which actually has (or at least is intended to) have fairly precise > descriptions of what the relevant security properties are. As one of the editors of the use case doc, I agree. The document was written at a time when everything was much vaguer, and we as a group had much much less insight, and this is reflected in the document. 'Eavesdropping' is one example, 'stream' is another (we now have things like MediaStream, MediaStreamTrack), and so on. I think we should keep it that way rather than doing a major update; I think there is little gain in doing that. Stefan > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed May 2 01:45:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE3221F8A47 for ; Wed, 2 May 2012 01:45:54 -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=[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 V8ciz4ADKZYu for ; Wed, 2 May 2012 01:45:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3680721F8A43 for ; Wed, 2 May 2012 01:45:53 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-13-4fa0f4400874 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5F.78.03534.044F0AF4; Wed, 2 May 2012 10:45:52 +0200 (CEST) Received: from [150.132.142.229] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 10:45:51 +0200 Message-ID: <4FA0F43E.4020308@ericsson.com> Date: Wed, 2 May 2012 10:45:50 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com><2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com><387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com><4F9EC0B2.10903@alcatel-lucent.com><101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:45:54 -0000 On 05/01/2012 02:05 PM, Jim Barnett wrote: > One way to describe the use case is to let the contact center's media > server/gateway serve as the webRTC endpoint. Then all the issues of > call delivery, call monitoring, etc. disappear. They are handled by > application software that sits behind the webRTC endpoint. The > company I work for makes a good living selling software that deals > with all these issues - including bathroom breaks - and that's how we > would tend to think of this case. To us, it's a new kind of > call/connection coming into the contact center, which we translate > into SIP at the border and then handle normally. > > It's not clear to me if this use case adds any extra requirements. I think this is important to sort out. If the use case does not add any extra requirements, what's the point of adding it? > We would just have to be careful not to assume that a webRTC endpoint > is always a person/browser-based user agent. It may seem a bit > unsettling that the webRTC endpoint can distribute the call somewhere > else and let others listen in, but as far as I can tell that is > already the case. If Bob calls Alice with full authentication and > security, he can be sure that he is connected to Alice's user agent > and that no one in between can listen in, but there's nothing > stopping Alice from recording the audio, or forwarding it to a third > party. So Bob could in fact be talking to Mary if that's how Alice > wants to arrange things (_behind_ her user agent). In general, Bob > is assured only that he is talking to someone Alice wants him to talk > to, and that no one can snoop without Alice's permission. That's > very much the way things work with the call center - you are sure > that you are 1) connected securely to your bank 2) talking to someone > that the bank wants you to talk to 3) being recorded or snooped on > only when the bank explicitly chooses to do so. > > - Jim > > -----Original Message----- From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: > Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc: > rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft > > On Mon, Apr 30, 2012 at 2:31 PM, Hutton, > Andrew wrote: >> Whether anybody has been successful in the past with this type of >> use case is I think irrelevant. >> >> >> >> The enterprise call centre use case is I think a vital use case >> because it is a scenario in which one user is only concerned that >> they can securely reach an organization/domain and is not concerned >> about the individual within that domain that they communicate >> with. A suspect quite a large percentage of RTCWEB applications >> will be like this and it is not covered in the current use case >> draft. > > I agree that this is a very useful use case and one I think is going > to get a lot of traction. There is a very solid business case for > this. However, I have a fair amount of experience with a video call > center for a client, and it is not as simple as it might seem. > > The essence of course is that you get the next available person, > i.e., it is anycast. Determining who the next available person is is > not trivial, nor is error recovery. (If I call you, and you don't > answer or the call drops or whatever, I can leave a message or try > later. If I call a help desk, and this happens, I want a new agent, > ideally automatically.) Call forwarding (e.g., first tier to second > tier technical support) is essential, and it may be anycast or > directed. There are also some security oddities - if I am connecting > from home, I may need to authenticate, use a credit card, etc. If I > am connecting from inside a store, and providing in store video > technical support is big part of the market, then the store > authenticates me off line and the call really should just be a button > push, which implies that the store has previously authenticated some > sort of master session. In addition, unlike most video calls, in the > enterprise call center a supervisor may need to be able to monitor > (i.e., watch) a call, and in some circumstances (financial or medical > calls, for example) there will need to be third party recording. I > believe that these details would be different from the typical > RTCWEB scenario. > > Also, there will be a temptation to do the anycasting by the > techniques used to load balance servers in a data center, but I think > that may not be sufficient. The call "center" may in fact be spread > completely across the planet (daytime support in the US, nighttime > support in India, for example) and be on multiple autonomous systems > (and even from people's homes), which gives rise to some of the > transport issues NVO3 may face, but without any opportunity for > packet tagging. Plus, there will complicated rules about who can be > selected next. RTCWEB shouldn't worry about the intricacies of > bathroom break policies; these complexities should be dealt with by > an enterprise-side database, which to me (together with some of the > other issues above) suggests that this would probably benefit from > API support. > > Regards Marshall > > >> >> >> >> So I think we need it. >> >> >> >> Regards >> >> Andy >> >> >> >> >> >> >> >> >> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Igor Faynberg Sent: 30 April 2012 17:41 To: >> rtcweb@ietf.org >> >> >> Subject: Re: [rtcweb] Use Case draft >> >> >> >> Without numbers it is impossible to argue, but, if we talk about >> the perceived need, I disagree. Think of the people who travel >> abroad and cannot call the 800 number. (I routinely use Web >> interface for calls when traveling.) >> >> >> >> I am all for the use case, as described by Jim. >> >> Igor >> >> On 4/30/2012 9:54 AM, Tim Panton wrote: >> >> ... >> >> I can't tell you the actual numbers, but when presented with the >> choice of calling a toll free number >> >> or clicking a button marked "free internet call" - almost no-one on >> a real, busy site clicked the button. >> >> ( for every button click there were several orders of magnitude >> more 0800 calls from that page). >> >> >> >> >> >> So from my perspective this is a legacy interop use case with >> almost zero user acceptance. >> >> >> >> (as far as I can see no-one has made this use-case desirable in >> practice yet.) >> >> Tim. >> >> >> >> >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed May 2 01:47:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7857421F8A95 for ; Wed, 2 May 2012 01:47:30 -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 Ud8jJPEbarwB for ; Wed, 2 May 2012 01:47:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 923AE21F8A94 for ; Wed, 2 May 2012 01:47:29 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-2a-4fa0f4a00f78 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.D8.03534.0A4F0AF4; Wed, 2 May 2012 10:47:28 +0200 (CEST) Received: from [150.132.142.229] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 10:47:27 +0200 Message-ID: <4FA0F49F.9090208@ericsson.com> Date: Wed, 2 May 2012 10:47:27 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <0fc001cd2495$a3985950$eac90bf0$@com> <4F9E3C4B.9050904@ericsson.com> In-Reply-To: <4F9E3C4B.9050904@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] use cases, F20 and encryption, SCTP - comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:47:30 -0000 On 04/30/2012 09:16 AM, Magnus Westerlund wrote: > Hi, > > My suggestion is that the use case document should be clarified. And I > think the starting point is that the data channel must have the same > security requirements as RTP media, both are media from the point of the > application. (speaking as use case doc editor): makes a lot of sense to me. > > Cheers > > Magnus > > > On 2012-04-27 18:48, Dan Wing wrote: >>> The chairs would like to ask the working group to focus on the use >>> case draft. If you have use cases that need to be added to the >>> document or text changes you'd like to suggest, please send them in >>> for discussion before May 15th. After this round, we will look >>> toward having a working group last call on the document (hopefully >>> before the interim meeting). >> >> A few comments on draft-ietf-rtcweb-use-cases-and-requirements-07: >> >> >> 1. Requirement F20 states: >> >> F20 It MUST be possible to protect streams from eavesdropping. >> >> Consensus in the room during my presentation to RTCWEB at IETF83 was that we >> don't need to support un-encrypted media (RTP) at all, and that all media >> would be SRTP. Can that be captured in F20 by re-wording, or perhaps in a >> new requirement if we can't reword F20? If there is a need or desire to >> validate that consensus on list, let's please ask the chairs to do that. >> >> >> 2. I noticed there is no requirement that we have a baseline for how SRTP >> media is keyed (although there is a baseline requirement for codecs). This >> is a critical requirement. I suggest adding "The browser MUST support a >> baseline SRTP keying mechanism." We have not reached consensus on that >> keying mechanism, but the requirement is real. >> >> >> 3. I see the document restricts its scope to media streams in the >> Introduction with: >> >> "The document focuses on requirements related to real-time media >> streams. Requirements related to privacy, signalling between the >> browser and web server etc. are currently not considered." >> >> However, RTCWEB is also supports a data communication between browsers. I >> am worried if we do not specify requirements for the data communication we >> will have problems. I believe the expectation is that if the audio/video >> stream works, that the data communication stream also work. We need to >> capture requirements for the data communication stream somewhere: >> >> - a requirement to support data communication >> - that the chosen data communication protocol supports multiple streams >> (which is why SCTP was chosen over TCP) >> - for NAT/firewall traversal of the data communication protocol (which is >> why SCTP-over-UDP was chosen and another reason TCP was not chosen) >> - for encrypting that data communication session >> - a requirement for SCTP-over-UDP to work when UDP is blocked (aligning >> with the existing F29 for audio/video) >> - a requirement to do ICE connectivity checks prior to bringing up DTLS (I >> don't know if that is really a requirement, but I recall it mentioned at the >> RTCWEB interim in Mountain View). >> >> Based on the scoping of the draft-ietf-rtcweb-use-cases-and-requirements, >> the omission of the data communication stream is intentional. If not in >> draft-ietf-rtcweb-use-cases-and-requirements, where can we capture the >> requirements for the data communication stream? >> >> -d >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > From pravindran@sonusnet.com Wed May 2 02:05:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38521F8A5E for ; Wed, 2 May 2012 02:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 AyuDCqKP6rFG for ; Wed, 2 May 2012 02:05:47 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id D46BB21F8A36 for ; Wed, 2 May 2012 02:05:46 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT6D46rNm3WLBaK0bCtK9cBrQY72yfoeR@postini.com; Wed, 02 May 2012 02:05:46 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 May 2012 05:05:51 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 2 May 2012 14:35:40 +0530 From: "Ravindran, Parthasarathi" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Use Case draft Thread-Index: AQHNJJD6fraw229Zx0W4DjUXXLWGX5augkyAgAMxP4CAAR3d8P//0qUAgABiT3CAAAXtAIAALogAgAAe2gCAAJmegIAAjLEAgAFaowCAAF+tcA== Date: Wed, 2 May 2012 09:05:38 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C148913C5@inba-mail02.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com><2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com><387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com><4F9EC0B2.10903@alcatel-lucent.com><101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> In-Reply-To: <4FA0F43E.4020308@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Use Case draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 09:05:48 -0000 Stefan, This usecase add its own requirements from identity perspective as=20 I mentioned earlier.=20 WebRTC MUST allow "Anonymous" users secure session for call center usecase. "Anonymous" User may be agent in the call center side or=20 customer who does not require Identity to start the session. Thanks Partha=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Stefan Hakansson LK >Sent: Wednesday, May 02, 2012 2:16 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Use Case draft > >On 05/01/2012 02:05 PM, Jim Barnett wrote: >> One way to describe the use case is to let the contact center's media >> server/gateway serve as the webRTC endpoint. Then all the issues of >> call delivery, call monitoring, etc. disappear. They are handled by >> application software that sits behind the webRTC endpoint. The >> company I work for makes a good living selling software that deals >> with all these issues - including bathroom breaks - and that's how we >> would tend to think of this case. To us, it's a new kind of >> call/connection coming into the contact center, which we translate >> into SIP at the border and then handle normally. >> >> It's not clear to me if this use case adds any extra requirements. > >I think this is important to sort out. If the use case does not add any >extra requirements, what's the point of adding it? > >> We would just have to be careful not to assume that a webRTC endpoint >> is always a person/browser-based user agent. It may seem a bit >> unsettling that the webRTC endpoint can distribute the call somewhere >> else and let others listen in, but as far as I can tell that is >> already the case. If Bob calls Alice with full authentication and >> security, he can be sure that he is connected to Alice's user agent >> and that no one in between can listen in, but there's nothing stopping >> Alice from recording the audio, or forwarding it to a third party. So >> Bob could in fact be talking to Mary if that's how Alice wants to >> arrange things (_behind_ her user agent). In general, Bob is assured >> only that he is talking to someone Alice wants him to talk to, and >> that no one can snoop without Alice's permission. That's very much >> the way things work with the call center - you are sure that you are >> 1) connected securely to your bank 2) talking to someone that the bank >> wants you to talk to 3) being recorded or snooped on only when the >> bank explicitly chooses to do so. >> >> - Jim >> >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: >> Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc: >> rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft >> >> On Mon, Apr 30, 2012 at 2:31 PM, Hutton, >> Andrew wrote: >>> Whether anybody has been successful in the past with this type of use >>> case is I think irrelevant. >>> >>> >>> >>> The enterprise call centre use case is I think a vital use case >>> because it is a scenario in which one user is only concerned that >>> they can securely reach an organization/domain and is not concerned >>> about the individual within that domain that they communicate with. >>> A suspect quite a large percentage of RTCWEB applications will be >>> like this and it is not covered in the current use case draft. >> >> I agree that this is a very useful use case and one I think is going >> to get a lot of traction. There is a very solid business case for >> this. However, I have a fair amount of experience with a video call >> center for a client, and it is not as simple as it might seem. >> >> The essence of course is that you get the next available person, i.e., >> it is anycast. Determining who the next available person is is not >> trivial, nor is error recovery. (If I call you, and you don't answer >> or the call drops or whatever, I can leave a message or try later. If >> I call a help desk, and this happens, I want a new agent, ideally >> automatically.) Call forwarding (e.g., first tier to second tier >> technical support) is essential, and it may be anycast or directed. >> There are also some security oddities - if I am connecting from home, >> I may need to authenticate, use a credit card, etc. If I am connecting >> from inside a store, and providing in store video technical support is >> big part of the market, then the store authenticates me off line and >> the call really should just be a button push, which implies that the >> store has previously authenticated some sort of master session. In >> addition, unlike most video calls, in the enterprise call center a >> supervisor may need to be able to monitor (i.e., watch) a call, and in >> some circumstances (financial or medical calls, for example) there >> will need to be third party recording. I believe that these details >> would be different from the typical RTCWEB scenario. >> >> Also, there will be a temptation to do the anycasting by the >> techniques used to load balance servers in a data center, but I think >> that may not be sufficient. The call "center" may in fact be spread >> completely across the planet (daytime support in the US, nighttime >> support in India, for example) and be on multiple autonomous systems >> (and even from people's homes), which gives rise to some of the >> transport issues NVO3 may face, but without any opportunity for packet >> tagging. Plus, there will complicated rules about who can be selected >> next. RTCWEB shouldn't worry about the intricacies of bathroom break >> policies; these complexities should be dealt with by an >> enterprise-side database, which to me (together with some of the other >> issues above) suggests that this would probably benefit from API >> support. >> >> Regards Marshall >> >> >>> >>> >>> >>> So I think we need it. >>> >>> >>> >>> Regards >>> >>> Andy >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Igor Faynberg Sent: 30 April 2012 17:41 To: >>> rtcweb@ietf.org >>> >>> >>> Subject: Re: [rtcweb] Use Case draft >>> >>> >>> >>> Without numbers it is impossible to argue, but, if we talk about the >>> perceived need, I disagree. Think of the people who travel abroad >>> and cannot call the 800 number. (I routinely use Web interface for >>> calls when traveling.) >>> >>> >>> >>> I am all for the use case, as described by Jim. >>> >>> Igor >>> >>> On 4/30/2012 9:54 AM, Tim Panton wrote: >>> >>> ... >>> >>> I can't tell you the actual numbers, but when presented with the >>> choice of calling a toll free number >>> >>> or clicking a button marked "free internet call" - almost no-one on a >>> real, busy site clicked the button. >>> >>> ( for every button click there were several orders of magnitude more >>> 0800 calls from that page). >>> >>> >>> >>> >>> >>> So from my perspective this is a legacy interop use case with almost >>> zero user acceptance. >>> >>> >>> >>> (as far as I can see no-one has made this use-case desirable in >>> practice yet.) >>> >>> Tim. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> rtcweb mailing list >>> >>> rtcweb@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> _______________________________________________ rtcweb mailing list >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ rtcweb mailing list >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ rtcweb mailing list >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed May 2 06:01:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356F621F847C for ; Wed, 2 May 2012 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Tng1lxmRW8b2 for ; Wed, 2 May 2012 06:01:47 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4A03821F8491 for ; Wed, 2 May 2012 06:01:47 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT6EwOlfiEaDWBkUhHsFDgPJt725KHFEy@postini.com; Wed, 02 May 2012 06:01:47 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 May 2012 09:01:52 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 2 May 2012 18:31:41 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , Justin Uberti , Cullen Jennings Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewAThDfgAF2QivA= Date: Wed, 2 May 2012 13:01:41 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C148945AF@inba-mail02.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 13:01:48 -0000 Hi Charles, UPDATE is allowed in the early dialog and I haven't shown in the callflow f= or simplicity as I mentioned in PS of below mail as " PS: For simplicity, P= RACK message exchange is not chosen in SIP side." Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Monday, April 30, 2012 9:53 PM >To: Ravindran, Parthasarathi; Justin Uberti; Cullen Jennings >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in >JSEP > >Hi Partha, > >I believe such a flow illegal, per RFC 3311: > > o If the UPDATE is being sent before the completion of the INVITE > transaction, and the initial INVITE contained an offer, the > UPDATE cannot be sent with an offer unless the callee has > generated an answer in a reliable provisional response, has > received a PRACK for that reliable provisional response, has > not received any requests (PRACK or UPDATE) with offers that it > has not answered, and has not sent any UPDATE requests > containing offers that have not been answered. > >Cheers, >Charles > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Monday, April 30, 2012 12:02 AM >> To: Justin Uberti; Cullen Jennings >> Cc: rtcweb@ietf.org >> Subject: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP >> >> Justin/Cullen, >> >> Could you please explain in case for an SDP_OFFER(1), the remote >entity >> replies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the >> expected behavior. The exact callflow is as follows: >> >> >> Browser1-------------------------Browser2(SIP-JSEP gateway) >> | SDP_OFFER(1) | INV with offer1 >> |------------------------------->|---> >> | SDP_PRANSWER(1) | 183 with answer1 >> |<-------------------------------|<--- >> | SDP_OFFER(2) | UPDATE with offer2 >> |<-------------------------------|<--- >> | SDP_ANSWER(2?) | >> |--------------------->? >> >> The reason for this O/A callflow is due to UPDATE method (RFC 3311) >> mapping in Browser 2 (SIP-JSEP gateway). >> >> Thanks >> Partha >> >> PS: For simplicity, PRACK message exchange is not chosen in SIP side. >> >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed May 2 06:13:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829E21F849C for ; Wed, 2 May 2012 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=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 0CI6q5cAN2B4 for ; Wed, 2 May 2012 06:13:09 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8321F8496 for ; Wed, 2 May 2012 06:13:08 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-26-4fa132e3b793 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 19.F3.03534.3E231AF4; Wed, 2 May 2012 15:13:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 15:13:07 +0200 Message-ID: <4FA132E3.4020703@ericsson.com> Date: Wed, 2 May 2012 15:13:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Justin Uberti References: <4F869648.2020605@alvestrand.no> <4F96B7C9.1030609@ericsson.com> <4F980BA6.7070405@ericsson.com> <4F9822C2.7090602@alvestrand.no> <4F9E57BF.5000902@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 13:13:10 -0000 On 2012-05-01 05:02, Justin Uberti wrote: > > According to my Colleague Per-Erik you can use video.width and > video.height to set the resolution the video element should have. > > see > http://dev.w3.org/html5/spec/the-video-element.html#the-video-element > > Thus the code you presented should be something like. > > video.src = webkitURL.createObjectURL(s); > video.width = 300; > video.height = 300; > canvas.getContext("2d").drawImage(video, 0, 0, 300, 300); > > That would set the video objects size to a 300, 300 video resolution. > The drawImage call I have removed the part which selects a cropping of > the source video to automatically show the full video in the specified > area. > > The adaptation of the video will of course not happen instantly so until > that happens the video will be scaled to the specified width and height. > And the actual delivered resolution will depend on the COP request and > what the sender support. > > > I think this is a reasonable way to approach the problem as long as a >
Inaki said:


>=3B I= f I have a SIP phone implementing ICE and DTLS-SRTP (which is
>=3B sta= ndarized for SIP regardless it has null impementation)=2C will my SIP
&g= t=3B phone be able to *directly* talk in the media plane with a WebRTC
&= gt=3B browser? or not?

[BA] While I believe that the answer to this = question should be required to be "yes"=2C I do not think we can yet say wh= ether this will be true or not.

For example=2C for interoperation t= o be possible=2C the "continuing consent" mechanism used in ICE would need = to be backward compatible with existing implementations.

This is no= t the case for the mechanism proposed in draft-muthu-behave-consent-freshne= ss.

Similarly=2C we would need to ensure that the DTLS-SRTP functio= nality specified in WebRTC could be used to interoperate with existing impl= ementations=2C which as I understand it=2C support EKT.



= --_90fbff1c-ba1e-4808-9656-d98a385a7e13_-- From dwing@cisco.com Sat May 5 10:24:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923D121F85E4 for ; Sat, 5 May 2012 10:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yw+TBkesYhBH for ; Sat, 5 May 2012 10:24:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9E56B21F85E3 for ; Sat, 5 May 2012 10:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2122; q=dns/txt; s=iport; t=1336238685; x=1337448285; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zR3xPsPJ/qLAw1aCTm6DSYxxuENBX9y/is7sjZHe3eY=; b=izW7Huqi8df4fQ3Gnj7B/YhvfvAqJzg8RF8e8nA54+3VIFq2YlpzvJTi IZbAIxBKaNBaxzn6sPVY7Q/HYmfputPssvUhoho6n+ItykEdCybj5SYSf 4aDh+pvX1MI7cxinRfpF8skgztI1A4zBeVz4/0uJhXBXBWG7OHo2cxDZ2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGdhpU+Q/khM/2dsb2JhbABFhXKcapAYgQeCDAEBAQMBCAoBEAdPBQcBAwIJDwIEAQEDAhESAwICGSMKCQgBAQQTCxeHZwWaPo0WkiOBL4lQgm6CGoEYBIhkhRaWXYFpgwk X-IronPort-AV: E=Sophos;i="4.75,536,1330905600"; d="scan'208";a="72518940" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 05 May 2012 17:24:44 +0000 Received: from dwingWS ([10.32.240.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q45HOhwn003837; Sat, 5 May 2012 17:24:43 GMT From: "Dan Wing" To: "=?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?=" References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> <4FA1575C.4050508@ericsson.com> <4FA37A1E.4080806@alvestrand.no> <0db701cd 2adb$98082f10$c8188d30$@com> In-Reply-To: Date: Sat, 5 May 2012 10:24:48 -0700 Message-ID: <0dc901cd2ae3$f9ffb500$edff1f00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0q3KYDnVHuLjJfSiuEI8vd6hqE0wABsq8g Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft - legacy interop X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:24:46 -0000 > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Saturday, May 05, 2012 9:32 AM > To: Dan Wing > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Use Case draft - legacy interop >=20 > 2012/5/5 Dan Wing : > >> If I have a SIP phone implementing ICE and DTLS-SRTP (which is > >> standarized for SIP regardless it has null impementation), will my > SIP > >> phone be able to *directly* talk in the media plane with a WebRTC > >> browser? or not? > > > > That would work. >=20 > Ok, so then, taking into account that SIP defines the usage of > DTLS-SRTP in RFC 5763 (regardless no one device implements it), why > does this WG assumes that "interop with non WebRTC endpoints will be > made via *gateways*"? Perhaps a more accurate statement would be: directly, if the remote endpoint supports ICE and supports DTLS-SRTP; otherwise, via a gateway. > Let me please repeat my question: if my SIP phone implements RFC 5763, > can my SIP phone directly interop at media plane with a WebRTC > browser? (I know you already replied this, but I want to be very very > sure) :) Sure seems it should work. Only nuance that I am aware of at the moment is WEBRTC seems to want to require Consent Freshness (periodic ICE connectivity checks) for the duration of the call. This is okay, and would work with an existing SIP phone -- so long as the SIP phone continues to respond to ICE messages. It should. But I doubt that is exercised in SIPIT testing. The other nuance is that, because doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent freshness, there is desire to allow those periodic ICE connectivity checks to omit the MESSAGE-INTEGRITY, which is a change to ICE. See=20 draft-muthu-behave-consent-freshness. Of course, that doesn't require a gateway, but would require softening the implementation on the phone. draft-muthu-behave-consent-freshness might also add a new SDP attribute, I dunno yet. -d > Thanks a lot. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > From richard.ejzak@alcatel-lucent.com Sun May 6 11:40:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517D921F8549 for ; Sun, 6 May 2012 11:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.334, 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 h-WeRDhriFkh for ; Sun, 6 May 2012 11:40:37 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF921F8548 for ; Sun, 6 May 2012 11:40:36 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q46IeXV7004410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 6 May 2012 13:40:33 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q46IeXiK029483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 May 2012 13:40:33 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Sun, 6 May 2012 13:40:33 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Sun, 6 May 2012 13:40:31 -0500 Thread-Topic: [rtcweb] Question about JSEP createOffer Thread-Index: Ac0rt7b2MPjJPIJiSxe9o1wlRksHCA== Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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_6F428EFD2B8C2F49A2FB1317291A76C11364EC0288USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:40:38 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0288USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question about something I came across in the JSEP draft. 6.1.2 of JSEP draft 0 has the following text regarding "createOffer": As an offer, the generated SDP will contain the full set of capabilities supported by the session (as opposed to an answer, which will include only a specific negotiated subset to use); for each SDP line, the generation of the SDP must follow the appropriate process for generating an offer. In the event createOffer is called after the session is established, createOffer will generate an offer that is compatible with the current session, incorporating any changes that have been made to the session since the last complete offer-answer exchange, such as addition or removal of streams. If no changes have been made, the offer will be identical to the current local description. The first and last sentences might conflict if the SDP Answerer later wants= to create a new Offer. The local configuration based on the first offer/a= nswer will contain only the selected media configuration, whereas it is des= irable for the new Offer to contain the full set of capabilities of the (ne= w) Offerer. I think this text needs to change to reflect this case. Am I = missing something? Richard --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0288USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a question about something I came across in the J= SEP draft.

 

6.1.2 of JSEP draft 0 has the following text regarding &= #8220;createOffer”:

 

   As an offer, the generated SDP will contain the full s= et of

   capabilities supported by the session (as opposed to a= n answer, which

   will include only a specific negotiated subset to use)= ; for each SDP

   line, the generation of the SDP must follow the appropriate process

   for generating an offer. In the event createOffer is called after the

   session is established, createOffer will generate an o= ffer that is

   compatible with the current session, incorporating any changes that

   have been made to the session since the last complete offer-answer

   exchange, such as addition or removal of streams. If n= o changes have

   been made, the offer will be identical to the current local

   description.

 

The first and last sentences might conflict if the SDP Answerer later wants to create a new Offer.  The local configuration b= ased on the first offer/answer will contain only the selected media configuratio= n, whereas it is desirable for the new Offer to contain the full set of capabilities of the (new) Offerer.  I think this text needs to change = to reflect this case.  Am I missing something?

 

Richard

--_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0288USNAVSXCHMBSA_-- From richard.ejzak@alcatel-lucent.com Sun May 6 11:54:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F821F854A for ; Sun, 6 May 2012 11:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 hH4ocfoJ6mVl for ; Sun, 6 May 2012 11:54:18 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B78A321F8549 for ; Sun, 6 May 2012 11:54:18 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q46IsH0f028253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 6 May 2012 13:54:18 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q46IsH1J007569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 May 2012 13:54:17 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Sun, 6 May 2012 13:54:17 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Sun, 6 May 2012 13:54:16 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0ruaKw/sIXfcxHRLuCOzit4TRF6g== Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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_6F428EFD2B8C2F49A2FB1317291A76C11364EC028CUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:54:21 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC028CUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald asked for a proposal for PeerConnection cloning, so here it goes: I propose to create a new constructor "ClonePeerConnection" (CPC below) wit= h the following semantics. 1. CPC will create a new PeerConnection object when successful. The resu= lting PC behaves just like any other PC except as described below. 2. CPC will take as input a reference to an existing PeerConnection (PC) = object (no configuration or IceCallback parameters). 3. CPC can clone any other PC (including a cloned PC). The sequence of c= loning is not important and parents have no particular status different fro= m any generation of clone. 4. CPC will fail if either the local description of the parent PC is not = set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The pare= nt PC can be in the OPENING or ACTIVE state. 5. The CPC object will inherit the local streams, local ICE candidates, a= nd local description of the PC. 6. The remote streams and remote description for the CPC object will be s= et to empty. 7. The CPC object will be set to the OPENING state to reflect that only t= he local description is set. 8. The ICE states other than CLOSED and GATHERING will be handled indepen= dently for each PC and its clones (as is true in standard forking scenarios= ). 9. The ICE state for this clone will be set to ICE_WAITING to reflect tha= t all candidates are available but the remote configuration is not yet set. 10. The PC and its clone(s) use a common pool of media resources. 11. If the parent PC object has already released unused resources (final A= NSWER), resources are reallocated as available to reflect the capabilities = for each stream (as they would be reflected in a createOffer). 12. The local streams might multicast toward the remote targets depending = on the directionality attributes independently set for each PC and clone. 13. The application should manage the directionality attributes for remote= streams from different targets to avoid resource conflicts. CPC will be used primarily if forking is anticipated or actually occurs. I= t can also be used to clone a stable PC if desired for other reasons. When= used for SIP forking, creation of the clone can be delayed until an ANSWER= actually arrives from a 2nd target as long as final ANSWER hasn't been app= lied to the parent (PRANSWER is OK). The parent always handles the first t= arget; the first clone handles the 2nd target; etc. The application can ev= en try to clone for forking after the first ANSWER is applied to the parent= and resources are released, as long as the local description has not chang= ed, at the risk that some resources needed for the 2nd target are no longer= available and must be renegotiated. Comments on this proposal are welcome. Richard --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC028CUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald asked for a proposal for PeerConnection cloning, = so here it goes:

 

I propose to create a new constructor “ClonePeerCo= nnection” (CPC below) with the following semantics.

 

  1. CPC will create a new PeerConnection object when successful.  The resulting PC behaves = just like any other PC except as described below.<= /li>
  2. CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration = or IceCallback parameters).
  3. CPC can clone any other P= C (including a cloned PC).  The sequence of cloning is not importan= t and parents have no particular status different from any generation of clone.
  4. CPC will fail if either t= he local description of the parent PC is not set or the parent PC ICE is = in ICE_CLOSED or ICE_GATHERING state.  The parent PC can be in the OPENING or ACTIVE state.
  5. The CPC object will inher= it the local streams, local ICE candidates, and local description of the PC.<= o:p>
  6. The remote streams and re= mote description for the CPC object will be set to empty.
  7. The CPC object will be se= t to the OPENING state to reflect that only the local description is set.<= /o:p>
  8. The ICE states other than CLOSED and GATHERING will be handled independently for each PC and its clones (as is true in standard forking scenarios).
  9. The ICE state for this cl= one will be set to ICE_WAITING to reflect that all candidates are availabl= e but the remote configuration is not yet set.<= /li>
  10. The PC and its clone(s) u= se a common pool of media resources.
  11. If the parent PC object h= as already released unused resources (final ANSWER), resources are reallocated as available to reflect the capabilities for each stream (= as they would be reflected in a createOffer).
  12. The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.<= /font>
  13. The application should ma= nage the directionality attributes for remote streams from different target= s to avoid resource conflicts.

 

CPC will be used primarily if forking is anticipated or actually occurs.  It can also be used to clone a stable PC if desired = for other reasons.  When used for SIP forking, creation of the clone can b= e delayed until an ANSWER actually arrives from a 2nd target as lo= ng as final ANSWER hasn’t been applied to the parent (PRANSWER is OK). &= nbsp;The parent always handles the first target; the first clone handles the 2n= d target; etc.  The application can even try to clone for forking after = the first ANSWER is applied to the parent and resources are released, as long a= s the local description has not changed, at the risk that some resources need= ed for the 2nd target are no longer available and must be renegotia= ted.

 

Comments on this proposal are welcome.=

 

Richard

 

--_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC028CUSNAVSXCHMBSA_-- From christer.holmberg@ericsson.com Sun May 6 12:05:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBEF21F8554 for ; Sun, 6 May 2012 12:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucv9FswEvokP for ; Sun, 6 May 2012 12:05:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BEED421F8551 for ; Sun, 6 May 2012 12:05:55 -0700 (PDT) X-AuditID: c1b4fb30-b7c78ae000006de5-0b-4fa6cb92785e Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 72.1C.28133.29BC6AF4; Sun, 6 May 2012 21:05:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sun, 6 May 2012 21:05:54 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Date: Sun, 6 May 2012 21:01:12 +0200 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0ruaKw/sIXfcxHRLuCOzit4TRF6gAAPhbN Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 19:05:56 -0000 Hi Richard, Interesting proposal. In bullet 11, you say that, if a final answer has been received (and unused= resources released), resources would have to be reallocated once a clone i= s created. A couple of questions: 1. Is there a need to allow cloning once a final answer has been received? 2. Once a final answer is received on a given PC, would it automatically re= move all associated CPCs? The basic question is really whether there is a need for clones once a fina= l answer has been received. After all, there is a reason we call it "final"= :) Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ejzak,= Richard P (Richard) [richard.ejzak@alcatel-lucent.com] Sent: Sunday, May 06, 2012 9:54 PM To: rtcweb@ietf.org Subject: [rtcweb] Proposal for PeerConnection cloning Harald asked for a proposal for PeerConnection cloning, so here it goes: I propose to create a new constructor =93ClonePeerConnection=94 (CPC below)= with the following semantics. 1. CPC will create a new PeerConnection object when successful. The resu= lting PC behaves just like any other PC except as described below. 2. CPC will take as input a reference to an existing PeerConnection (PC) = object (no configuration or IceCallback parameters). 3. CPC can clone any other PC (including a cloned PC). The sequence of c= loning is not important and parents have no particular status different fro= m any generation of clone. 4. CPC will fail if either the local description of the parent PC is not = set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The pare= nt PC can be in the OPENING or ACTIVE state. 5. The CPC object will inherit the local streams, local ICE candidates, a= nd local description of the PC. 6. The remote streams and remote description for the CPC object will be s= et to empty. 7. The CPC object will be set to the OPENING state to reflect that only t= he local description is set. 8. The ICE states other than CLOSED and GATHERING will be handled indepen= dently for each PC and its clones (as is true in standard forking scenarios= ). 9. The ICE state for this clone will be set to ICE_WAITING to reflect tha= t all candidates are available but the remote configuration is not yet set. 10. The PC and its clone(s) use a common pool of media resources. 11. If the parent PC object has already released unused resources (final A= NSWER), resources are reallocated as available to reflect the capabilities = for each stream (as they would be reflected in a createOffer). 12. The local streams might multicast toward the remote targets depending = on the directionality attributes independently set for each PC and clone. 13. The application should manage the directionality attributes for remote= streams from different targets to avoid resource conflicts. CPC will be used primarily if forking is anticipated or actually occurs. I= t can also be used to clone a stable PC if desired for other reasons. When= used for SIP forking, creation of the clone can be delayed until an ANSWER= actually arrives from a 2nd target as long as final ANSWER hasn=92t been a= pplied to the parent (PRANSWER is OK). The parent always handles the first= target; the first clone handles the 2nd target; etc. The application can = even try to clone for forking after the first ANSWER is applied to the pare= nt and resources are released, as long as the local description has not cha= nged, at the risk that some resources needed for the 2nd target are no long= er available and must be renegotiated. Comments on this proposal are welcome. Richard From richard.ejzak@alcatel-lucent.com Sun May 6 13:40:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4621F855B for ; Sun, 6 May 2012 13:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 Hx6AGnbDkLJQ for ; Sun, 6 May 2012 13:40:42 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BA5DB21F8559 for ; Sun, 6 May 2012 13:40:42 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q46Kebd7000746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 May 2012 15:40:38 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q46KebuY019268 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 6 May 2012 15:40:37 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Sun, 6 May 2012 15:40:37 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "rtcweb@ietf.org" Date: Sun, 6 May 2012 15:40:35 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0ruaKw/sIXfcxHRLuCOzit4TRF6gAAPhbNAAMHk8A= Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 20:40:43 -0000 Hi Christer, Question 1: I agree that for parallel forking, as long as a PC is cloned be= fore the unused parent resources are released, it is not necessary to allow= cloning later. I would be ok to remove this feature. I threw it in becau= se it seemed not too expensive to implement (others have to comment on this= ) and it might be useful to allow delaying of cloning to the last possible = instant (and for potentially other applications). =20 Question 2: I do not think we want to automatically remove all related PCs = when one gets a final answer, else we could not support Partha's nested O/A= scenario. I propose that this be done manually (so it is not mentioned in= the proposal). This allows ICE and DTLS to progress independently with mu= ltiple targets until a winner is selected and the others are closed. BR, Richard -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Sunday, May 06, 2012 2:01 PM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] Proposal for PeerConnection cloning Hi Richard, Interesting proposal. In bullet 11, you say that, if a final answer has been received (and unused= resources released), resources would have to be reallocated once a clone i= s created. A couple of questions: 1. Is there a need to allow cloning once a final answer has been received? 2. Once a final answer is received on a given PC, would it automatically re= move all associated CPCs? The basic question is really whether there is a need for clones once a fina= l answer has been received. After all, there is a reason we call it "final"= :) Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ejzak,= Richard P (Richard) [richard.ejzak@alcatel-lucent.com] Sent: Sunday, May 06, 2012 9:54 PM To: rtcweb@ietf.org Subject: [rtcweb] Proposal for PeerConnection cloning Harald asked for a proposal for PeerConnection cloning, so here it goes: I propose to create a new constructor "ClonePeerConnection" (CPC below) wit= h the following semantics. 1. CPC will create a new PeerConnection object when successful. The resu= lting PC behaves just like any other PC except as described below. 2. CPC will take as input a reference to an existing PeerConnection (PC) = object (no configuration or IceCallback parameters). 3. CPC can clone any other PC (including a cloned PC). The sequence of c= loning is not important and parents have no particular status different fro= m any generation of clone. 4. CPC will fail if either the local description of the parent PC is not = set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The pare= nt PC can be in the OPENING or ACTIVE state. 5. The CPC object will inherit the local streams, local ICE candidates, a= nd local description of the PC. 6. The remote streams and remote description for the CPC object will be s= et to empty. 7. The CPC object will be set to the OPENING state to reflect that only t= he local description is set. 8. The ICE states other than CLOSED and GATHERING will be handled indepen= dently for each PC and its clones (as is true in standard forking scenarios= ). 9. The ICE state for this clone will be set to ICE_WAITING to reflect tha= t all candidates are available but the remote configuration is not yet set. 10. The PC and its clone(s) use a common pool of media resources. 11. If the parent PC object has already released unused resources (final A= NSWER), resources are reallocated as available to reflect the capabilities = for each stream (as they would be reflected in a createOffer). 12. The local streams might multicast toward the remote targets depending = on the directionality attributes independently set for each PC and clone. 13. The application should manage the directionality attributes for remote= streams from different targets to avoid resource conflicts. CPC will be used primarily if forking is anticipated or actually occurs. I= t can also be used to clone a stable PC if desired for other reasons. When= used for SIP forking, creation of the clone can be delayed until an ANSWER= actually arrives from a 2nd target as long as final ANSWER hasn't been app= lied to the parent (PRANSWER is OK). The parent always handles the first t= arget; the first clone handles the 2nd target; etc. The application can ev= en try to clone for forking after the first ANSWER is applied to the parent= and resources are released, as long as the local description has not chang= ed, at the risk that some resources needed for the 2nd target are no longer= available and must be renegotiated. Comments on this proposal are welcome. Richard From martin.thomson@gmail.com Sun May 6 15:20:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0313321F8559 for ; Sun, 6 May 2012 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.783 X-Spam-Level: X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThAoLfhJ-+x7 for ; Sun, 6 May 2012 15:19:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 910B221F854F for ; Sun, 6 May 2012 15:19:58 -0700 (PDT) Received: by bkty8 with SMTP id y8so3932524bkt.31 for ; Sun, 06 May 2012 15:19:57 -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=Yj6ykmTjo4mYO0VZNdA1kyoap/2nagKUiRZZ/ukK6kg=; b=A6O1DW1Ww4Tgl4OnS4Kb+Sk9+2xzIOXsguPrKZGejS22acxIIU7bZGlAWyZxtXfmQr nnfkGCcn3DcQyWahux72rdUPxM40ACU7uE07FETpYcYb/tZSOKXc5B5qjHvqacixlAw+ KY/CN3Gs+Fi++Vb+W2lhXHqHBNDLOMOB4XEZIyqrC12YoNZV2tpp6aF6XIzEQPYN4O/h M2W730vM26DAJlVvXJAe4gLcjc4wdEJm+raC2UnxyjZZl2UEI6O2R5eQNDdXZnUDm2kd rPX9JS+F1XercjVbm8C1guDMuVoOpO6tWa6S9yGwKqN1AGhNrqdG+6yqEngYfK1SQ/pD p/hw== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr4615508bks.42.1336342797298; Sun, 06 May 2012 15:19:57 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Sun, 6 May 2012 15:19:57 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Sun, 6 May 2012 15:19:57 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Sun, 6 May 2012 15:19:57 -0700 Message-ID: From: Martin Thomson To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=0015174c43aabb2dbe04bf658d2f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 22:20:00 -0000 --0015174c43aabb2dbe04bf658d2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Such a complicated process would not be necessary if the PeerConnection object were not home to two largely independent state machines. Nor would it be necessary if this scenario were considered out of scope. Certainly, if you consider the scenario interesting enough to do something about (I don't), then you news some support from the browser in setting up two ICE associations on the same local port, but that is easier without having to worry about the state of the media negotiation. Let's assume you could have transport and media separate. Then what you need is a clone operation for the transport object. You can simply start the media negotiation, as if from scratch on the cloned transport. The state of the media has no real bearing on this then, and Christer's concern becomes irrelevant. ...Though it is certainly valid given the current proposal. Other considerations: -does the clone get a copy of local streams if they are added to the original? I'm guessing not. -the transition from PR_ANSWER to OFFER will be difficult given that this is the obvious way to implement this -how does the application learn that cloning fails due to lack of resources? Normally, an offer can't include capabilities that cannot be provided, but this implies it. An alternative, within the constraints offered by JSEP, is to create a new PeerConfection and bind it to an existing one. What reasons can you offer for avoiding this choice? --Martin On May 6, 2012 11:54 AM, "Ejzak, Richard P (Richard)" < richard.ejzak@alcatel-lucent.com> wrote: > Harald asked for a proposal for PeerConnection cloning, so here it goes:= * > *** > > ** ** > > I propose to create a new constructor =E2=80=9CClonePeerConnection=E2=80= =9D (CPC below) > with the following semantics.**** > > ** ** > > 1. CPC will create a new PeerConnection object when successful. The > resulting PC behaves just like any other PC except as described below.= * > *** > 2. CPC will take as input a reference to an existing PeerConnection > (PC) object (no configuration or IceCallback parameters).**** > 3. CPC can clone any other PC (including a cloned PC). The sequence > of cloning is not important and parents have no particular status diff= erent > from any generation of clone.**** > 4. CPC will fail if either the local description of the parent PC is > not set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. = The > parent PC can be in the OPENING or ACTIVE state.**** > 5. The CPC object will inherit the local streams, local ICE > candidates, and local description of the PC.**** > 6. The remote streams and remote description for the CPC object will > be set to empty.**** > 7. The CPC object will be set to the OPENING state to reflect that > only the local description is set.**** > 8. The ICE states other than CLOSED and GATHERING will be handled > independently for each PC and its clones (as is true in standard forki= ng > scenarios).**** > 9. The ICE state for this clone will be set to ICE_WAITING to reflect > that all candidates are available but the remote configuration is not = yet > set.**** > 10. The PC and its clone(s) use a common pool of media resources.**** > 11. If the parent PC object has already released unused resources > (final ANSWER), resources are reallocated as available to reflect the > capabilities for each stream (as they would be reflected in a createOf= fer). > **** > 12. The local streams might multicast toward the remote targets > depending on the directionality attributes independently set for each = PC > and clone.**** > 13. The application should manage the directionality attributes for > remote streams from different targets to avoid resource conflicts.**** > > ** ** > > CPC will be used primarily if forking is anticipated or actually occurs. > It can also be used to clone a stable PC if desired for other reasons. > When used for SIP forking, creation of the clone can be delayed until an > ANSWER actually arrives from a 2nd target as long as final ANSWER hasn=E2= =80=99t > been applied to the parent (PRANSWER is OK). The parent always handles t= he > first target; the first clone handles the 2nd target; etc. The > application can even try to clone for forking after the first ANSWER is > applied to the parent and resources are released, as long as the local > description has not changed, at the risk that some resources needed for t= he > 2nd target are no longer available and must be renegotiated.**** > > ** ** > > Comments on this proposal are welcome.**** > > ** ** > > Richard**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0015174c43aabb2dbe04bf658d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Such a complicated process would not be necessary if the PeerConnection = object were not home to two largely independent state machines.

Nor would it be necessary if this scenario were considered out of scope.=

Certainly, if you consider the scenario interesting enough to do somethi= ng about (I don't), then you news some support from the browser in sett= ing up two ICE associations on the same local port, but that is easier with= out having to worry about the state of the media negotiation.

Let's assume you could have transport and media separate. Then what = you need is a clone operation for the transport object. You can simply star= t the media negotiation, as if from scratch on the cloned transport.

The state of the media has no real bearing on this then, and Christer= 9;s concern becomes irrelevant.=C2=A0 ...Though it is certainly valid given= the current proposal.

Other considerations:
-does the clone get a copy of local streams if they are added to the origin= al? I'm guessing not.
-the transition from PR_ANSWER to OFFER will be difficult given that this i= s the obvious way to implement this
-how does the application learn that cloning fails due to lack of resources= ? Normally, an offer can't include capabilities that cannot be provided= , but this implies it.

An alternative, within the constraints offered by JSEP, is to create a n= ew PeerConfection and bind it to an existing one. What reasons can you offe= r for avoiding this choice?

--Martin

 --0015174c43aabb2dbe04bf658d2f-- From richard.ejzak@alcatel-lucent.com Sun May 6 17:26:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8282921F8448 for ; Sun, 6 May 2012 17:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 EDB4Cjy0Gqll for ; Sun, 6 May 2012 17:26:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B0B4B21F841E for ; Sun, 6 May 2012 17:26:10 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q470Q8Iw010454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 May 2012 19:26:09 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q470Q8tI003976 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 6 May 2012 19:26:08 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Sun, 6 May 2012 19:26:08 -0500 From: "Ejzak, Richard P (Richard)" To: Martin Thomson , "rtcweb@ietf.org" Date: Sun, 6 May 2012 19:26:06 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0r1mBxtT6yfr2YSoSa60QolFNKrgAAr0sg Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC02AE@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.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_6F428EFD2B8C2F49A2FB1317291A76C11364EC02AEUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 00:26:14 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC02AEUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, I'm not sure that separating the ICE and media state machines would help ve= ry much. ICE has to handle all the streams and components of a PeerConnect= ion at the same time anyway. Once cloning occurs, operations on them (in my proposal) are independent ex= cept in the sharing of resources allocated to the parent at the time of clo= ning. If we accept Christer's simplification then we should never need to fail th= e cloning operation due to lack of resources. I didn't think that reportin= g failure would be a problem (if necessary). You suggest that creating a separate PeerConnection and "binding" it to the= parent is somehow a better alternative for cloning. I look forward to rev= iewing an alternative proposal with sufficient detail to make a comparison = (as Harald challenged me to do). I took my best shot and certainly didn't = "avoid" any alternatives that I was aware of and thought might be superior. Richard ________________________________ From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Sunday, May 06, 2012 5:20 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for PeerConnection cloning Such a complicated process would not be necessary if the PeerConnection obj= ect were not home to two largely independent state machines. Nor would it be necessary if this scenario were considered out of scope. Certainly, if you consider the scenario interesting enough to do something = about (I don't), then you news some support from the browser in setting up = two ICE associations on the same local port, but that is easier without hav= ing to worry about the state of the media negotiation. Let's assume you could have transport and media separate. Then what you nee= d is a clone operation for the transport object. You can simply start the m= edia negotiation, as if from scratch on the cloned transport. The state of the media has no real bearing on this then, and Christer's con= cern becomes irrelevant. ...Though it is certainly valid given the current= proposal. Other considerations: -does the clone get a copy of local streams if they are added to the origin= al? I'm guessing not. -the transition from PR_ANSWER to OFFER will be difficult given that this i= s the obvious way to implement this -how does the application learn that cloning fails due to lack of resources= ? Normally, an offer can't include capabilities that cannot be provided, bu= t this implies it. An alternative, within the constraints offered by JSEP, is to create a new = PeerConfection and bind it to an existing one. What reasons can you offer f= or avoiding this choice? --Martin On May 6, 2012 11:54 AM, "Ejzak, Richard P (Richard)" > wrote: Harald asked for a proposal for PeerConnection cloning, so here it goes: I propose to create a new constructor "ClonePeerConnection" (CPC below) wit= h the following semantics. 1. CPC will create a new PeerConnection object when successful. The resu= lting PC behaves just like any other PC except as described below. 2. CPC will take as input a reference to an existing PeerConnection (PC) = object (no configuration or IceCallback parameters). 3. CPC can clone any other PC (including a cloned PC). The sequence of c= loning is not important and parents have no particular status different fro= m any generation of clone. 4. CPC will fail if either the local description of the parent PC is not = set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The pare= nt PC can be in the OPENING or ACTIVE state. 5. The CPC object will inherit the local streams, local ICE candidates, a= nd local description of the PC. 6. The remote streams and remote description for the CPC object will be s= et to empty. 7. The CPC object will be set to the OPENING state to reflect that only t= he local description is set. 8. The ICE states other than CLOSED and GATHERING will be handled indepen= dently for each PC and its clones (as is true in standard forking scenarios= ). 9. The ICE state for this clone will be set to ICE_WAITING to reflect tha= t all candidates are available but the remote configuration is not yet set. 10. The PC and its clone(s) use a common pool of media resources. 11. If the parent PC object has already released unused resources (final A= NSWER), resources are reallocated as available to reflect the capabilities = for each stream (as they would be reflected in a createOffer). 12. The local streams might multicast toward the remote targets depending = on the directionality attributes independently set for each PC and clone. 13. The application should manage the directionality attributes for remote= streams from different targets to avoid resource conflicts. CPC will be used primarily if forking is anticipated or actually occurs. I= t can also be used to clone a stable PC if desired for other reasons. When= used for SIP forking, creation of the clone can be delayed until an ANSWER= actually arrives from a 2nd target as long as final ANSWER hasn't been app= lied to the parent (PRANSWER is OK). The parent always handles the first t= arget; the first clone handles the 2nd target; etc. The application can ev= en try to clone for forking after the first ANSWER is applied to the parent= and resources are released, as long as the local description has not chang= ed, at the risk that some resources needed for the 2nd target are no longer= available and must be renegotiated. Comments on this proposal are welcome. Richard _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC02AEUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin,

I’m not sure that separating the= ICE and media state machines would help very much.  ICE has to handle all = the streams and components of a PeerConnection at the same time anyway.

 

Once cloning occurs, operations on the= m (in my proposal) are independent except in the sharing of resources allocated t= o the parent at the time of cloning.

 

If we accept Christer’s simplification then we should never need to fail the cloning operation due = to lack of resources.  I didn’t think that reporting failure would = be a problem (if necessary).

 

You suggest that creating a separate PeerConnection and “binding” it to the parent is somehow a bett= er alternative for cloning.  I look forward to reviewing an alternative proposal with sufficient detail to make a comparison (as Harald challenged me to do).&nbs= p; I took my best shot and certainly didn’t “avoid” any alternatives that I was aware of and thought might be superior.<= /span>

 

Richard

 

From: Martin T= homson [mailto:martin.thomson@gmail.com]
Sent: Sunday, May 06, 2012 5= :20 PM
To: Ejzak, Richard P (Richar= d)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Propos= al for PeerConnection cloning

 

Such a complicated process would not be necessary if the PeerConnection object wer= e not home to two largely independent state machines.

Nor would it be necessary if this scenario were considered out of scope.

Certainly, if you consider the scenario interesting enough to do something about (I don't), then you news some support from the browser in setting up two ICE associations on the same local port, but that is easier without having to w= orry about the state of the media negotiation.

Let's assume you could have transport and media separate. Then what you need is a clone operation for the transport object. You can simply start the media negotiation, as if from scratch on the cloned transport.<= /font>

The state of the media has no real bearing on this then, and Christer's concern becom= es irrelevant.  ...Though it is certainly valid given the current proposa= l.

Other considerations:
-does the clone get a copy of local streams if they are added to the origin= al? I'm guessing not.
-the transition from PR_ANSWER to OFFER will be difficult given that this i= s the obvious way to implement this
-how does the application learn that cloning fails due to lack of resources= ? Normally, an offer can't include capabilities that cannot be provided, but = this implies it.

An alternative, within the constraints offered by JSEP, is to create a new PeerConfection and bind it to an existing one. What reasons can you offer f= or avoiding this choice?

--Martin

On May 6, 2012 11:54 AM, "Ejzak, Richard P (Richard)" <= ;richard.ejzak@alcatel-luce= nt.com> wrote:

Ha= rald asked for a proposal for PeerConnection cloning, so here it goes:

&n= bsp;

I = propose to create a new constructor “ClonePeerConnection” (CPC below) with= the following semantics.

&n= bsp;

  1. CPC will create a new PeerConnection object = when successful.  The resulting PC behaves just like any other PC exce= pt as described below.
  2. CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration or IceCallback p= arameters).
  3. CPC can clone any other PC (including a clon= ed PC).  The sequence of cloning is not important and parents have n= o particular status different from any generation of clone.
  4. CPC will fail if either the local descriptio= n of the parent PC is not set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state.  The parent PC can be in the OPENING or ACTI= VE state.
  5. The CPC object will inherit the local stream= s, local ICE candidates, and local description of the PC.
  6. The remote streams and remote description fo= r the CPC object will be set to empty.
  7. The CPC object will be set to the OPENING st= ate to reflect that only the local description is set.<= /o:p>
  8. The ICE states other than CLOSED and GATHERI= NG will be handled independently for each PC and its clones (as is true i= n standard forking scenarios).
  9. The ICE state for this clone will be set to ICE_WAITING to reflect that all candidates are available but the remot= e configuration is not yet set.
  10. The PC and its clone(s) use a common pool of media resources.
  11. If the parent PC object has already released unused resources (final ANSWER), resources are reallocated as availabl= e to reflect the capabilities for each stream (as they would be reflected i= n a createOffer).
  12. The local streams might multicast toward the remote targets depending on the directionality attributes independentl= y set for each PC and clone.
  13. The application should manage the directiona= lity attributes for remote streams from different targets to avoid resource conflicts.

&n= bsp;

CP= C will be used primarily if forking is anticipated or actually occurs.  It can a= lso be used to clone a stable PC if desired for other reasons.  When used = for SIP forking, creation of the clone can be delayed until an ANSWER actually arrives from a 2nd target as long as final ANSWER hasn’t b= een applied to the parent (PRANSWER is OK).  The parent always handles the first target; the first clone handles the 2nd target; etc.  = ;The application can even try to clone for forking after the first ANSWER is app= lied to the parent and resources are released, as long as the local description = has not changed, at the risk that some resources needed for the 2nd target are no longer available and must be renegotiated.=

&n= bsp;

Co= mments on this proposal are welcome.

&n= bsp;

Ri= chard

&n= bsp;


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

--_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC02AEUSNAVSXCHMBSA_-- From randell-ietf@jesup.org Sun May 6 22:34:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CAE21F84B8 for ; Sun, 6 May 2012 22:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 RDstN7r5rVuJ for ; Sun, 6 May 2012 22:34:20 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1957921F84B5 for ; Sun, 6 May 2012 22:34:19 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRGaO-0004cw-Kr for rtcweb@ietf.org; Mon, 07 May 2012 00:34:18 -0500 Message-ID: <4FA75E92.2050007@jesup.org> Date: Mon, 07 May 2012 01:33:06 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 05:34:21 -0000 On 5/6/2012 4:40 PM, Ejzak, Richard P (Richard) wrote: > Hi Christer, > Question 1: I agree that for parallel forking, as long as a PC is cloned before the unused parent resources are released, it is not necessary to allow cloning later. I would be ok to remove this feature. I threw it in because it seemed not too expensive to implement (others have to comment on this) and it might be useful to allow delaying of cloning to the last possible instant (and for potentially other applications). > Question 2: I do not think we want to automatically remove all related PCs when one gets a final answer, else we could not support Partha's nested O/A scenario. I propose that this be done manually (so it is not mentioned in the proposal). This allows ICE and DTLS to progress independently with multiple targets until a winner is selected and the others are closed. If you want to support the usecase I suggested, where a single offer can result in parallel forking, but where you don't want to lock down to a single answerer: then you obviously need to support forking, and likely you need/want to support it irrespective of the 'final' state of the original PeerConnection. You *can* require cloning before the final answer is applied, though I would argue that you don't gain much by doing so. So this is the usecase: you send a single offer (say to a conference server controller, or to a game server) and you get a separate answer from each other endpoint, such as in a mesh conference, or who are in the same 'area' of the game, or in hearing (at that moment) in a VR environment. You might get these answers well after the initial answer or burst of answers. Using CPC, the sequence would be to: ClonePeerConnection(), apply the new answer to the new CPC-created PeerConnection. Nothing requires you to do so; you can reject the new answerer because you have a final already (or if the PeerConnection was made speculatively, you could close them if any other one of the clones received an answer). I *think* that CPC will reduce the amount of ICE traffic (in some cases) and the number of external ports used (depending on NATs), and therefore might reduce call setup-time overhead. Without CPC, the server will need to be able to ask endpoints to generate offers in anticipation of using later, or even immediately ("send me an offer *now* to forward to the new user, or "send me 8 more offers just like that one to send of existing users"). p.s. Thanks for the concrete proposal about how to handle this! We've been talking about it (on occasion) for a year-ish, but no one has proposed an actual set of semantics for it. > > BR, Richard > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, May 06, 2012 2:01 PM > To: Ejzak, Richard P (Richard); rtcweb@ietf.org > Subject: RE: [rtcweb] Proposal for PeerConnection cloning > > Hi Richard, > > Interesting proposal. > > In bullet 11, you say that, if a final answer has been received (and unused resources released), resources would have to be reallocated once a clone is created. > > A couple of questions: > > 1. Is there a need to allow cloning once a final answer has been received? > > 2. Once a final answer is received on a given PC, would it automatically remove all associated CPCs? > > The basic question is really whether there is a need for clones once a final answer has been received. After all, there is a reason we call it "final" :) > > Regards, > > Christer > > ________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard P (Richard) [richard.ejzak@alcatel-lucent.com] > Sent: Sunday, May 06, 2012 9:54 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Proposal for PeerConnection cloning > > Harald asked for a proposal for PeerConnection cloning, so here it goes: > > I propose to create a new constructor "ClonePeerConnection" (CPC below) with the following semantics. > > > 1. CPC will create a new PeerConnection object when successful. The resulting PC behaves just like any other PC except as described below. > 2. CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration or IceCallback parameters). > 3. CPC can clone any other PC (including a cloned PC). The sequence of cloning is not important and parents have no particular status different from any generation of clone. > 4. CPC will fail if either the local description of the parent PC is not set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The parent PC can be in the OPENING or ACTIVE state. > 5. The CPC object will inherit the local streams, local ICE candidates, and local description of the PC. > 6. The remote streams and remote description for the CPC object will be set to empty. > 7. The CPC object will be set to the OPENING state to reflect that only the local description is set. > 8. The ICE states other than CLOSED and GATHERING will be handled independently for each PC and its clones (as is true in standard forking scenarios). > 9. The ICE state for this clone will be set to ICE_WAITING to reflect that all candidates are available but the remote configuration is not yet set. > 10. The PC and its clone(s) use a common pool of media resources. > 11. If the parent PC object has already released unused resources (final ANSWER), resources are reallocated as available to reflect the capabilities for each stream (as they would be reflected in a createOffer). > 12. The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone. > 13. The application should manage the directionality attributes for remote streams from different targets to avoid resource conflicts. > > CPC will be used primarily if forking is anticipated or actually occurs. It can also be used to clone a stable PC if desired for other reasons. When used for SIP forking, creation of the clone can be delayed until an ANSWER actually arrives from a 2nd target as long as final ANSWER hasn't been applied to the parent (PRANSWER is OK). The parent always handles the first target; the first clone handles the 2nd target; etc. The application can even try to clone for forking after the first ANSWER is applied to the parent and resources are released, as long as the local description has not changed, at the risk that some resources needed for the 2nd target are no longer available and must be renegotiated. > > Comments on this proposal are welcome. > > Richard -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Sun May 6 23:22:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372DA21F84DF for ; Sun, 6 May 2012 23:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 mH2TwS-06uaO for ; Sun, 6 May 2012 23:22:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D61C521F84DA for ; Sun, 6 May 2012 23:22:05 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-13-4fa76a0c2e73 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AF.89.32015.C0A67AF4; Mon, 7 May 2012 08:22:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 7 May 2012 08:22:03 +0200 From: Christer Holmberg To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 7 May 2012 08:22:03 +0200 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0sExCiE1bGQO68R827nRhMUccxOQABc8Og Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> In-Reply-To: <4FA75E92.2050007@jesup.org> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 06:22:07 -0000 Hi, >> Hi Christer, >> Question 1: I agree that for parallel forking, as long as a PC is cloned= before the unused parent resources are >> released, it is not necessary to allow cloning later. I would be ok to = remove this feature. I threw it in because=20 >> it seemed not too expensive to implement (others have to comment on this= ) and it might be useful to allow >> delaying of cloning to the last possible instant (and for potentially ot= her applications). >> >> Question 2: I do not think we want to automatically remove all related P= Cs when one gets a final answer, else we >> could not support Partha's nested O/A scenario. I propose that this be = done manually (so it is not mentioned in the >> proposal). This allows ICE and DTLS to progress independently with mul= tiple targets until a winner is selected=20 >> and the others are closed. > > If you want to support the usecase I suggested, where a single offer can = result in parallel forking, but where you don't > want to lock down to a single answerer: then you obviously need to suppor= t forking, and likely you need/want to support > it irrespective of the 'final' state of the original PeerConnection. You= *can* require cloning before the final answer is=20 > applied, though I would argue that you don't gain much by doing so. > > So this is the usecase: you send a single offer (say to a conference serv= er controller, or to a game server) and you get=20 > a separate answer from each other endpoint, such as in a mesh conference,= or who are in the same 'area' of the game,=20 > or in hearing (at that moment) in a VR environment. You might get these = answers well after the initial answer or burst=20 > of answers. Yes. And, my idea would be that each of those answers are provided to the b= rowser as PRE_ANSWERS. Then, at some point, you decide that you are not going to accept any more a= nswers, and you provide an ANSWER to one of the (C)PCs, which will release = all other associated (C)PCs. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, May 06, 2012 2:01 PM > To: Ejzak, Richard P (Richard); rtcweb@ietf.org > Subject: RE: [rtcweb] Proposal for PeerConnection cloning > > Hi Richard, > > Interesting proposal. > > In bullet 11, you say that, if a final answer has been received (and unus= ed resources released), resources would have to be reallocated once a clone= is created. > > A couple of questions: > > 1. Is there a need to allow cloning once a final answer has been received= ? > > 2. Once a final answer is received on a given PC, would it automatically = remove all associated CPCs? > > The basic question is really whether there is a need for clones once a fi= nal answer has been received. After all, there is a reason we call it "fina= l" :) > > Regards, > > Christer > > ________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Ejza= k, Richard P (Richard) [richard.ejzak@alcatel-lucent.com] > Sent: Sunday, May 06, 2012 9:54 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Proposal for PeerConnection cloning > > Harald asked for a proposal for PeerConnection cloning, so here it goes: > > I propose to create a new constructor "ClonePeerConnection" (CPC below) w= ith the following semantics. > > > 1. CPC will create a new PeerConnection object when successful. The r= esulting PC behaves just like any other PC except as described below. > 2. CPC will take as input a reference to an existing PeerConnection (P= C) object (no configuration or IceCallback parameters). > 3. CPC can clone any other PC (including a cloned PC). The sequence o= f cloning is not important and parents have no particular status different = from any generation of clone. > 4. CPC will fail if either the local description of the parent PC is n= ot set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The p= arent PC can be in the OPENING or ACTIVE state. > 5. The CPC object will inherit the local streams, local ICE candidates= , and local description of the PC. > 6. The remote streams and remote description for the CPC object will b= e set to empty. > 7. The CPC object will be set to the OPENING state to reflect that onl= y the local description is set. > 8. The ICE states other than CLOSED and GATHERING will be handled inde= pendently for each PC and its clones (as is true in standard forking scenar= ios). > 9. The ICE state for this clone will be set to ICE_WAITING to reflect = that all candidates are available but the remote configuration is not yet s= et. > 10. The PC and its clone(s) use a common pool of media resources. > 11. If the parent PC object has already released unused resources (fina= l ANSWER), resources are reallocated as available to reflect the capabiliti= es for each stream (as they would be reflected in a createOffer). > 12. The local streams might multicast toward the remote targets dependi= ng on the directionality attributes independently set for each PC and clone= . > 13. The application should manage the directionality attributes for rem= ote streams from different targets to avoid resource conflicts. > > CPC will be used primarily if forking is anticipated or actually occurs. = It can also be used to clone a stable PC if desired for other reasons. Wh= en used for SIP forking, creation of the clone can be delayed until an ANSW= ER actually arrives from a 2nd target as long as final ANSWER hasn't been a= pplied to the parent (PRANSWER is OK). The parent always handles the first= target; the first clone handles the 2nd target; etc. The application can = even try to clone for forking after the first ANSWER is applied to the pare= nt and resources are released, as long as the local description has not cha= nged, at the risk that some resources needed for the 2nd target are no long= er available and must be renegotiated. > > Comments on this proposal are welcome. > > Richard --=20 Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Sun May 6 23:54:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2542621F84DA for ; Sun, 6 May 2012 23:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 od68kiYDeuAC for ; Sun, 6 May 2012 23:54:25 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB521F84B2 for ; Sun, 6 May 2012 23:54:25 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRHpw-00010b-1Y for rtcweb@ietf.org; Mon, 07 May 2012 01:54:24 -0500 Message-ID: <4FA7715B.40505@jesup.org> Date: Mon, 07 May 2012 02:53:15 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 06:54:26 -0000 On 5/7/2012 2:22 AM, Christer Holmberg wrote: >> >> If you want to support the usecase I suggested, where a single offer can result in parallel forking, but where you don't >> want to lock down to a single answerer: then you obviously need to support forking, and likely you need/want to support >> it irrespective of the 'final' state of the original PeerConnection. You *can* require cloning before the final answer is >> applied, though I would argue that you don't gain much by doing so. >> >> So this is the usecase: you send a single offer (say to a conference server controller, or to a game server) and you get >> a separate answer from each other endpoint, such as in a mesh conference, or who are in the same 'area' of the game, >> or in hearing (at that moment) in a VR environment. You might get these answers well after the initial answer or burst >> of answers. > Yes. And, my idea would be that each of those answers are provided to the browser as PRE_ANSWERS. > > Then, at some point, you decide that you are not going to accept any more answers, and you provide an ANSWER to one of the (C)PCs, which will release all other associated (C)PCs. Sorry, I think you missed the point: the application wants to end up with N connected, active PeerConnections, not one. This is a mesh conference (for example), not a central-mixer conference. And for added fun, we don't necessarily know there won't be more coming later, perhaps much later (but that's a possibly-separable feature). -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Mon May 7 00:08:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774A821F84DF for ; Mon, 7 May 2012 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=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 hhN8drehVeOo for ; Mon, 7 May 2012 00:08:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AEC0321F84DA for ; Mon, 7 May 2012 00:08:31 -0700 (PDT) X-AuditID: c1b4fb30-b7c78ae000006de5-ce-4fa774ee9faf Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 86.50.28133.EE477AF4; Mon, 7 May 2012 09:08:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 7 May 2012 09:08:29 +0200 From: Christer Holmberg To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 7 May 2012 09:08:27 +0200 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0sHj+FOGYYlPFESEathLjcP/pOJAAAaBBw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> In-Reply-To: <4FA7715B.40505@jesup.org> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 07:08:32 -0000 Hi, >>> If you want to support the usecase I suggested, where a single offer=20 >>> can result in parallel forking, but where you don't want to lock down=20 >>> to a single answerer: then you obviously need to support forking, and=20 >>> likely you need/want to support it irrespective of the 'final' state of= the original PeerConnection. You *can* require cloning before the final a= nswer is applied, though I would argue that you don't gain much by doing so= . >>> >>> So this is the usecase: you send a single offer (say to a conference=20 >>> server controller, or to a game server) and you get a separate answer=20 >>> from each other endpoint, such as in a mesh conference, or who are in=20 >>> the same 'area' of the game, or in hearing (at that moment) in a VR env= ironment. You might get these answers well after the initial answer or bur= st of answers. >> Yes. And, my idea would be that each of those answers are provided to th= e browser as PRE_ANSWERS. >> >> Then, at some point, you decide that you are not going to accept any mor= e answers, and you provide an ANSWER to one of the (C)PCs, which will relea= se all other associated (C)PCs. > > Sorry, I think you missed the point: the application wants to end up with= N connected, active PeerConnections, not one. This is a=20 > mesh conference (for example), not a central-mixer conference. And for a= dded fun, we don't necessarily know there won't be more=20 > coming later, perhaps much later (but that's a possibly-separable feature= ). Speaking in SIP terms, I don't think it is possible to implement mesh confe= rence that way, because clients will normally, once they've received one 20= 0 OK, ACK+BYE any additional ones. Or, a forking proxy will CANCEL all othe= r forked legs once a 200 OK has been forwarded on one of them. Regards, Christer From randell-ietf@jesup.org Mon May 7 00:37:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E621F84E7 for ; Mon, 7 May 2012 00:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_33=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 B3LKXYXx4pLv for ; Mon, 7 May 2012 00:37:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 690B921F84E2 for ; Mon, 7 May 2012 00:37:33 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRIVg-0002vu-6K for rtcweb@ietf.org; Mon, 07 May 2012 02:37:32 -0500 Message-ID: <4FA77B77.1020806@jesup.org> Date: Mon, 07 May 2012 03:36:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 07:37:34 -0000 On 5/7/2012 3:08 AM, Christer Holmberg wrote: > Hi, > >>>> If you want to support the usecase I suggested, where a single offer >>>> can result in parallel forking, but where you don't want to lock down >>>> to a single answerer: then you obviously need to support forking, and >>>> likely you need/want to support it irrespective of the 'final' state of the original PeerConnection. You *can* require cloning before the final answer is applied, though I would argue that you don't gain much by doing so. >>>> >>>> So this is the usecase: you send a single offer (say to a conference >>>> server controller, or to a game server) and you get a separate answer >>>> from each other endpoint, such as in a mesh conference, or who are in >>>> the same 'area' of the game, or in hearing (at that moment) in a VR environment. You might get these answers well after the initial answer or burst of answers. >>> Yes. And, my idea would be that each of those answers are provided to the browser as PRE_ANSWERS. >>> >>> Then, at some point, you decide that you are not going to accept any more answers, and you provide an ANSWER to one of the (C)PCs, which will release all other associated (C)PCs. >> Sorry, I think you missed the point: the application wants to end up with N connected, active PeerConnections, not one. This is a >> mesh conference (for example), not a central-mixer conference. And for added fun, we don't necessarily know there won't be more >> coming later, perhaps much later (but that's a possibly-separable feature). > Speaking in SIP terms, I don't think it is possible to implement mesh conference that way, because clients will normally, once they've received one 200 OK, ACK+BYE any additional ones. Or, a forking proxy will CANCEL all other forked legs once a 200 OK has been forwarded on one of them. Why would SIP come into this? Yes, classic PSTN telecom is focused on endpoint to one other connection, and any form of more complex arrangement is implemented with a mixing server or equivalent, and thus SIP flows are designed with that assumption in mind. However, we are NOT constrained to mirror SIP, and we should be able to build applications that go beyond what SIP makes easy to do. I gave some direct use-cases we've talked about since the beginning or near: Mesh conferencing, multiplayer games - where parallel forking (without collapse to a single session/connection) is desirable/useful. If there's an equally-usable way to implement those cases avoiding cloning, please detail that. I think cloning makes initiation of these sorts of mesh connections much simpler. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Mon May 7 01:20:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449621F8547 for ; Mon, 7 May 2012 01:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.2 X-Spam-Level: X-Spam-Status: No, score=-110.2 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zbNKAB4Bv8cB for ; Mon, 7 May 2012 01:20:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 954E621F8551 for ; Mon, 7 May 2012 01:20:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E77239E107; Mon, 7 May 2012 10:20: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 surXZw8NnZLM; Mon, 7 May 2012 10:20:04 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 68A5E39E031; Mon, 7 May 2012 10:20:04 +0200 (CEST) Message-ID: <4FA785B8.9080102@alvestrand.no> Date: Mon, 07 May 2012 10:20:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> <4FA1575C.4050508@ericsson.com> <4FA37A1E.4080806@alvestrand.no> <0db701cd2adb$98082f10$c8188d30$@com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft - legacy interop X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 08:20:09 -0000 On 05/05/2012 06:32 PM, Iñaki Baz Castillo wrote: > 2012/5/5 Dan Wing: >>> If I have a SIP phone implementing ICE and DTLS-SRTP (which is >>> standarized for SIP regardless it has null impementation), will my SIP >>> phone be able to *directly* talk in the media plane with a WebRTC >>> browser? or not? >> That would work. > Ok, so then, taking into account that SIP defines the usage of > DTLS-SRTP in RFC 5763 (regardless no one device implements it), why > does this WG assumes that "interop with non WebRTC endpoints will be > made via *gateways*"? > > Let me please repeat my question: if my SIP phone implements RFC 5763, > can my SIP phone directly interop at media plane with a WebRTC > browser? (I know you already replied this, but I want to be very very > sure) :) Inaki, your statement that "the WG assumes" is, as far as I can see, a straw man made out of red herrings. The WG's opinion is what's captured in the WG's documents, and (if needed) announced by the chairs. Statements by participants are statements by participants. If you have issue with the WG's documents, quote the text you want changed, don't just make unfounded statements like you do above. I've quoted the overview document before: As for all protocol and API specifications, there is no restriction that the protocols can only be used to talk to another browser; since they are fully specified, any device that implements the protocols faithfully should be able to interoperate with the application running in the browser. Since you did not specify the product number of your hypothetical phone, and since the IETF has not finished specifying the set of protocols needed, there is no guarantee that interworking will happen in practice. That is, there's no guarantee that ICE + RFC 5763 is sufficient for interoperation. From christer.holmberg@ericsson.com Mon May 7 03:58:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD11D21F85A8 for ; Mon, 7 May 2012 03:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=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 b+-0RHR4-nbd for ; Mon, 7 May 2012 03:58:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8D21F85A7 for ; Mon, 7 May 2012 03:58:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-63-4fa7aacd3497 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E4.40.25560.DCAA7AF4; Mon, 7 May 2012 12:58:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 7 May 2012 12:58:21 +0200 From: Christer Holmberg To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 7 May 2012 12:58:19 +0200 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0sJEaKMJOs9oEHT4WtRJmOhKxv1gAG2KQA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> In-Reply-To: <4FA77B77.1020806@jesup.org> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 10:58:25 -0000 Hi, >>>>> If you want to support the usecase I suggested, where a single=20 >>>>> offer can result in parallel forking, but where you don't want to=20 >>>>> lock down to a single answerer: then you obviously need to support=20 >>>>> forking, and likely you need/want to support it irrespective of the '= final' state of the original PeerConnection. You *can* require cloning bef= ore the final answer is applied, though I would argue that you don't gain m= uch by doing so. >>>>> >>>>> So this is the usecase: you send a single offer (say to a=20 >>>>> conference server controller, or to a game server) and you get a=20 >>>>> separate answer from each other endpoint, such as in a mesh=20 >>>>> conference, or who are in the same 'area' of the game, or in hearing = (at that moment) in a VR environment. You might get these answers well aft= er the initial answer or burst of answers. >>>> Yes. And, my idea would be that each of those answers are provided to = the browser as PRE_ANSWERS. >>>> >>>> Then, at some point, you decide that you are not going to accept any m= ore answers, and you provide an ANSWER to one of the (C)PCs, which will rel= ease all other associated (C)PCs. >>> Sorry, I think you missed the point: the application wants to end up=20 >>> with N connected, active PeerConnections, not one. This is a mesh=20 >>> conference (for example), not a central-mixer conference. And for adde= d fun, we don't necessarily know there won't be more coming later, perhaps = much later (but that's a possibly-separable feature). >> Speaking in SIP terms, I don't think it is possible to implement mesh co= nference that way, because clients will normally, once they've received one= 200 OK, ACK+BYE any >> additional ones. Or, a forking proxy will CANCEL all other forked legs o= nce a 200 OK has been forwarded on one of them. > > Why would SIP come into this? Yes, classic PSTN telecom is focused on en= dpoint to one other connection, and any form of more complex arrangement is= =20 > implemented with a mixing server or equivalent, and thus SIP flows are de= signed with that assumption in mind. However, we are NOT constrained to mi= rror=20 > SIP, and we should be able to build applications that go beyond what SIP = makes easy to do. > > I gave some direct use-cases we've talked about since the beginning or ne= ar: Mesh conferencing, multiplayer games - where parallel forking=20 > (without collapse to a single session/connection) is desirable/useful. I= f there's an equally-usable way to implement those cases avoiding cloning, = please > detail that. I think cloning makes initiation of these sorts of mesh con= nections much simpler. I didn't say you can't do it with CPC, I simply said that you would have is= sues if doing it with SIP. But, of course you can use whatever protocol on = the wire. Maybe there could be an API parameter to indicate, when a final answer is p= rovided to the browser, whether it should do a CPC "clean-up". It would mak= e life easier for the JS App developers in non-mesh-conf cases. Regards, Christer From richard.ejzak@alcatel-lucent.com Mon May 7 05:31:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FADD21F85D4 for ; Mon, 7 May 2012 05:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.87 X-Spam-Level: X-Spam-Status: No, score=-8.87 tagged_above=-999 required=5 tests=[AWL=1.129, BAYES_00=-2.599, J_CHICKENPOX_33=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 atZc6M-pL2tF for ; Mon, 7 May 2012 05:31:56 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6256D21F85AF for ; Mon, 7 May 2012 05:31:56 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q47CVnLY014864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 07:31:49 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q47CVmcw008530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 May 2012 07:31:48 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 7 May 2012 07:31:48 -0500 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , Randell Jesup , "rtcweb@ietf.org" Date: Mon, 7 May 2012 07:31:46 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0sJEaKMJOs9oEHT4WtRJmOhKxv1gAG2KQAAAKMcYA= Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 12:31:57 -0000 Hi Christer, As I mentioned in a previous response to you, you cannot mandate that clone= s be cleared out once a final ANSWER is applied since that prevents you fro= m applying independent offer/answer sequences to each clone (as required in= some SIP scenarios). The optional "cleanup" indicator you propose to asso= ciate with final ANSWER will not work in the case where a final ANSWER has = already been applied to a clone to allow another offer/answer sequence on t= hat clone before a final "winner" is selected. I would prefer to just clea= n up the "losers" manually or create a new method for this. There is at least one ERROR that I found in my proposal. I forgot that the= clone will continue to need to be able to report PEER-REFLEXIVE candidates= after the cloning operation, since this occurs after ICE exits the ICE_GAT= HERING state (this should be made clearer in the JSEP text). So the CPC st= ill needs the IceCallback. The SIP example in JSEP is also missing the 2nd offer/answer needed by ICE = to update the default candidates. How is the application triggered to gene= rate this offer? BR, Richard -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Monday, May 07, 2012 5:58 AM To: Randell Jesup; rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for PeerConnection cloning Hi, >>>>> If you want to support the usecase I suggested, where a single=20 >>>>> offer can result in parallel forking, but where you don't want to=20 >>>>> lock down to a single answerer: then you obviously need to support=20 >>>>> forking, and likely you need/want to support it irrespective of the '= final' state of the original PeerConnection. You *can* require cloning bef= ore the final answer is applied, though I would argue that you don't gain m= uch by doing so. >>>>> >>>>> So this is the usecase: you send a single offer (say to a=20 >>>>> conference server controller, or to a game server) and you get a=20 >>>>> separate answer from each other endpoint, such as in a mesh=20 >>>>> conference, or who are in the same 'area' of the game, or in hearing = (at that moment) in a VR environment. You might get these answers well aft= er the initial answer or burst of answers. >>>> Yes. And, my idea would be that each of those answers are provided to = the browser as PRE_ANSWERS. >>>> >>>> Then, at some point, you decide that you are not going to accept any m= ore answers, and you provide an ANSWER to one of the (C)PCs, which will rel= ease all other associated (C)PCs. >>> Sorry, I think you missed the point: the application wants to end up=20 >>> with N connected, active PeerConnections, not one. This is a mesh=20 >>> conference (for example), not a central-mixer conference. And for adde= d fun, we don't necessarily know there won't be more coming later, perhaps = much later (but that's a possibly-separable feature). >> Speaking in SIP terms, I don't think it is possible to implement mesh co= nference that way, because clients will normally, once they've received one= 200 OK, ACK+BYE any >> additional ones. Or, a forking proxy will CANCEL all other forked legs o= nce a 200 OK has been forwarded on one of them. > > Why would SIP come into this? Yes, classic PSTN telecom is focused on en= dpoint to one other connection, and any form of more complex arrangement is= =20 > implemented with a mixing server or equivalent, and thus SIP flows are de= signed with that assumption in mind. However, we are NOT constrained to mi= rror=20 > SIP, and we should be able to build applications that go beyond what SIP = makes easy to do. > > I gave some direct use-cases we've talked about since the beginning or ne= ar: Mesh conferencing, multiplayer games - where parallel forking=20 > (without collapse to a single session/connection) is desirable/useful. I= f there's an equally-usable way to implement those cases avoiding cloning, = please > detail that. I think cloning makes initiation of these sorts of mesh con= nections much simpler. I didn't say you can't do it with CPC, I simply said that you would have is= sues if doing it with SIP. But, of course you can use whatever protocol on = the wire. Maybe there could be an API parameter to indicate, when a final answer is p= rovided to the browser, whether it should do a CPC "clean-up". It would mak= e life easier for the JS App developers in non-mesh-conf cases. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Mon May 7 06:12:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF83A21F85FF for ; Mon, 7 May 2012 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.063, 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 3SV9yWS8dczD for ; Mon, 7 May 2012 06:12:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCAB21F85F6 for ; Mon, 7 May 2012 06:12:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so65023vbb.31 for ; Mon, 07 May 2012 06:12:31 -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=Olk/Ib2k6zXoXeeQcZT3K4JjT22ZfBf3uMQ5VHMq05A=; b=hmgm+/lVpTL5rOo5KtkwtSRgWl2TAliU90x2FjTBAh9/eMjNuHZW20QPhcDhMXdzyX NgKtn4ZUr3xIa7IrNzi7O5PDF5GFkc8X7HRiHcFIkvkBl3A1ZzhDeFEH8NDsZAxt7/xa noj7s1HHV9CoPOcmFkIhi9jLoFvi2sXl8dqvCcOxY8xyCnMJPTE423t+RGdqXOCLt8HI AvDcLwWuKTzu7CReHHzeqtPq7MSk9e44U92DB4me4/vHz82URZnR9Yi5mXRiOyx3gQ8T UrCymwh2r7AYuMpFs7kT5GAOc05bVa+9NGlGDhI9u6EL0ecLbcgDzXKzwqWZF4j6L2GE A/zA== Received: by 10.52.67.208 with SMTP id p16mr1122177vdt.93.1336390416289; Mon, 07 May 2012 04:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Mon, 7 May 2012 04:33:16 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 May 2012 13:33:16 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlwR4l9ETlkVPZpLLDEAMcqPW6XuVzr4ctJZsGhhC10fp3sM1cxxT3NI0jjKNlaH9db3Xn5 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:12:33 -0000 2012/5/7 Christer Holmberg : > Maybe there could be an API parameter to indicate, when a final answer is= provided to the browser, whether it should do a CPC "clean-up". It would m= ake life easier for the JS App developers in non-mesh-conf cases. I agree. IMHO it's much better if the API offers a simple mechanism for building/imitating existing VoIP technologies (i.e. SIP and XMPP-Jingle). Of course the API could be so powerful that it allows receiving late responses and use them (something that makes no sense in SIP world) but giving a simple parameter "just_one_final_response: true" in the constructor of the first PC, or offering an API function for discarding all the previous (C)PC's would be nice. Regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon May 7 06:45:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5221F864E for ; Mon, 7 May 2012 06:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 ZwncGIHU57M3 for ; Mon, 7 May 2012 06:45:57 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9921F8652 for ; Mon, 7 May 2012 06:45:55 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SROGA-0000iv-4b for rtcweb@ietf.org; Mon, 07 May 2012 08:45:54 -0500 Message-ID: <4FA7D1CC.3070004@jesup.org> Date: Mon, 07 May 2012 09:44:44 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:45:58 -0000 On 5/7/2012 8:31 AM, Ejzak, Richard P (Richard) wrote: > Hi Christer, > As I mentioned in a previous response to you, you cannot mandate that clones be cleared out once a final ANSWER is applied since that prevents you from applying independent offer/answer sequences to each clone (as required in some SIP scenarios). The optional "cleanup" indicator you propose to associate with final ANSWER will not work in the case where a final ANSWER has already been applied to a clone to allow another offer/answer sequence on that clone before a final "winner" is selected. I would prefer to just clean up the "losers" manually or create a new method for this. It doesn't have to be via this mechanism, but we could have an onfinal notification, or a manually polled jsepState checked (on all PeerConnections the app has) after installing an answer on one. (Unless the app knows that all it has are clones, in which case it could just kill off the others). jsepState is probably all that is needed (and probably needed even with onfinal, unless it gives a list of all clones of a finalized PC). -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Mon May 7 09:18:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59C21F8631 for ; Mon, 7 May 2012 09:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.097, 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 aWvYSKmvWIt9 for ; Mon, 7 May 2012 09:18:17 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F621F85D6 for ; Mon, 7 May 2012 09:18:16 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1442028wgb.1 for ; Mon, 07 May 2012 09:18:15 -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=wbtj3Ak1V79YOvQ8m6fPNTNpOry7OwUzJkKLuPCyCUs=; b=MhBvAAoWmKTWAinLIbIGzOhzezAj7BOVfP4YUoVGK0UqQdTh1SgkopkIm3wegL01Gl 7iyOyUK5kJM7MJY5VR16QnQys3iQzSMzalzcbFiTokzLPpfOqA32rABwq2STU6LnlX2q OFJdMF/xQtS8X85mtFuH0fmxmh6ffAt53V/XyzgaVgcOrnxs5M+/GnohuoHFuGbiRLaP rGRfCVGgoO6ZFPh01u40M6RXiwR4Yy4b+pcsbtaaA/VncO+In4MObHeL6JH4MkvPvaEp uH72tv3esmMO3EFPxfJoBvY1F2YnS1NxgzpcAeRolrJz7Jeg9uyqr5P+yucwyuzFuM3R ceRA== Received: by 10.180.99.72 with SMTP id eo8mr35841073wib.10.1336407495822; Mon, 07 May 2012 09:18:15 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id j3sm35491577wiw.1.2012.05.07.09.18.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 09:18:15 -0700 (PDT) Received: by bkty8 with SMTP id y8so4674438bkt.31 for ; Mon, 07 May 2012 09:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr5581475bkw.67.1336407493588; Mon, 07 May 2012 09:18:13 -0700 (PDT) Received: by 10.205.117.146 with HTTP; Mon, 7 May 2012 09:18:13 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 7 May 2012 12:18:13 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=0015175cfd18ee37c304bf749dad X-Gm-Message-State: ALoCoQmYLoEysZkLraEvIFXoyZX7fjW2fsi/Nb6iFjd/pr8YraoxmTh4qf8A4FREOH5nlQgq7eHs Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 16:18:18 -0000 --0015175cfd18ee37c304bf749dad Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 6:58 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Why would SIP come into this? Yes, classic PSTN telecom is focused on > endpoint to one other connection, and any form of more complex arrangement > is > > implemented with a mixing server or equivalent, and thus SIP flows are > designed with that assumption in mind. However, we are NOT constrained to > mirror > > SIP, and we should be able to build applications that go beyond what SIP > makes easy to do. > > > > I gave some direct use-cases we've talked about since the beginning or > near: Mesh conferencing, multiplayer games - where parallel forking > > (without collapse to a single session/connection) is desirable/useful. > If there's an equally-usable way to implement those cases avoiding > cloning, please > > detail that. I think cloning makes initiation of these sorts of mesh > connections much simpler. > > I didn't say you can't do it with CPC, I simply said that you would have > issues if doing it with SIP. But, of course you can use whatever protocol > on the wire. > > Maybe there could be an API parameter to indicate, when a final answer is > provided to the browser, whether it should do a CPC "clean-up". It would > make life easier for the JS App developers in non-mesh-conf cases. > > First of all, even in classic SIP use case, proxy will not hang up or cancel other call legs when 200 OK is received. You can setup a mesh conference this way if your end point supports this. Most of the end points do not, so they hang up the calls, but I have dealt with a few that actually start multiple calls this way and allow user to switch between them or conference them together. Second, you do need to be able to provide a final answer on the primary or cloned peer connection to implement Partha's scenario, since for this scenario you need to process another O/A while the original O/A is still in progress. This means you need to provide a final response on the call leg where you received the offer, but still be able to receive answers on other call legs. _____________ Roman Shpount --0015175cfd18ee37c304bf749dad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 7, 2012 at 6:58 AM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>= Why would SIP come into this? =A0Yes, classic PSTN telecom is focused on e= ndpoint to one other connection, and any form of more complex arrangement i= s
> implemented with a mixing server or equivalent, and thus SIP flows are= designed with that assumption in mind. =A0However, we are NOT constrained = to mirror
> SIP, and we should be able to build applications that go beyond what S= IP makes easy to do.
>
> I gave some direct use-cases we've talked about since the beginnin= g or near: Mesh conferencing, multiplayer games - where parallel forking > (without collapse to a single session/connection) is desirable/useful.= =A0If there's an equally-usable way to implement those cases avoiding = cloning, please
> detail that. =A0I think cloning makes initiation of these sorts of mes= h connections much simpler.

I didn't say you can't do it with CPC, I simply said th= at you would have issues if doing it with SIP. But, of course you can use w= hatever protocol on the wire.

Maybe there could be an API parameter to indicate, when a final answer is p= rovided to the browser, whether it should do a CPC "clean-up". It= would make life easier for the JS App developers in non-mesh-conf cases.
=A0
First of all, even in classic SIP use = case, proxy will not hang up or cancel other call legs when 200 OK is recei= ved. You can setup a mesh conference this way if your end point supports th= is. Most of the end points do not, so they hang up the calls, but I have de= alt with a few that actually start multiple calls this way and allow user t= o switch between them or conference them together.

Second, you do need to be able to provide a final answer on the primary= or cloned peer connection to implement Partha's scenario, since for th= is scenario you need to process another O/A while the original O/A is still= in progress. This means you need to provide a final response on the call l= eg where you received the offer, but still be able to receive answers on ot= her call legs.

_____________
Roman Shpount

--0015175cfd18ee37c304bf749dad-- From harald@alvestrand.no Mon May 7 14:14:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54E121F84E7 for ; Mon, 7 May 2012 14:14:37 -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 f2PYR+PNNXae for ; Mon, 7 May 2012 14:14:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDD421F84CF for ; Mon, 7 May 2012 14:14:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 455A539E1E2; Mon, 7 May 2012 23:14: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 0036lKUo28sW; Mon, 7 May 2012 23:14:35 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7C46E39E107; Mon, 7 May 2012 23:14:35 +0200 (CEST) Message-ID: <4FA83B3A.9070600@alvestrand.no> Date: Mon, 07 May 2012 23:14:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Dan Wing References: <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> <4FA1575C.4050508@ericsson.com> <4FA37A1E.4080806@alvestrand.no> <0db701cd 2adb$98082f10$c8188d30$@com> <0dc901cd2ae3$f9ffb500$edff1f00$@com> In-Reply-To: <0dc901cd2ae3$f9ffb500$edff1f00$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] Consent freshness and message-integrity (Re: Use Case draft - legacy interop) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:14:37 -0000 Forking the thread, since this is a different detail..... On 05/05/2012 07:24 PM, Dan Wing wrote: > The other nuance is that, because > doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent freshness, > there is desire to allow those periodic ICE connectivity checks to > omit the MESSAGE-INTEGRITY, which is a change to ICE. See > draft-muthu-behave-consent-freshness. Omitting MESSAGE-INTEGRITY would allow off-path attackers to inject fake connectivity checks, and thus to simulate continued consent. If connectivity checks for content freshness are worth doing, they're worth protecting. My $0.02. Harald From dwing@cisco.com Mon May 7 14:23:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9521F86F9 for ; Mon, 7 May 2012 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 aI5TJJ4Uy5XK for ; Mon, 7 May 2012 14:23:41 -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 268B221F86F8 for ; Mon, 7 May 2012 14:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1083; q=dns/txt; s=iport; t=1336425821; x=1337635421; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=XQl8sBOKL2Cw8YxUIKxrnMFi3f4VgjLTFdOQb/X6j9M=; b=BfTivomUVzvLrULmEFftV/gmJ1kVhLlBJYz0odJKo0xfikfUTTx2wd6B N57pg5z6cSLWOktMGLeSZUBmcSoLjx48FWps+FD4YBiITeaPwEqce5cOH nPFH6rI87nR34bE2YOFitv/e3SXHS/6zWPhb562DdJrqUs2pkuV9TQQO+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAFc8qE+rRDoG/2dsb2JhbABEhXKccJA9gQeCDAEBAQMBCAoBEAdPBQcBAwIJDwIEAQEBAgIjAwICGSMKCQgBAQQTCxeHZwSbCY0WknqBL4lQhHGBGASIZIUWll2BaYMJ X-IronPort-AV: E=Sophos;i="4.75,546,1330905600"; d="scan'208";a="43859301" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 May 2012 21:23:40 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q47LNe2I016137; Mon, 7 May 2012 21:23:40 GMT From: "Dan Wing" To: "'Harald Alvestrand'" References: <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> <4FA1575C.4050508@ericsson.com> <4FA37A1E.4080806@alvestrand.no> <0db701cd 2adb$98082f10$c8188d30$@com> <0dc901cd2ae3$f9ffb500$edff1f00$@com> <4FA83B3A.9070600@alvestr and.no> In-Reply-To: <4FA83B3A.9070600@alvestrand.no> Date: Mon, 7 May 2012 14:23:48 -0700 Message-ID: <027601cd2c97$b107e1a0$1317a4e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0slml7ggANXaVuRwiZD1QI8yaR9AAASAlg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consent freshness and message-integrity (Re: Use Case draft - legacy interop) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:23:42 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, May 07, 2012 2:15 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Consent freshness and message-integrity (Re: [rtcweb] Use Case > draft - legacy interop) > > Forking the thread, since this is a different detail..... > > On 05/05/2012 07:24 PM, Dan Wing wrote: > > The other nuance is that, because > > doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent > freshness, > > there is desire to allow those periodic ICE connectivity checks to > > omit the MESSAGE-INTEGRITY, which is a change to ICE. See > > draft-muthu-behave-consent-freshness. > Omitting MESSAGE-INTEGRITY would allow off-path attackers to inject > fake > connectivity checks, and thus to simulate continued consent. To successfully do that, those off-path attackers would have to guess the random 96-bit STUN transaction-id. -d > If connectivity checks for content freshness are worth doing, they're > worth protecting. > My $0.02. > > Harald From harald@alvestrand.no Mon May 7 14:24:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5321F86F8 for ; Mon, 7 May 2012 14:24:29 -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 uI5cdxeNH1CS for ; Mon, 7 May 2012 14:24:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A2B1621F869D for ; Mon, 7 May 2012 14:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90B7D39E1E2 for ; Mon, 7 May 2012 23:24:27 +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 Cei62dXQY-3v for ; Mon, 7 May 2012 23:24:27 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CE84F39E107 for ; Mon, 7 May 2012 23:24:26 +0200 (CEST) Message-ID: <4FA83D86.1050605@alvestrand.no> Date: Mon, 07 May 2012 23:24:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001342@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0293@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA75E92.2050007@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E11F@ESESSCMS0356.eemea.ericsson.se> <4FA7715B.40505@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E180@ESESSCMS0356.eemea.ericsson.se> <4FA77B77.1020806@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4435E3D1@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0377@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA7D1CC.3070004@jesup.org> In-Reply-To: <4FA7D1CC.3070004@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:24:29 -0000 On 05/07/2012 03:44 PM, Randell Jesup wrote: > On 5/7/2012 8:31 AM, Ejzak, Richard P (Richard) wrote: >> Hi Christer, >> As I mentioned in a previous response to you, you cannot mandate that >> clones be cleared out once a final ANSWER is applied since that >> prevents you from applying independent offer/answer sequences to each >> clone (as required in some SIP scenarios). The optional "cleanup" >> indicator you propose to associate with final ANSWER will not work in >> the case where a final ANSWER has already been applied to a clone to >> allow another offer/answer sequence on that clone before a final >> "winner" is selected. I would prefer to just clean up the "losers" >> manually or create a new method for this. > > It doesn't have to be via this mechanism, but we could have an onfinal > notification, or a manually polled jsepState checked (on all > PeerConnections the app has) after installing an answer on one. > (Unless the app knows that all it has are clones, in which case it > could just kill off the others). jsepState is probably all that is > needed (and probably needed even with onfinal, unless it gives a list > of all clones of a finalized PC). > It seems to me that for each Pc in ClonedConnections { if (Pc !== winner) Pc.close() } is simple enough to code that we should simply say that "the JS has to do cleanup when he decides he only wants one of the PeerConnection". Creating mechanisms for things to happen behind the scenes seems to me to make life for the programmer more complex, not less; "why did the voice of person 2 go silent? Oh - you applied an ANSWER instead of a PR-ANSWER to person 1".... From harald@alvestrand.no Mon May 7 14:32:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4325611E8074 for ; Mon, 7 May 2012 14:32:39 -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.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=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 Tgbj5YHB7GrL for ; Mon, 7 May 2012 14:32:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4019711E8073 for ; Mon, 7 May 2012 14:32:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32D9339E1E2 for ; Mon, 7 May 2012 23:32:35 +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 pZKSjZt+86H8 for ; Mon, 7 May 2012 23:32:30 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 92F0839E107 for ; Mon, 7 May 2012 23:32:30 +0200 (CEST) Message-ID: <4FA83F6D.9040308@alvestrand.no> Date: Mon, 07 May 2012 23:32:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------030403050202050101030304" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:32:39 -0000 This is a multi-part message in MIME format. --------------030403050202050101030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Richard, thank you for doing this! It's definitely the most thought-through proposal I've seen on this question! Two questions that are different from what others have raised: On 05/06/2012 08:54 PM, Ejzak, Richard P (Richard) wrote: > > Harald asked for a proposal for PeerConnection cloning, so here it goes: > > I propose to create a new constructor ?ClonePeerConnection? (CPC > below) with the following semantics. > > 1. CPC will create a new PeerConnection object when successful. > The resulting PC behaves just like any other PC except as > described below. > 2. CPC will take as input a reference to an existing PeerConnection > (PC) object (no configuration or IceCallback parameters). > 3. CPC can clone any other PC (including a cloned PC). The > sequence of cloning is not important and parents have no > particular status different from any generation of clone. > 4. CPC will fail if either the local description of the parent PC > is not set or the parent PC ICE is in ICE_CLOSED or > ICE_GATHERING state. The parent PC can be in the OPENING or > ACTIVE state. > 5. The CPC object will inherit the local streams, local ICE > candidates, and local description of the PC. > when it inherits the local streams, do you assume that unless the JS applies some setting, they will also inherit the "enabled/disabled" state, but that the "enabled/disabled" state can be changed independently for each PeerConnection's local streams after the cloning? > > 1. > > > 2. The remote streams and remote description for the CPC object > will be set to empty. > 3. The CPC object will be set to the OPENING state to reflect that > only the local description is set. > 4. The ICE states other than CLOSED and GATHERING will be handled > independently for each PC and its clones (as is true in standard > forking scenarios). > 5. The ICE state for this clone will be set to ICE_WAITING to > reflect that all candidates are available but the remote > configuration is not yet set. > 6. The PC and its clone(s) use a common pool of media resources. > 7. If the parent PC object has already released unused resources > (final ANSWER), resources are reallocated as available to > reflect the capabilities for each stream (as they would be > reflected in a createOffer). > 8. The local streams might multicast toward the remote targets > depending on the directionality attributes independently set for > each PC and clone. > So far, we've stayed away from anything that involves IP multicast. Are you sure it's worth the potential complexity to try to use this here? Remember that using multicast changes a *lot* of things on both ends of the connections - the sender has to have IP multicast address allocations, he has to decide between SSM and ASM, the recipients have to use a multicast joining protocol, the infrastructure has to be present to carry the multicast groups, we have to have a fallback in case it isn't, the appropriate congestion control protocols are probably different ..... I would prefer to not bring this in scope for this round of WebRTC. Is there a compelling reason you see for embarking on this particular adventure? > > 1. > > > 2. The application should manage the directionality attributes for > remote streams from different targets to avoid resource conflicts. > > CPC will be used primarily if forking is anticipated or actually > occurs. It can also be used to clone a stable PC if desired for other > reasons. When used for SIP forking, creation of the clone can be > delayed until an ANSWER actually arrives from a 2^nd target as long as > final ANSWER hasn?t been applied to the parent (PRANSWER is OK). The > parent always handles the first target; the first clone handles the > 2^nd target; etc. The application can even try to clone for forking > after the first ANSWER is applied to the parent and resources are > released, as long as the local description has not changed, at the > risk that some resources needed for the 2^nd target are no longer > available and must be renegotiated. > > Comments on this proposal are welcome. > > Richard > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030403050202050101030304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Richard, thank you for doing this! It's definitely the most thought-through proposal I've seen on this question!

Two questions that are different from what others have raised:

On 05/06/2012 08:54 PM, Ejzak, Richard P (Richard) wrote:

Harald asked for a proposal for PeerConnection cloning, so here it goes:

 

I propose to create a new constructor “ClonePeerConnection” (CPC below) with the following semantics.

 

  1. CPC will create a new PeerConnection object when successful.  The resulting PC behaves just like any other PC except as described below.
  2. CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration or IceCallback parameters).
  3. CPC can clone any other PC (including a cloned PC).  The sequence of cloning is not important and parents have no particular status different from any generation of clone.
  4. CPC will fail if either the local description of the parent PC is not set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state.  The parent PC can be in the OPENING or ACTIVE state.
  5. The CPC object will inherit the local streams, local ICE candidates, and local description of the PC.
when it inherits the local streams, do you assume that unless the JS applies some setting, they will also inherit the "enabled/disabled" state, but that the "enabled/disabled" state can be changed independently for each PeerConnection's local streams after the cloning?

  2. The remote streams and remote description for the CPC object will be set to empty.
  3. The CPC object will be set to the OPENING state to reflect that only the local description is set.
  4. The ICE states other than CLOSED and GATHERING will be handled independently for each PC and its clones (as is true in standard forking scenarios).
  5. The ICE state for this clone will be set to ICE_WAITING to reflect that all candidates are available but the remote configuration is not yet set.
  6. The PC and its clone(s) use a common pool of media resources.
  7. If the parent PC object has already released unused resources (final ANSWER), resources are reallocated as available to reflect the capabilities for each stream (as they would be reflected in a createOffer).
  8. The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.
So far, we've stayed away from anything that involves IP multicast. Are you sure it's worth the potential complexity to try to use this here?
Remember that using multicast changes a *lot* of things on both ends of the connections - the sender has to have IP multicast address allocations, he has to decide between SSM and ASM, the recipients have to use a multicast joining protocol, the infrastructure has to be present to carry the multicast groups, we have to have a fallback in case it isn't, the appropriate congestion control protocols are probably different ..... I would prefer to not bring this in scope for this round of WebRTC.
Is there a compelling reason you see for embarking on this particular adventure?

  2. The application should manage the directionality attributes for remote streams from different targets to avoid resource conflicts.

 

CPC will be used primarily if forking is anticipated or actually occurs.  It can also be used to clone a stable PC if desired for other reasons.  When used for SIP forking, creation of the clone can be delayed until an ANSWER actually arrives from a 2nd target as long as final ANSWER hasn’t been applied to the parent (PRANSWER is OK).  The parent always handles the first target; the first clone handles the 2nd target; etc.  The application can even try to clone for forking after the first ANSWER is applied to the parent and resources are released, as long as the local description has not changed, at the risk that some resources needed for the 2nd target are no longer available and must be renegotiated.

 

Comments on this proposal are welcome.

 

Richard

 


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

--------------030403050202050101030304-- From harald@alvestrand.no Mon May 7 14:46:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB021F870A for ; Mon, 7 May 2012 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 iVj6HmYh8+tV for ; Mon, 7 May 2012 14:46:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1DD21F86F1 for ; Mon, 7 May 2012 14:46:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C61F839E1E2; Mon, 7 May 2012 23:46:19 +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 SITVyAoQygNK; Mon, 7 May 2012 23:46:18 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A03EB39E107; Mon, 7 May 2012 23:46:18 +0200 (CEST) Message-ID: <4FA842A8.7070104@alvestrand.no> Date: Mon, 07 May 2012 23:46:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Dan Wing References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <4FA0F43E.4020308@ericsson.com> <4FA1575C.4050508@ericsson.com> <4FA37A1E.4080806@alvestrand.no> <0db701cd 2adb$98082f10$c8188d30$@com> <0dc901cd2ae3$f9ffb500$edff1f00$@com> <4FA83B3A.9070600@alvestr and.no> <027601cd2c97$b107e1a0$1317a4e0$@com> In-Reply-To: <027601cd2c97$b107e1a0$1317a4e0$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consent freshness and message-integrity (Re: Use Case draft - legacy interop) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:46:21 -0000 On 05/07/2012 11:23 PM, Dan Wing wrote: >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Monday, May 07, 2012 2:15 PM >> To: Dan Wing >> Cc: rtcweb@ietf.org >> Subject: Consent freshness and message-integrity (Re: [rtcweb] Use Case >> draft - legacy interop) >> >> Forking the thread, since this is a different detail..... >> >> On 05/05/2012 07:24 PM, Dan Wing wrote: >>> The other nuance is that, because >>> doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent >> freshness, >>> there is desire to allow those periodic ICE connectivity checks to >>> omit the MESSAGE-INTEGRITY, which is a change to ICE. See >>> draft-muthu-behave-consent-freshness. >> Omitting MESSAGE-INTEGRITY would allow off-path attackers to inject >> fake >> connectivity checks, and thus to simulate continued consent. > To successfully do that, those off-path attackers would have to guess > the random 96-bit STUN transaction-id. You're right, successfully replying to consent freshness packets requires read access to the consent freshness packets being sent (I was thinking that consent freshness was being generated from the recipient, not the sender, which is opposite to what draft-muthu does .... or rather, it's not clear to me what direction a successful request/response exchange verifies the freshness of). So it's an on-path attacker. I'll go take that argument to behave; I don't think that tradeoff is in the right place. From randell-ietf@jesup.org Mon May 7 14:54:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88421F846A for ; Mon, 7 May 2012 14:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 HdxW4S2mKjP8 for ; Mon, 7 May 2012 14:54:21 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A086C21F843E for ; Mon, 7 May 2012 14:54:21 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRVsq-0000hu-LD for rtcweb@ietf.org; Mon, 07 May 2012 16:54:20 -0500 Message-ID: <4FA84446.1000308@jesup.org> Date: Mon, 07 May 2012 17:53:10 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> In-Reply-To: <4FA83F6D.9040308@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:54:22 -0000 On 5/7/2012 5:32 PM, Harald Alvestrand wrote: > Richard, thank you for doing this! It's definitely the most > thought-through proposal I've seen on this question! Ditto! >> 5. The CPC object will inherit the local streams, local ICE >> candidates, and local description of the PC. >> > when it inherits the local streams, do you assume that unless the JS > applies some setting, they will also inherit the "enabled/disabled" > state, but that the "enabled/disabled" state can be changed > independently for each PeerConnection's local streams after the cloning? I would assume that personally, and that typically after cloning you'd do "appropriate" tweaking to new (and old). >> 8. The local streams might multicast toward the remote targets >> depending on the directionality attributes independently set for >> each PC and clone. >> > So far, we've stayed away from anything that involves IP multicast. Are > you sure it's worth the potential complexity to try to use this here? Richard - do you mean "IP Multicast" (tm) or 'multicast' by sending the same encoded data to more than one destination in separate RTP streams? (i.e. one encoding being used to simulcast to multiple receivers?) Simulcast is possible and useful (almost required for Mesh Conferencing); IP Multicast has been pretty much ruled out-of-scope IIRC. -- Randell Jesup randell-ietf@jesup.org From richard.ejzak@alcatel-lucent.com Mon May 7 17:59:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961721F847F for ; Mon, 7 May 2012 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.311 X-Spam-Level: X-Spam-Status: No, score=-7.311 tagged_above=-999 required=5 tests=[AWL=-0.713, 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 BvVa034iWxUM for ; Mon, 7 May 2012 17:59:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 17EDA21F8470 for ; Mon, 7 May 2012 17:59:23 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q480xLAf015024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 May 2012 19:59:22 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q480xLa2028035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 May 2012 19:59:21 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 7 May 2012 19:59:21 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Mon, 7 May 2012 19:59:20 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0smPDA2BOMigG/Q02npduDfRhMyQAG+mVg Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> In-Reply-To: <4FA83F6D.9040308@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0859USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 00:59:27 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0859USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Harald, Randell. Question 1: I have no strong opinion on whether each local stream should in= herit its parent's state or get reset to a default value, but inheriting th= e state seems cleaner (today). It must be possible to control the state of= each cloned local stream separately. Question 2: I should have been more careful in my choice of words. Randell= interpreted my meaning correctly. My meaning is better indicated with the= word "simulcast", as Randell suggests. I NEVER intended the use of "IP mu= lticast addressing". Richard ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Monday, May 07, 2012 4:32 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for PeerConnection cloning Richard, thank you for doing this! It's definitely the most thought-through= proposal I've seen on this question! Two questions that are different from what others have raised: On 05/06/2012 08:54 PM, Ejzak, Richard P (Richard) wrote: Harald asked for a proposal for PeerConnection cloning, so here it goes: I propose to create a new constructor "ClonePeerConnection" (CPC below) wit= h the following semantics. 1. CPC will create a new PeerConnection object when successful. The resu= lting PC behaves just like any other PC except as described below. 2. CPC will take as input a reference to an existing PeerConnection (PC) = object (no configuration or IceCallback parameters). 3. CPC can clone any other PC (including a cloned PC). The sequence of c= loning is not important and parents have no particular status different fro= m any generation of clone. 4. CPC will fail if either the local description of the parent PC is not = set or the parent PC ICE is in ICE_CLOSED or ICE_GATHERING state. The pare= nt PC can be in the OPENING or ACTIVE state. 5. The CPC object will inherit the local streams, local ICE candidates, a= nd local description of the PC. when it inherits the local streams, do you assume that unless the JS applie= s some setting, they will also inherit the "enabled/disabled" state, but th= at the "enabled/disabled" state can be changed independently for each PeerC= onnection's local streams after the cloning? 1. 2. The remote streams and remote description for the CPC object will be s= et to empty. 3. The CPC object will be set to the OPENING state to reflect that only t= he local description is set. 4. The ICE states other than CLOSED and GATHERING will be handled indepen= dently for each PC and its clones (as is true in standard forking scenarios= ). 5. The ICE state for this clone will be set to ICE_WAITING to reflect tha= t all candidates are available but the remote configuration is not yet set. 6. The PC and its clone(s) use a common pool of media resources. 7. If the parent PC object has already released unused resources (final A= NSWER), resources are reallocated as available to reflect the capabilities = for each stream (as they would be reflected in a createOffer). 8. The local streams might multicast toward the remote targets depending = on the directionality attributes independently set for each PC and clone. So far, we've stayed away from anything that involves IP multicast. Are you= sure it's worth the potential complexity to try to use this here? Remember that using multicast changes a *lot* of things on both ends of the= connections - the sender has to have IP multicast address allocations, he = has to decide between SSM and ASM, the recipients have to use a multicast j= oining protocol, the infrastructure has to be present to carry the multicas= t groups, we have to have a fallback in case it isn't, the appropriate cong= estion control protocols are probably different ..... I would prefer to not= bring this in scope for this round of WebRTC. Is there a compelling reason you see for embarking on this particular adven= ture? 1. 2. The application should manage the directionality attributes for remote= streams from different targets to avoid resource conflicts. CPC will be used primarily if forking is anticipated or actually occurs. I= t can also be used to clone a stable PC if desired for other reasons. When= used for SIP forking, creation of the clone can be delayed until an ANSWER= actually arrives from a 2nd target as long as final ANSWER hasn't been app= lied to the parent (PRANSWER is OK). The parent always handles the first t= arget; the first clone handles the 2nd target; etc. The application can ev= en try to clone for forking after the first ANSWER is applied to the parent= and resources are released, as long as the local description has not chang= ed, at the risk that some resources needed for the 2nd target are no longer= available and must be renegotiated. Comments on this proposal are welcome. Richard _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0859USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Harald, Randell.

 

Question 1: I have no strong opinion o= n whether each local stream should inherit its parent’s state or get re= set to a default value, but inheriting the state seems cleaner (today).  I= t must be possible to control the state of each cloned local stream separatel= y.

 

Question 2: I should have been more careful in my choice of words.  Randell interpreted my meaning correctly.  My meaning is better indicated with the word “simulc= ast”, as Randell suggests.  I NEVER intended the use of “IP multicast addressing”.

 

Richard

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]= On Behalf Of Harald Alvestrand
Sent: Monday, May 07, 2012 4= :32 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Propos= al for PeerConnection cloning

 

Richard, thank you for doing this! It's definite= ly the most thought-through proposal I've seen on this question!

Two questions that are different from what others have raised:

On 05/06/2012 08:54 PM, Ejzak, Richard P (Richard) wrote:

Harald asked for a proposal for PeerConnection cloning, s= o here it goes:

 

I propose to create a new constructor “ClonePeerConnection” (CPC below) with the following semantics.=

 

  1. CPC wi= ll create a new PeerConnection object when successful.  The resultin= g PC behaves just like any other PC except as described below.=
  2. CPC wi= ll take as input a reference to an existing PeerConnection (PC) object (no configuration or IceCallback parameters).
  3. CPC ca= n clone any other PC (including a cloned PC).  The sequence of cloning is= not important and parents have no particular status different from any generation of clone.
  4. CPC wi= ll fail if either the local description of the parent PC is not set or the par= ent PC ICE is in ICE_CLOSED or ICE_GATHERING state.  The parent PC ca= n be in the OPENING or ACTIVE state.<= /li>
  5. The CP= C object will inherit the local streams, local ICE candidates, and local description of the PC.

= when it inherits t= he local streams, do you assume that unless the JS applies some setting, they = will also inherit the "enabled/disabled" state, but that the "enabled/disabled" state can be changed independently for each PeerConnection's local streams after the cloning?

  1. <= o:p> 
  2. The re= mote streams and remote description for the CPC object will be set to empty= .
  3. The CP= C object will be set to the OPENING state to reflect that only the local description is set.
  4. The IC= E states other than CLOSED and GATHERING will be handled independently for each= PC and its clones (as is true in standard forking scenarios).
  5. The IC= E state for this clone will be set to ICE_WAITING to reflect that all candidat= es are available but the remote configuration is not yet set.
  6. The PC= and its clone(s) use a common pool of media resources.
  7. If the= parent PC object has already released unused resources (final ANSWER), resour= ces are reallocated as available to reflect the capabilities for each stre= am (as they would be reflected in a createOffer).
  8. The lo= cal streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.

= So far, we've stay= ed away from anything that involves IP multicast. Are you sure it's worth the potential complexity to try to use this here?
Remember that using multicast changes a *lot* of things on both ends of the connections - the sender has to have IP multicast address allocations, he h= as to decide between SSM and ASM, the recipients have to use a multicast joini= ng protocol, the infrastructure has to be present to carry the multicast group= s, we have to have a fallback in case it isn't, the appropriate congestion con= trol protocols are probably different ..... I would prefer to not bring this in scope for this round of WebRTC.
Is there a compelling reason you see for embarking on this particular adventure?

  1. <= o:p> 
  2. The ap= plication should manage the directionality attributes for remote streams from different targets to avoid resource conflicts.

 

CPC will be used primarily if forking is anticipa= ted or actually occurs.  It can also be used to clone a stable PC if desir= ed for other reasons.  When used for SIP forking, creation of the clone can b= e delayed until an ANSWER actually arrives from a 2nd target as lo= ng as final ANSWER hasn’t been applied to the parent (PRANSWER is OK).  The parent always handles the first target; the first clone handles t= he 2nd target; etc.  The application can even try to clone for forking after = the first ANSWER is applied to the parent and resources are released, as long a= s the local description has not changed, at the risk that some resources need= ed for the 2nd target are no longer available and must be renegotia= ted.

 

Comments on this proposal are welcome.

 

Richard

 

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



=
 <=
/span>
--_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0859USNAVSXCHMBSA_-- From roman@telurix.com Mon May 7 18:36:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB3721F85CE for ; Mon, 7 May 2012 18:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.095, 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 tnMTWuKUD5K0 for ; Mon, 7 May 2012 18:36:41 -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 0E47521F8534 for ; Mon, 7 May 2012 18:36:40 -0700 (PDT) Received: by werf13 with SMTP id f13so2985631wer.31 for ; Mon, 07 May 2012 18:36: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4jsy66Tramj+suDc7wpyVglgit+ic9Mdn40rDm7p+o4=; b=JMPo13MpF2P4RlbM0RF6cRGMf4aJq/0EnlcSkfMX7n4mgKaN8Ct21e0vY5bMPCIQ0d d/WyUqPOr3SoHtvOdwTPLM8gNjexXem0UMqRYxvnmf+57PYFXF2eR8MNCtBSkTOpcKJI wkP9cVm+yUEuTW7XRfqBzI3s24JO1ct5TE26hdxjroTFNkgNiT44ZyISmRDNGbIIqIyu Rz4mOJ7PSYQqO0gkpdGtCTnsXEv7cFviYPb3VFxhfIh8Q7/Ah7DxKfB5P8Z9sg1HNKPM eoWVL3WNnsYKOYzIHY+5ekytLjhPQnqDDXiMUkQsr/5T5Qz7YVKkSwbB9TsOqZtxa56k aQTw== Received: by 10.180.86.194 with SMTP id r2mr32861092wiz.15.1336441000173; Mon, 07 May 2012 18:36:40 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id u9sm25680379wix.0.2012.05.07.18.36.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 18:36:38 -0700 (PDT) Received: by bkty8 with SMTP id y8so5052860bkt.31 for ; Mon, 07 May 2012 18:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.134.6 with SMTP id ia6mr976435bkc.51.1336440997639; Mon, 07 May 2012 18:36:37 -0700 (PDT) Received: by 10.205.117.146 with HTTP; Mon, 7 May 2012 18:36:37 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 7 May 2012 21:36:37 -0400 Message-ID: From: Roman Shpount To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=000e0ce0d862ed747e04bf7c6ae0 X-Gm-Message-State: ALoCoQk4y8JHMUxxjitMKwLvckmDJ0pl/CRWcdUNFDwuL25tBohRob7fb82nn4RKDe294YPMNHYY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 01:36:43 -0000 --000e0ce0d862ed747e04bf7c6ae0 Content-Type: text/plain; charset=ISO-8859-1 One question I have is when should TURN allocations be released? TURN would not be used for 99% of PeerConnections but it cannot be released until it is guaranteed that the offer that used this TURN candidate would not be used to create any more PeerConnections. We would need a separate method to release the TURN candidates, which can be complicated by the fact that you can have several offers for a given peerconnection in progress, each with its own TURN candidates that can have overlapping lifetimes. I would actually think that the model where an offer object is created and each PeerConnection is created using the offer object and the answer would be cleaner. One way to implement this, is to define a factory object is used to create offers. SDP is extracted from an offer object. Once answer is received, a method in the offer object is used to create the PeerConnection. Once no more answers are expected offer object should be released. The other option, that would be less disruptive to the curretn API, is that instead of cloning peerconnection method, a method that returns reference to the current offer is used. A cloned peerconnection can be created using this offer. Once final answer is processed by the peerconnection, offer object is released by it. If multiple answers are expected, offer object can be retrieved using the get offer method and stored separately until the moment when answers for this particular offer a no longer expected. _____________ Roman Shpount --000e0ce0d862ed747e04bf7c6ae0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One question I have is when should TURN allocations be released? TURN would= not be used for 99% of PeerConnections but it cannot be released until it = is guaranteed that the offer that used this TURN candidate would not be use= d to create any more PeerConnections. We would need a separate method to re= lease the TURN candidates, which can be complicated by the fact that you ca= n have several offers for a given peerconnection in progress, each with its= own TURN candidates that can have overlapping lifetimes.

I would actually think that the model where an offer object is created = and each PeerConnection is created=A0 using the offer object and the answer= would be cleaner.

One way to implement this, is to define a factor= y object is used to create offers. SDP is extracted from an offer object. O= nce answer is received, a method in the offer object is used to create the = PeerConnection. Once no more answers are expected offer object should be re= leased.

The other option, that would be less disruptive to the curretn API,=A0 = is that instead of cloning peerconnection method, a method that returns ref= erence to the current offer is used. A cloned peerconnection can be created= using this offer. Once final answer is processed by the peerconnection, of= fer object is released by it. If multiple answers are expected, offer objec= t can be retrieved using the get offer method and stored separately until t= he moment when answers for this particular offer a no longer expected.
_____________
Roman Shpount

--000e0ce0d862ed747e04bf7c6ae0-- From richard.ejzak@alcatel-lucent.com Mon May 7 19:10:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBF621F8631 for ; Mon, 7 May 2012 19:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.232 X-Spam-Level: X-Spam-Status: No, score=-7.232 tagged_above=-999 required=5 tests=[AWL=-0.633, 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 C0L79LxTJZXV for ; Mon, 7 May 2012 19:10:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFEC21F8615 for ; Mon, 7 May 2012 19:10:59 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q482Aw6c012317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 May 2012 21:10:58 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q482AvaO023131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 May 2012 21:10:58 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 7 May 2012 21:10:58 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Mon, 7 May 2012 21:10:56 -0500 Thread-Topic: [rtcweb] Proposal for PeerConnection cloning Thread-Index: Ac0suwWDStY/ZEhsRMKulO5M+p1c7AAASEbQ Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.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_6F428EFD2B8C2F49A2FB1317291A76C11364EC0881USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 02:11:00 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0881USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You raise a good point since some candidates may be released before cloning= occurs. So this is another bug in the procedure. I would suggest that th= e configuration also be passed to the CPC and that if any of the required c= andidates are released before cloning occurs that they be reallocated. Alternately, we could recommend that candidates be kept allocated longer th= an usual and that if cloning is attempted after any of the candidates are r= eleased then the cloning procedure fails. The latter approach should be sufficient for SIP forking scenarios, but oth= ers may prefer the generality of the former. Or maybe both? Any votes? Richard ________________________________ From: Roman Shpount [mailto:roman@telurix.com] Sent: Monday, May 07, 2012 8:37 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposal for PeerConnection cloning One question I have is when should TURN allocations be released? TURN would= not be used for 99% of PeerConnections but it cannot be released until it = is guaranteed that the offer that used this TURN candidate would not be use= d to create any more PeerConnections. We would need a separate method to re= lease the TURN candidates, which can be complicated by the fact that you ca= n have several offers for a given peerconnection in progress, each with its= own TURN candidates that can have overlapping lifetimes. I would actually think that the model where an offer object is created and = each PeerConnection is created using the offer object and the answer would= be cleaner. One way to implement this, is to define a factory object is used to create = offers. SDP is extracted from an offer object. Once answer is received, a m= ethod in the offer object is used to create the PeerConnection. Once no mor= e answers are expected offer object should be released. The other option, that would be less disruptive to the curretn API, is tha= t instead of cloning peerconnection method, a method that returns reference= to the current offer is used. A cloned peerconnection can be created using= this offer. Once final answer is processed by the peerconnection, offer ob= ject is released by it. If multiple answers are expected, offer object can = be retrieved using the get offer method and stored separately until the mom= ent when answers for this particular offer a no longer expected. _____________ Roman Shpount --_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0881USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You raise a good point since some candidates may be released before cloning occurs.  So this is another = bug in the procedure.  I would suggest that the configuration also be pass= ed to the CPC and that if any of the required candidates are released before cloning occurs that they be reallocated.

 

Alternately, we could recommend that candidates be kept allocated longer than usual and that if cloning is attem= pted after any of the candidates are released then the cloning procedure fails.<= o:p>

 

The latter approach should be sufficie= nt for SIP forking scenarios, but others may prefer the generality of the form= er.  Or maybe both?  Any votes?

 

Richard

 

From: Roman Sh= pount [mailto:roman@telurix.com]
Sent: Monday, May 07, 2012 8= :37 PM
To: Ejzak, Richard P (Richar= d)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Propos= al for PeerConnection cloning

 

One question I ha= ve is when should TURN allocations be released? TURN would not be used for 99% of PeerConnections but it cannot be released until it is guaranteed that the o= ffer that used this TURN candidate would not be used to create any more PeerConn= ections. We would need a separate method to release the TURN candidates, which can b= e complicated by the fact that you can have several offers for a given peerconnection in progress, each with its own TURN candidates that can have overlapping lifetimes.

I would actually think that the model where an offer object is created and = each PeerConnection is created  using the offer object and the answer would= be cleaner.

One way to implement this, is to define a factory object is used to create offers. SDP is extracted from an offer object. Once answer is received, a method in the offer object is used to create the PeerConnection. Once no mo= re answers are expected offer object should be released.

The other option, that would be less disruptive to the curretn API,  i= s that instead of cloning peerconnection method, a method that returns refere= nce to the current offer is used. A cloned peerconnection can be created using = this offer. Once final answer is processed by the peerconnection, offer object i= s released by it. If multiple answers are expected, offer object can be retrieved usin= g the get offer method and stored separately until the moment when answers fo= r this particular offer a no longer expected.
_____________
Roman Shpount

--_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0881USNAVSXCHMBSA_-- From stefan.lk.hakansson@ericsson.com Mon May 7 23:51:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C721F861B for ; Mon, 7 May 2012 23:51:10 -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 BT1pFli7vFtn for ; Mon, 7 May 2012 23:51:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC721F860E for ; Mon, 7 May 2012 23:51:09 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-0c-4fa8c25a2845 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.05.32015.A52C8AF4; Tue, 8 May 2012 08:51:06 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 08:51:06 +0200 Message-ID: <4FA8C259.7060904@ericsson.com> Date: Tue, 8 May 2012 08:51:05 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <4FA84446.1000308@jesup.org> In-Reply-To: <4FA84446.1000308@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 06:51:10 -0000 On 05/07/2012 11:53 PM, Randell Jesup wrote: > On 5/7/2012 5:32 PM, Harald Alvestrand wrote: >> Richard, thank you for doing this! It's definitely the most >> thought-through proposal I've seen on this question! > > Ditto! > >>> 5. The CPC object will inherit the local streams, local ICE >>> candidates, and local description of the PC. >>> >> when it inherits the local streams, do you assume that unless the JS >> applies some setting, they will also inherit the "enabled/disabled" >> state, but that the "enabled/disabled" state can be changed >> independently for each PeerConnection's local streams after the cloning? > > I would assume that personally, and that typically after cloning you'd > do "appropriate" tweaking to new (and old). As the APIs are designed right now, this is not possible AFAIK. The "local streams" is more or less just a list of the streams that has been added to the PeerConnection (PC) using "addStream". So if you have one PC with one MediaStream added, then clones the PC, the result would be that that MediaStream now has two consumers. And if you disable a track, that track would be disabled for all consumers. I think a more flexible solution would be that the new PC does _not_ inherit the streams. This way the application can choose to clone the MediaStream's attached to the first PC, and add the cloned MS's to the new PC, and thereby get independent control of e.g. enable/disable state. After all, it is the application that initiates the PC cloning, so it knows exactly when it happens and the context, so adding the req. to the app to add the stream(s) that should be added would not make it more complex IMO. The possible problem I can see with this approach is that if the set of MS's added to the cloned PC is not exactly the same as for the original PC, the number of ICE connections needed might not match. But is that problem not already there, and must be handled by the ICE agent? The cloned PC may connect to an endpoint that does not support multiplexing of RTP-streams, or new streams might be added to the cloned PC at any time after cloning. > >>> 8. The local streams might multicast toward the remote targets >>> depending on the directionality attributes independently set for >>> each PC and clone. >>> >> So far, we've stayed away from anything that involves IP multicast. Are >> you sure it's worth the potential complexity to try to use this here? > > Richard - do you mean "IP Multicast" (tm) or 'multicast' by sending the > same encoded data to more than one destination in separate RTP streams? > (i.e. one encoding being used to simulcast to multiple receivers?) > > Simulcast is possible and useful (almost required for Mesh > Conferencing); IP Multicast has been pretty much ruled out-of-scope IIRC. > From harald@alvestrand.no Tue May 8 00:57:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219B021F8606 for ; Tue, 8 May 2012 00:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 N1IN+P9KCv4X for ; Tue, 8 May 2012 00:57:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E45E621F85D8 for ; Tue, 8 May 2012 00:57:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CB9E39E1FC for ; Tue, 8 May 2012 09:57:45 +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 XwYKji-cV+VK for ; Tue, 8 May 2012 09:57:43 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A879939E0F3 for ; Tue, 8 May 2012 09:57:43 +0200 (CEST) Message-ID: <4FA8D1F6.4010103@alvestrand.no> Date: Tue, 08 May 2012 09:57:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FA3754D.6020004@ericsson.com> <4FA40C0F.3000702@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000700000304060305050109" Subject: [rtcweb] SAVPF history (Re: Final plea about SRTP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 07:57:52 -0000 This is a multi-part message in MIME format. --------------000700000304060305050109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/04/2012 07:45 PM, Roman Shpount wrote: > > On Fri, May 4, 2012 at 1:04 PM, Randell Jesup > wrote: > > You forget that bid-down includes bid-downs by the JS or server > (which are not trusted in our model), not just by on-path attackers. > > > If your session is initiated by HTTPS, using RTP should not be an > option (the same way as using HTTP from HTTPS is not normally an > option). If your session is HTTP, whole application can be spoofed, so > there is no security to begin with. > > I used to work on hardware endpoints that have been using SAVPF > since 2004, with hundreds of thousands of units in the field. > > > I thought SAVPF was only standardized in 2008 and AVPF was > standardized in 2006. AVPF was discussed for a while though, so I > would assumed you worked with something that implemented one of the > drafts... The -00 version of the SAVPF draft is dated 19 October 2003. According to https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/ publication was requested in February 2006, and it was approved by the IESG in November 2007. The publication delay was 3 months. The technical changes that resulted from these 4 years of work can be seen here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt Harald --------------000700000304060305050109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 05/04/2012 07:45 PM, Roman Shpount wrote:

On Fri, May 4, 2012 at 1:04 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
You forget that bid-down includes bid-downs by the JS or server (which are not trusted in our model), not just by on-path attackers.

If your session is initiated by HTTPS, using RTP should not be an option (the same way as using HTTP from HTTPS is not normally an option). If your session is HTTP, whole application can be spoofed, so there is no security to begin with.

I used to work on hardware endpoints that have been using SAVPF since 2004, with hundreds of thousands of units in the field.

I thought SAVPF was only standardized in 2008 and AVPF was standardized in 2006. AVPF was discussed for a while though, so I would assumed you worked with something that implemented one of the drafts... 
The -00 version of the SAVPF draft is dated 19 October 2003.

According to https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/ publication was requested in February 2006, and it was approved by the IESG in November 2007. The publication delay was 3 months.

The technical changes that resulted from these 4 years of work can be seen here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt

                        Harald

--------------000700000304060305050109-- From mperumal@cisco.com Tue May 8 03:20:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE021F8592 for ; Tue, 8 May 2012 03:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 hOJCgGPglFCt for ; Tue, 8 May 2012 03:20:11 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB0E21F855B for ; Tue, 8 May 2012 03:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4659; q=dns/txt; s=iport; t=1336472410; x=1337682010; h=mime-version:subject:date:message-id:from:to; bh=QUiAc76EQIXNj9vC+nSZ2aTWjkDC3pvmr6KIE1ru5zY=; b=ZFQXoBEsTO4BqrkBTQOhvIJ1EEPSlJ2uhH6v1jVHt+nugwnTvwUg5foV wFBvNe0lLoXBe0bxQx4NRAFyW1v4MCO/7vBLBQ3KWdOo4R2sjl3gFA3er 7k1bbzG7FzYxFdCEbK38mWmUAdrs9zoQhooxgan62qJ/iVVoMYrnwbyYf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAL7yqE9Io8UY/2dsb2JhbABEgkaxZoIOAQQSAQkRA1sBKgYYB1cBBAsQGodsmUKBKKA4jWaCQ2MEiGKbdYFpgnE X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208,217";a="11698294" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 08 May 2012 10:20:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q48AK7VM001223 for ; Tue, 8 May 2012 10:20:07 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 15:50:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2D04.2432EA0C" Date: Tue, 8 May 2012 15:50:06 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020865B54D@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consent freshness - interaction with SDP direction attributes Thread-Index: Ac0tBCPSRkI2gF0yT9qNu1ywo1sR0w== From: "Muthu Arul Mozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 08 May 2012 10:20:07.0545 (UTC) FILETIME=[24484E90:01CD2D04] Subject: [rtcweb] Consent freshness - interaction with SDP direction attributes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 10:20:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2D04.2432EA0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was thinking what the interaction between the SDP direction attributes and the generation of consent freshness (described in draft-muthu-behave-consent-freshness-00) should be, in response to some questions posted by Harald. My thought is that the direction attributes in SDP should have no impact on the generation of consent freshness. As far as the media connection address and port are valid, the browser should continue to generate consent freshness requests, irrespective of whether the stream is sendonly, recvonly, sendrecv or inactive, analogous to RTCP. =20 This would: - Eliminate the need for the browser to depend on the (untrusted) JS to tell it when to stop/start generating consent requests. - Keep the NAT bindings always alive. =20 Comments? =20 Muthu =20 ------_=_NextPart_001_01CD2D04.2432EA0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was thinking what = the interaction between the SDP direction attributes and the generation = of consent freshness (described in = draft-muthu-behave-consent-freshness-00) should be, in response to some = questions posted by Harald. My thought is that the direction attributes = in SDP should have no impact on the generation of consent freshness. As = far as the media connection address and port are valid, the browser = should continue to generate consent freshness requests, irrespective of = whether the stream is sendonly, recvonly, sendrecv or inactive, = analogous to RTCP.

 

This = would:

- Eliminate the = need for the browser to depend on the (untrusted) JS to tell it when to = stop/start generating consent requests.

- Keep the NAT bindings always alive.

 

Comments?

 

Muthu

 

------_=_NextPart_001_01CD2D04.2432EA0C-- From roman@telurix.com Tue May 8 06:34:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4889B21F84E2 for ; Tue, 8 May 2012 06:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 zUKaQoKi712i for ; Tue, 8 May 2012 06:34:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E72C221F852A for ; Tue, 8 May 2012 06:34:09 -0700 (PDT) Received: by bkty8 with SMTP id y8so5579201bkt.31 for ; Tue, 08 May 2012 06:34:06 -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=U6imLYIHaIoLO28b1fRav44fGpsVMphmk3Gxfr18+IE=; b=JHiWeEkqP9b7W0Al34LrhT5YAd573xsBhXUKJn/iENcoxY0Rko1mUSlFN/2L6BuX4l MK7GdNPETjeU0WvuxvTJ8iIgvr++hmieJj0h3OCeeXRjAiNjAnqxEi1op9SFjjhIXjqh T0D+TJXYMi7O1KG4C/MAnwqKqWkgupRbA84+FArjFcf39ksQUaFYMpSSeBNiCmE0X32W A6YeLhzKqapI9CMT42cwYD+7zR6P4d3O/dxins+2j3ONS/z9Fi2m+qAVSUwUh3CcILVa gDqTx5JEvoWagodmDlEgDVXTyjuvCP0vBsofhHHFZLafaDsiA+hXpXn3MB9MQ4sX4Oxw wMkQ== Received: by 10.204.129.17 with SMTP id m17mr6997021bks.4.1336484046303; Tue, 08 May 2012 06:34:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id h18sm39006018bkh.8.2012.05.08.06.34.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 06:34:05 -0700 (PDT) Received: by bkty8 with SMTP id y8so5579149bkt.31 for ; Tue, 08 May 2012 06:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.152.70 with SMTP id f6mr6554820bkw.7.1336484043576; Tue, 08 May 2012 06:34:03 -0700 (PDT) Received: by 10.205.117.146 with HTTP; Tue, 8 May 2012 06:34:03 -0700 (PDT) In-Reply-To: <4FA8D1F6.4010103@alvestrand.no> References: <4FA3754D.6020004@ericsson.com> <4FA40C0F.3000702@jesup.org> <4FA8D1F6.4010103@alvestrand.no> Date: Tue, 8 May 2012 09:34:03 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001517592bfcaa56f404bf86707d X-Gm-Message-State: ALoCoQk4x1/FKSpZBYuOd7a7/1wMol1MpWnFi0Ga5greYqjJ1KN/LSQmNLBUTj2bzWXAbDsjKM+O Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SAVPF history (Re: Final plea about SRTP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 13:34:11 -0000 --001517592bfcaa56f404bf86707d Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 8, 2012 at 3:57 AM, Harald Alvestrand wrote: > ** > On 05/04/2012 07:45 PM, Roman Shpount wrote: > > I used to work on hardware endpoints that have been using SAVPF since > 2004, with hundreds of thousands of units in the field. > >> > I thought SAVPF was only standardized in 2008 and AVPF was standardized in > 2006. AVPF was discussed for a while though, so I would assumed you worked > with something that implemented one of the drafts... > > The -00 version of the SAVPF draft is dated 19 October 2003. > > According to > https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/publication was requested in February 2006, and it was approved by the IESG > in November 2007. The publication delay was 3 months. > > The technical changes that resulted from these 4 years of work can be seen > here: > > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt > > I would say that something that changes to rfc4585 would be more relevant. Regardless of the actual changes in the draft, my point is there are very few actual SIP devices that implement SAVPF or AVPF. Specifying this as the only profile supported by WebRTC will create yet another challenge to legacy interop, since it will require not only processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP re-generation. _____________ Roman Shpount --001517592bfcaa56f404bf86707d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 8, 2012 at 3:57 AM= , Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 05/04/2012 07:45 PM, Roman Shpount wrote:
I used to work on hardware endpoints that hav= e been using SAVPF since 2004, with hundreds of thousands of units in the field.

I thought SAVPF was only standardized in 2008 and AVPF was standardized in 2006. AVPF was discussed for a while though, so I would assumed you worked with something that implemented one of the drafts...=A0
The -00 version of the SAVPF draft is dated 19 October 2003.

According to https://datatracker.ietf.org/doc= /draft-ietf-avt-profile-savpf/history/ publication was requested in February 2006, and it was approved by the IESG in November 2007. The publication delay was 3 months.

The technical changes that resulted from these 4 years of work can be seen here:

http://tools.ietf.org/rfcdiff?difftype=3D--hw= diff&url1=3Ddraft-ietf-avt-profile-savpf-00.txt&url2=3Ddraft-ietf-a= vt-profile-savpf-12.txt<= br> =A0=A0=A0

I would say th= at something that changes to rfc4585 would be more relevant. Regardless of = the actual changes in the draft, my point is there are very few actual SIP = devices that implement SAVPF or AVPF. Specifying this as the only profile s= upported by WebRTC will create yet another challenge to legacy interop, sin= ce it will require not only processing of ICE messages, and DTLS-SRTP re-en= coding, but also RTCP re-generation.
_____________
Roman Shpount

--001517592bfcaa56f404bf86707d-- From roman@telurix.com Tue May 8 06:40:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83221F84F0 for ; Tue, 8 May 2012 06:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 u4rI-6CiniXc for ; Tue, 8 May 2012 06:40:34 -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 58A9E21F847F for ; Tue, 8 May 2012 06:40:34 -0700 (PDT) Received: by werf13 with SMTP id f13so3408857wer.31 for ; Tue, 08 May 2012 06:40:33 -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=vXNCIMjurtGkfVcH7mdAeS3lCxNyU1o/i2NiMH39+bg=; b=e4wPA9EXS6zaxjlJPae2m1NfbakJH/ZglVvnJ+E5zmFbXX2GSKLmrUVasajvZ/S7fc kwPW/YVzGpGOq2FXi2g3aqSVuDQ/qmxJ2fAPmbpHmfGkyAMbirudazOUWtOlmV7kgAwG m6/8/G/fY8dmtbgbSIVsKAMLE5wXECs485dFYy2/s2oWgtQobm6ywMsADwYqilH43qIS W0jxX+KtZBFYrvFdroR8AMIzHx0wqVpezNtQtVssMU1DpSj047OrBazpkooXfVqTGtBq ddie4iIfaFq6SmnVI62ne4lLt2USjAhgJ3boo7oeDTkUqMq9UPUuAA+6L0Eyy8O2yb+D B+jg== Received: by 10.180.89.9 with SMTP id bk9mr44804049wib.11.1336484433532; Tue, 08 May 2012 06:40:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id fo7sm27784807wib.9.2012.05.08.06.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 06:40:31 -0700 (PDT) Received: by bkty8 with SMTP id y8so5586705bkt.31 for ; Tue, 08 May 2012 06:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.157.144 with SMTP id b16mr6995701bkx.12.1336484430625; Tue, 08 May 2012 06:40:30 -0700 (PDT) Received: by 10.205.117.146 with HTTP; Tue, 8 May 2012 06:40:30 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 8 May 2012 09:40:30 -0400 Message-ID: From: Roman Shpount To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=0015175cd0dabc3c2304bf868771 X-Gm-Message-State: ALoCoQk0GMjFunjlMIzaUih2stPx/EjIMML7IhamzNXaluiloIBMCTyLZaO+C8dTFiUxMUjy9TLc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 13:40:35 -0000 --0015175cd0dabc3c2304bf868771 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 10:10 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > You raise a good point since some candidates may be released before > cloning occurs. So this is another bug in the procedure. I would suggest > that the configuration also be passed to the CPC and that if any of the > required candidates are released before cloning occurs that they be > reallocated.**** > > ** ** > > Alternately, we could recommend that candidates be kept allocated longer > than usual and that if cloning is attempted after any of the candidates are > released then the cloning procedure fails.**** > > ** ** > > The latter approach should be sufficient for SIP forking scenarios, but > others may prefer the generality of the former. Or maybe both? Any votes? > **** > > ** ** > My suggestion was that instead of the clone method to have a method that returns reference to the offer object. This separate object holds the candidates while references to it exist. When this object is passed during creation of peer connection, peer connection is initialized as a clone of an existing peer connection This way application has the explicit control of the ICE candidate lifetimes. I would think this would be the most flexible. _____________ Roman Shpount --0015175cd0dabc3c2304bf868771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
_____________
Roman Shpount
--0015175cd0dabc3c2304bf868771-- From magnus.westerlund@ericsson.com Tue May 8 06:49:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B6721F84AA for ; Tue, 8 May 2012 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.138 X-Spam-Level: X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPisH0nkopDd for ; Tue, 8 May 2012 06:49:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2462021F8499 for ; Tue, 8 May 2012 06:49:32 -0700 (PDT) X-AuditID: c1b4fb30-b7c78ae000006de5-5d-4fa9246bb7dc Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 79.01.28133.B6429AF4; Tue, 8 May 2012 15:49:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 15:49:31 +0200 Message-ID: <4FA9246A.1060805@ericsson.com> Date: Tue, 8 May 2012 15:49:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roman Shpount References: <4FA3754D.6020004@ericsson.com> <4FA40C0F.3000702@jesup.org> <4FA8D1F6.4010103@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SAVPF history (Re: Final plea about SRTP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 13:49:34 -0000 On 2012-05-08 15:34, Roman Shpount wrote: > I would say that something that changes to rfc4585 would be more > relevant. Regardless of the actual changes in the draft, my point is > there are very few actual SIP devices that implement SAVPF or AVPF. > Specifying this as the only profile supported by WebRTC will create yet > another challenge to legacy interop, since it will require not only > processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP > re-generation. Hi, Here I have to protest that it increases the barrier. First of all the S in SAVPF is for using SRTP. That is already agreed on in this WG. Secondly the F stands for the feedback part. That consists of two parts: 1) New Timer Rules 2) Feedback RTCP packets The second is actually negotiated on a per individual feedback format basis. So only the first is what really what would be mandated by a WebRTC requirement of SAVPF. From my perspective to get the RTP/RTCP functionalities needed to give a good user experience we really need the timing rules. When it comes to legacy interop a signalling gateway can actually produce a SAVPF configuration that is fully interopable with an SAVP end-point. The configuration required to make this interoperable are: use a=rtcp-fb to sett trr-int to 3.5 to 4 seconds and ensure that the same or at least sufficient RTCP bandwidth is configured and that no feedback format are agreed on being used. So please don't be afraid of SAVPF. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From juberti@google.com Tue May 8 07:46:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC28521F8643 for ; Tue, 8 May 2012 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dei8MlmYttxi for ; Tue, 8 May 2012 07:46:54 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id C57C721F8617 for ; Tue, 8 May 2012 07:46:53 -0700 (PDT) Received: by qabj40 with SMTP id j40so692090qab.15 for ; Tue, 08 May 2012 07:46:53 -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:x-system-of-record; bh=CYhxcVbL3mlTO1MH/P3Gu1gYwy3gMCt3ELfVlT+2DWg=; b=dYHQBOhG4cXAjbOq3XXpTTIahyec6NpfTAfUb793dV3vWCAx3a8M41o7AJTDPg/YzQ zHvQznpE2tIbts1ZaOS0w2PMschomi8uW2iQAM9lkiQnbaoUL1F4AonSWRb3l7IPu3mZ zwXuvvxjyCUOH3GxvB06VFnzBo6w6RErjvbzG8aUsY/plHbvdD+2C4/eWvW/XYUo6vS5 9+Sitjgj+5rDL7gK6LguRwsoyFrichX67rrCVEvMtm/Vnt0a3WJyi3yjohnenCCzJ0Oy kp9GHvbwxYD8OLjaegHvhfwwWT6IiKuGEcUqRubWOQq+uMlB4hLRb6cmpRGnRM6IiENX VW6g== 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-system-of-record:x-gm-message-state; bh=CYhxcVbL3mlTO1MH/P3Gu1gYwy3gMCt3ELfVlT+2DWg=; b=fyOOk/O/rd8RH0KSn7Uhs+wrHrjc6zre5UMWfNxH97IdPLsTWQy26cChbE52JhQgL8 3PF1JVrHmOcZRcauF2N42bkxXEISxLL2yjLW1h8JGNmDYlAkQRiIX1rCU0in1xxXX8pP z2mcLaGom8vrv/05ZLS2itaXI6gf309IqHHeTEXXGbDkN+3lPMvPbEIYKKhyQcA+ch8g n4XdQwM0FCNM9LhCsbmNRs99nv7GzgeliEOCafIc4QqF8Yo/+PxeUFPCruy8CVsrk5Ry TSVhgu0D9oi3fcCwx+9EeuULOuTymGqzJKAGj+GhuanSGYVKwUysC7x/+32Lj/GxnUb8 8FPA== Received: by 10.224.101.72 with SMTP id b8mr31794176qao.53.1336488413299; Tue, 08 May 2012 07:46:53 -0700 (PDT) Received: by 10.224.101.72 with SMTP id b8mr31794154qao.53.1336488413181; Tue, 08 May 2012 07:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Tue, 8 May 2012 07:46:32 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: Justin Uberti Date: Tue, 8 May 2012 10:46:32 -0400 Message-ID: To: "Ejzak, Richard P (Richard)" Content-Type: multipart/alternative; boundary=20cf30667c2f1d366d04bf8775f4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkR2w2jehbKkM8ViSX3LDi9l/LUPFg6NyJSGqGRlYF7vEcDocc3EtqbYO/s+CKjpRwukwrogwSF08EV9znvzFUqmdtsWPeAk5XG6N5PQlKp8HX0pux2gccJUJhbFPf1jnF/DxbQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:46:54 -0000 --20cf30667c2f1d366d04bf8775f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard, That is an interesting point. Could you give a short example of when such a "full" re-OFFER would be used? There are a few ways we could handle this case. On Sun, May 6, 2012 at 2:40 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > I have a question about something I came across in the JSEP draft.**** > > ** ** > > 6.1.2 of JSEP draft 0 has the following text regarding =E2=80=9CcreateOff= er=E2=80=9D:**** > > ** ** > > As an offer, the generated SDP will contain the full set of**** > > capabilities supported by the session (as opposed to an answer, which*= * > ** > > will include only a specific negotiated subset to use); for each SDP**= * > * > > line, the generation of the SDP must follow the appropriate process***= * > > for generating an offer. In the event createOffer is called after the*= * > ** > > session is established, createOffer will generate an offer that is**** > > compatible with the current session, incorporating any changes that***= * > > have been made to the session since the last complete offer-answer**** > > exchange, such as addition or removal of streams. If no changes have**= * > * > > been made, the offer will be identical to the current local**** > > description.**** > > ** ** > > The first and last sentences might conflict if the SDP Answerer later > wants to create a new Offer. The local configuration based on the first > offer/answer will contain only the selected media configuration, whereas = it > is desirable for the new Offer to contain the full set of capabilities of > the (new) Offerer. I think this text needs to change to reflect this cas= e. > Am I missing something?**** > > ** ** > > Richard**** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf30667c2f1d366d04bf8775f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard,

That is an interesting point. Could you give a = short example of when such a "full" re-OFFER would be used?=C2=A0= There are a few ways we could handle this case.

On Sun, May 6, 2012 at 2:40 PM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com> wrote:

I have a question about something I came across in the = JSEP draft.

=C2=A0

6.1.2 of JSEP draft 0 has the following text regarding = =E2=80=9CcreateOffer=E2=80=9D:

=C2=A0

=C2=A0=C2=A0= As an offer, the generated SDP will contain the full set of

=C2=A0=C2=A0= capabilities supported by the session (as opposed to an answer, which

=C2=A0=C2=A0= will include only a specific negotiated subset to use); for each SDP

=C2=A0=C2=A0= line, the generation of the SDP must follow the appropriate process

=C2=A0=C2=A0= for generating an offer. In the event createOffer is called after the

=C2=A0=C2=A0= session is established, createOffer will generate an offer that is

=C2=A0=C2=A0= compatible with the current session, incorporating any changes that

=C2=A0=C2=A0= have been made to the session since the last complete offer-answer

=C2=A0=C2=A0= exchange, such as addition or removal of streams. If no changes have

=C2=A0=C2=A0= been made, the offer will be identical to the current local

=C2=A0=C2=A0= description.

=C2=A0

The first and last sentences might conflict if the SDP Answerer later wants to create a new Offer. =C2=A0The local configuration b= ased on the first offer/answer will contain only the selected media configuratio= n, whereas it is desirable for the new Offer to contain the full set of capabilities of the (new) Offerer. =C2=A0I think this text needs to change = to reflect this case. =C2=A0Am I missing something?

=C2=A0

Richard


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


--20cf30667c2f1d366d04bf8775f4-- From juberti@google.com Tue May 8 07:54:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC57021F85E3 for ; Tue, 8 May 2012 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOtIuRtsh5JB for ; Tue, 8 May 2012 07:54:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD021F8648 for ; Tue, 8 May 2012 07:54:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1856854qcs.31 for ; Tue, 08 May 2012 07:54:47 -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:x-system-of-record; bh=RKOisKJVJfCNHKzxezZKnNrvIVUs+DLbPVAjN/Qgov8=; b=IrMd/H70uCzSEfnHC2GDvvaSGkQfmTKcpKyydcow6TP3j6uM3fs3TerDfh1Rw2SIAg Pfim/IiWjZFcC8mxP7Px9+8bdwmVOQUPqMdc2JMZHgbVqyH7M3HCNBRBgy3ZADt+rjE7 SMbLPexT51vfYP4yHe94t078ttgG14V73B92UZ3/OdxbLZOz+sb9FgRYuuuQjSwnoJSf crBvA/V58qyphRnf725XGI0sihbkaxj33fdZJvjHQOHroqG1TgJknnoo2kowpI2tzJUI NQjEa3jFluBTlUlahCtJr0BIehq8BeQSTescRDeGbBJqbZWSame7FVm+6P3QqZcNS9K0 pk0A== 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-system-of-record:x-gm-message-state; bh=RKOisKJVJfCNHKzxezZKnNrvIVUs+DLbPVAjN/Qgov8=; b=Y2UQEShl1aLXR7X0eW7G68PNLCxik/sdw6snzfGX1h0CtsWaNOumt+dyDD4yaSIpBg iGWDcxS9drmpvnWmhAKI+xymd4y3naAlFa1iiSIvwN+YiwHaTp2IdvuCZ6Tyg/VF7Mng 0/CQRZPo+UjQ04BsVo9/lIcxsVKYR7eaCR+a1QrSgHRtAbixD+lsu+6bwqMebK+j5PX9 pBpXJoIFRlweRfcKr4jr/rf2KYTZoyKumqkaMOWc/LQvKJ1vKeK/LDA0lu9afIakxLdT P+sK6M4NR/obQFbExVyvrIPRXIvjylmKjW22fZ+a4QS11/5Gfku0vipAcELBeZJy+aH3 4ybA== Received: by 10.229.69.80 with SMTP id y16mr9370910qci.153.1336488887622; Tue, 08 May 2012 07:54:47 -0700 (PDT) Received: by 10.229.69.80 with SMTP id y16mr9370900qci.153.1336488887469; Tue, 08 May 2012 07:54:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Tue, 8 May 2012 07:54:27 -0700 (PDT) In-Reply-To: References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <20120504104446.2d7b2715@lminiero-acer> <4FA3E48E.1050204@freedesktop.org> From: Justin Uberti Date: Tue, 8 May 2012 10:54:27 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=0003255630a262479404bf8791cc X-System-Of-Record: true X-Gm-Message-State: ALoCoQmFBixVYAx/9K30PYITSX9cF4oCAUwAG9SZHTzO3xh+FxwVNHir9qHWw2gKHZPh1u0gyxKky/bSU4F/oQR50kW19gMCdkYZ7NQfjkzb4d6pBm4HBf6GlHkfup55sC6bcPbDUJi7 Cc: rtcweb@ietf.org, dean.willis@softarmor.com Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:54:50 -0000 --0003255630a262479404bf8791cc Content-Type: text/plain; charset=UTF-8 This "SW encoding chews battery" claim is often mentioned, but in a video chat, the power draw from the screen and network are often 10x the CPU power draw, which is typically < 1W (for ARM). So there is very little impact on talk time between HW and SW encode. Mobile devices are often limited in terms of what resolutions they can encode in software, because they have less overall compute power than PCs. In my experience, that is the factor to consider, not battery life. On Fri, May 4, 2012 at 6:56 PM, Bernard Aboba wrote: > > > I am more worried about the guy implementing a WebRTC security camera > > that uses an embedded Linux kernel and a software video encoder. Each > > unit might "produce" video 24x7. But there is no MPEG-LA licensed > > browser or OS or encoder chip to fall back on. The whole product might > > sell for less than it might cost him to license the codec. > > [BA] We are rapidly moving toward inclusion of hardware video > encode/decode by default on battery-powered devices (mobile handsets, > tablets, etc.). > > Since software encode/decode is processor (and battery) intensive, the > latest generation of webcams have video encode/decode built-in. For > example, see: > > http://www.ehomeupgrade.com/2011/06/02/skype-certified-webcams-tote-built-in-720p-h-264-video-encoders/ > > When handled purely in software, it is quite difficult to enable video > sessions of substantial duration without draining the battery. > > While my assumption is that hardware support for encode/decode will become > less codec-specific over time, that is typically not the case today. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0003255630a262479404bf8791cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This "SW encoding chews battery" claim is often mentioned, but in= a video chat, the power draw from the screen and network are often 10x the= CPU power draw, which is typically < 1W (for ARM). So there is very lit= tle impact on talk time between HW and SW encode.=C2=A0

Mobile devices are often limited in terms of what resolution= s they can encode in software, because they have less overall compute power= than PCs. In my experience, that is the factor to consider, not battery li= fe.

On Fri, May 4, 2012 at 6:56 PM, Bernard Abob= a <bernard_aboba@hotmail.com> wrote:

> I am more worried about the guy implementin= g a WebRTC security camera
> that uses an embedded Linux kernel and a= software video encoder. Each
> unit might "produce" video = 24x7. But there is no MPEG-LA licensed
> browser or OS or encoder chip to fall back on. The whole product might=
> sell for less than it might cost him to license the codec.

=
[BA]=C2=A0 We are rapidly moving toward inclusion of hardware video e= ncode/decode by default on battery-powered devices (mobile handsets, tablet= s, etc.).

Since software encode/decode is processor (and battery) intensive, the = latest generation of webcams have video encode/decode built-in.=C2=A0 For e= xample, see:
= http://www.ehomeupgrade.com/2011/06/02/skype-certified-webcams-tote-built-i= n-720p-h-264-video-encoders/

When handled purely in software, it is quite difficult to enable video = sessions of substantial duration without draining the battery.=C2=A0=C2=A0 =

While my assumption is that hardware support for encode/decode will= become less codec-specific over time,=C2=A0 that is typically not the case= today.


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


--0003255630a262479404bf8791cc-- From juberti@google.com Tue May 8 08:10:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0E21F85C0 for ; Tue, 8 May 2012 08:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdfBQRRAsuq3 for ; Tue, 8 May 2012 08:10:30 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97021F85A3 for ; Tue, 8 May 2012 08:10:20 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1875810qcs.31 for ; Tue, 08 May 2012 08:10:19 -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:x-system-of-record; bh=32PEfjFKpsxTSMpKs5a6HU251aVkN2FQEfSjqfs+m/4=; b=AeE9vpkRckB+zgSW2ngaPb4wUmBJpR5CEik5PSJHoUoOOm1rgRiLAKYR7aXico0Qa8 onJtQTXjA6odtWBNE5yggLaLf54mi3COjrg4a0XPSO7W0B9O4ldaYWfBx6gleb0bXYk8 xocDq8lucsym44sFi6KA63v59Qgwo9252mSEVjxAk7CzsJVNfQzAnSke4xagef5EhdX5 6Y8aqMqeQjZ5g8nGmVw46BQjoE7+/C9bAfU3+Ye9hNCixTYQxXkEhrPV1I27yxIbVaRX +Lm+XLeVbYVo0ZR2cV8sHGQtOzmRbIabP7FX728lhYi2R3HC4ligOE+rUmk1+zBPVwnj r3Jg== 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-system-of-record:x-gm-message-state; bh=32PEfjFKpsxTSMpKs5a6HU251aVkN2FQEfSjqfs+m/4=; b=eENnRdFM9Y8LCNJZOqMkhjnORLsJCHtoorsghFu1bdoWhBToor6hXUM1gMAUYR+F8O Bh2iFSkp4iqtfueWMxGLsaaAXfnueaTfS5lZba1/BR85cbVTCqKw6HmbR1vxLAuQjCoa O3pb6xy2YvFf3e1Y9rTZlynldk5gJu1WmUxh/GiJlwK43Jdn1kyo0IXeEMcuQA3Wkt2a RBpTOraxEaBYWa9zTR8hiGdltgJ6WTkX8vP4x7wx1XNzWpZL2YeceP32KEUvH2EE9sOC FmkA/205ZZACnOOgXHPxZgMgUyu9P/gDuva02iV7HmnpKDb5iWPVDckN/zc0r81MBO1h 3YGg== Received: by 10.224.215.135 with SMTP id he7mr25824526qab.48.1336489819691; Tue, 08 May 2012 08:10:19 -0700 (PDT) Received: by 10.224.215.135 with SMTP id he7mr25824504qab.48.1336489819565; Tue, 08 May 2012 08:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Tue, 8 May 2012 08:09:58 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericsson.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Tue, 8 May 2012 11:09:58 -0400 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf300513f6f0f06604bf87c89e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkS9qw1BNshBOn1aJxd3bEjEqt7w8Phl7k1hlFNKgNSlslRqPZEHeBWVq4Dk68Z6izQKnaib2JMsE8l/jqiQA6hjofFXkRxPNI8eKcskHHGZJ/NRWeY6BNOjAV0MgL/ReiNhCru Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:10:31 -0000 --20cf300513f6f0f06604bf87c89e Content-Type: text/plain; charset=UTF-8 The conclusion on this thread seems to be that the right way to address this problem is via PeerConnection cloning, and that no changes are needed to the JSEP state machine. I'll work with Richard to figure out how we should extend JSEP to support cloning. On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>>You could also choose not to alert the remote user until the ICE > procedures have finished - more or less using ICE with preconditions. > >>>> > >>>> Of course, that is going to trigger actions in STUN/TURN servers, > even if the called party won't accept the call, but at least from a user > >>>> experience perspective that is still better than lifting the hook, > and having to wait for whatever-time-it-takes-for-ICE-to-finish seconds > before one can start to talk. > >>> > >>> This also has a downside of disclosing user's IP to the caller without > the user confirmation. For a lot of applications this can be serious > security flaw. > >> > >> The client can still log when ICE procedures occur. > >> > >> Because, even if I wait until your phone starts to ring, most likely I > would still get your IP address without user confirmation (speaking in SIP > terms, phones normally don't ask for user permission before they send 18x > with SDP), eventhough you would easier be made aware of that it happens. > > > > Another alternative is of course to do ICE with an SBC, and/or having an > SBC doing ICE on behalf of you :) > > > > > > This is true for SIP but was as far as I know was specifically designed > around in WebRTC. WebRTC signaling server acts as B2BUA so any type of > ringing notification goes through the web server and does not need to carry > any type of client address information. The client address information is > only provided > > when SDP answer is sent or ICE negotiation is started. > > Assuming you are only going to make user confirmation (read: accept calls) > in cases where you absolutely sure that the caller isn't someone trying to > get your IP address. > > But, never the less, having a solution where I first have to give user > confirmation, and then wait until I can start to talk, is probably > something most people want to avoid. Depending upon, of course, how long > the waiting time is. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf300513f6f0f06604bf87c89e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The conclusion on this thread seems to be that the right way to address thi= s problem is via PeerConnection cloning, and that no changes are needed to = the JSEP state machine. I'll work with Richard to figure out how we sho= uld extend JSEP to support cloning.

On Thu, May 3, 2012 at 5:16 PM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:
Hi,

>>>>You could also choose not to alert the remote user until th= e ICE procedures have finished - more or less using ICE with preconditions.=
>>>>
>>>> Of course, that is going to trigger actions in STUN/TURN s= ervers, even if the called party won't accept the call, but at least fr= om a user
>>>> experience perspective that is still better than lifting t= he hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish se= conds before one can start to talk.
>>>
>>> This also has a downside of disclosing user's IP to the ca= ller without the user confirmation. For a lot of applications this can be s= erious security flaw.
>>
>> The client can still log when ICE procedures occur.
>>
>> Because, even if I wait until your phone starts to ring, most like= ly I would still get your IP address without user confirmation (speaking in= SIP terms, phones normally don't ask for user permission before they s= end 18x with SDP), eventhough you would easier be made aware of that it hap= pens.
>
> Another alternative is of course to do ICE with an SBC, and/or having = an SBC doing ICE on behalf of you :)
>
>
> This is true for SIP but was as far as I know was specifically designe= d around in WebRTC. WebRTC signaling server acts as B2BUA so any type of ri= nging notification goes through the web server and does not need to carry a= ny type of client address information. The client address information is on= ly provided
> when SDP answer is sent or ICE negotiation is started.

Assuming you are only going to make user confirmation (read: ac= cept calls) in cases where you absolutely sure that the caller isn't so= meone trying to get your IP address.

But, never the less, having a solution where I first have to give user conf= irmation, and then wait until I can start to talk, is probably something mo= st people want to avoid. Depending upon, of course, how long the waiting ti= me is.

Regards,

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

--20cf300513f6f0f06604bf87c89e-- From roman@telurix.com Tue May 8 08:33:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D7921F85D9 for ; Tue, 8 May 2012 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.088, 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 d3PLuN1GygAq for ; Tue, 8 May 2012 08:33:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A525221F85D6 for ; Tue, 8 May 2012 08:33:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8278892pbc.31 for ; Tue, 08 May 2012 08:33: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 :cc:content-type:x-gm-message-state; bh=4D8U5MsOzVUBi5RwJXT4blQ/9pfVwHG94307HD722Bw=; b=BcnmlVVL15vRfGIr1KZY0eJCW+kvTAA7IpyNcOBe2l09SD+2MTuKxRd6gUlseygCq7 xu0ZPkfSb4ddEHMj/RT0bOQnMpqhoeqqKwLEPGXrRfN9tCk7h/7J7H39mEsqV4m58ksV P48pxtLoF3lOAfVEkoDtqLfJ78IFgrgn7AK1n2rvawTn48vqe6bo9mzL/TzZtmoKgtTU shlRE0xgvphw54K2VvWDkI2N3qPxeTolNf+X2/qPgYCFicTWw/YMzj4TajHaAMqQNg9A MKuINDtrc3fF4E3KswfvmGn40BPDEAeA4cpdWTlQ3d619iVi0SBrHC89B4i5domhDiVh 6Maw== Received: by 10.68.197.8 with SMTP id iq8mr8251371pbc.65.1336491192478; Tue, 08 May 2012 08:33:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id kb12sm2725673pbb.15.2012.05.08.08.33.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:33:11 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8278858pbc.31 for ; Tue, 08 May 2012 08:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.74 with SMTP id gw10mr9365734pbc.90.1336491191033; Tue, 08 May 2012 08:33:11 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Tue, 8 May 2012 08:33:10 -0700 (PDT) In-Reply-To: References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 8 May 2012 11:33:10 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8fb20896afe13f04bf881a1e X-Gm-Message-State: ALoCoQla0YhVM57wDjl4pRxhC90Rs3vzEvvIHmNKv+xPq9xLLylKRo/3O+nwWoa1YxvD2fNH2z3r Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:33:13 -0000 --e89a8fb20896afe13f04bf881a1e Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 8, 2012 at 10:46 AM, Justin Uberti wrote: > Richard, > > That is an interesting point. Could you give a short example of when such > a "full" re-OFFER would be used? There are a few ways we could handle this > case. > > Actually I was the person who argued that "full" capabilities should be present in original SIP O/A, when new offer is generated in an existing session. The use case for this are B2BUA that connect an existing session to a new call or another existing session. Typically, B2BUA would ask one of the call parties for the offer (send an INVITE with no body in SIP), get the new offer, and send this offer to the newly placed call. In order for this to work, all the calling party capabilities should be listed in this new offer, in particular all the codecs and all the communications types (audio, video, text, etc), or call would not be successfully established. _____________ Roman Shpount --e89a8fb20896afe13f04bf881a1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 8, 2012 at 10:46 A= M, Justin Uberti <juberti@google.com> wrote:
Richard,

That is an interesting point. Could you give a = short example of when such a "full" re-OFFER would be used?=A0The= re are a few ways we could handle this case.


Actually I was the person who argued that "full" capabi= lities should be present in original SIP O/A, when new offer is generated i= n an existing session. The use case for this are B2BUA that connect an exis= ting session to a new call or another existing session. Typically, B2BUA wo= uld ask one of the call parties for the offer (send an INVITE with no body = in SIP), get the new offer, and send this offer to the newly placed call. I= n order for this to work, all the calling party capabilities should be list= ed in this new offer, in particular all the codecs and all the communicatio= ns types (audio, video, text, etc), or call would not be successfully estab= lished.
_____________
Roman Shpount

--e89a8fb20896afe13f04bf881a1e-- From martin.thomson@gmail.com Tue May 8 08:40:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5E711E80A2 for ; Tue, 8 May 2012 08:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-0.152, 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 Y6HmWA8niTm5 for ; Tue, 8 May 2012 08:40:46 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 127EA11E80A3 for ; Tue, 8 May 2012 08:40:45 -0700 (PDT) Received: by bkty8 with SMTP id y8so5729080bkt.31 for ; Tue, 08 May 2012 08:40:45 -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=hjuGf8tpM22ATc3/ZCIHj662nbzaJn1nLM4h1Zmk6D0=; b=L3mTscPk8YzvG+C+UbCIT4SxcqxT5225WSCgOXGL0Ey6IsL8PeMvyOhi4CmVfIX2ri 5LQ7zR1xYDUPKBqeTDtm2stE5YaSgMnD6YWLntZ4qBv6+/qdw0GusXQu2GmxuOwhKKBQ gia3DMo0bircL3iBMGjR3teUMxsmVS3cRqblYJxOkQi9EtRLnKz2LO/7H4GSNDT/shqW e4FlLLjQaKU1secj6ZXS5t0HH6j2AvQvsZBNkTj+jD/q1mMzDRbiCvklRXtVngff2F7Q SJzqY/YuoWYGk1W85E+2YAoeuS2qZsH0ds06T1Dmk/A6WMrBHV+A94pY7qZvRhdALLu1 WVMg== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr5695313bkv.26.1336491644885; Tue, 08 May 2012 08:40:44 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Tue, 8 May 2012 08:40:44 -0700 (PDT) In-Reply-To: <1D062974A4845E4D8A343C65380492020865B54D@XMB-BGL-414.cisco.com> References: <1D062974A4845E4D8A343C65380492020865B54D@XMB-BGL-414.cisco.com> Date: Tue, 8 May 2012 08:40:44 -0700 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consent freshness - interaction with SDP direction attributes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:40:48 -0000 On 8 May 2012 03:20, Muthu Arul Mozhi Perumal (mperumal) wrote: > My thought is that the direction attributes in > SDP should have no impact on the generation of consent freshness. As far as > the media connection address and port are valid, the browser should continue > to generate consent freshness requests, irrespective of whether the stream > is sendonly, recvonly, sendrecv or inactive, analogous to RTCP. I tend to agree. Where I disagree: consent freshness does not require a new mechanism. If a Binding request is used, it's trivial to maintain consent with ICE-lite endpoints and I don't see any significant advantage in avoiding a simple SHA-1. > - Eliminate the need for the browser to depend on the (untrusted) JS to tell > it when to stop/start generating consent requests. This isn't a problem. The browser needs to have consent freshness when it sends a packet, simple. The only possible concern is clipping, where consent freshness has expired, causing the browser to drop packets instead of sending them. If consent freshness wasn't maintained, then an unmute on a stream would force the browser to refresh consent prior to sending packets. Add packet loss and this could be annoying. --Martin From martin.thomson@gmail.com Tue May 8 08:49:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08ACE21F8655 for ; Tue, 8 May 2012 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.745 X-Spam-Level: X-Spam-Status: No, score=-3.745 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 lo1qFVbaSqsW for ; Tue, 8 May 2012 08:49:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35E21F8652 for ; Tue, 8 May 2012 08:49:04 -0700 (PDT) Received: by bkty8 with SMTP id y8so5737980bkt.31 for ; Tue, 08 May 2012 08:49:03 -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=yiLg4eG35cUWM/IDzHwLzxBkB6ZkYvz9Yg3lno6kM5w=; b=pybtEl117piN+VtsV1GoKSgmfH1zZqUDIHRF7gmUcqIf/aZ1FpwcaWxa92F41G4T7k RpyswZWuIDxYNQJW/dSdS+rh6gmNLj/VGaUurv2hgx59egoOCgMBh0WgYfx3OqJxzFcQ AMEuvKl3tSdah4cxdo62TFaEE6VOHzj/lX3N5YNNEZIAUKegu0K1PxJyWstBqZ+0069Q fTUkX7I+G4Hw9o11MC/P8lsIHD22eJhEhJ+0Pb+yNjLaM9NjMarmR02dGDqgcG9WNjIH Ko6h31vi4XjH9EqCsbznAL0dFbI98W4ZRvmRDwi5ZmFWq3234ea14yud0uFE9tq8E4O6 DZrw== MIME-Version: 1.0 Received: by 10.204.152.73 with SMTP id f9mr7343180bkw.3.1336492143345; Tue, 08 May 2012 08:49:03 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Tue, 8 May 2012 08:49:03 -0700 (PDT) In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC028C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA83F6D.9040308@alvestrand.no> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0859@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11364EC0881@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Tue, 8 May 2012 08:49:03 -0700 Message-ID: From: Martin Thomson To: "Ejzak, Richard P (Richard)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposal for PeerConnection cloning X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:49:05 -0000 On 7 May 2012 19:10, Ejzak, Richard P (Richard) wrote: > You raise a good point since some candidates may be released before cloning > occurs. So this is another bug in the procedure. I would suggest that the > configuration also be passed to the CPC and that if any of the required > candidates are released before cloning occurs that they be reallocated. Releasing a TURN candidate is a real possibility. The same could apply to local candidates (and server reflexive), though that will depend on implementation. Getting the same one back is unlikely for TURN, though it might be possible for local. In all these cases, answers that arrive late will fail. > Alternately, we could recommend that candidates be kept allocated longer > than usual and that if cloning is attempted after any of the candidates are > released then the cloning procedure fails. I'd be against making any such recommendation for browser implementations. The signaling application is more likely to know best in this scenario. In that case, it can make the call to hold candidates open. PR_ANSWER seems to have the right semantics. --Martin From dbenham@cisco.com Tue May 8 09:37:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D606B21F8567 for ; Tue, 8 May 2012 09:37:06 -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=[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 RNF13kgHHiBS for ; Tue, 8 May 2012 09:37:05 -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 6F20121F8564 for ; Tue, 8 May 2012 09:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dbenham@cisco.com; l=9081; q=dns/txt; s=iport; t=1336495025; x=1337704625; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=VzLUfOzK0/Rsf8Wjcvwtm9tM6a3EiFwfPvvImVWTMso=; b=BhDVX5e0uPufZa72LPZK+N4142KO1SA+cqvdWCL5Qg5+N9qhwVM/i3kI j+8doNs9LgWM18V4bcRZeY0T3tCPxi8ows9Vs1vPXYLjF11ul14uWPMqQ 5TBvL8xE030hqvin1OHFTYKE1Wa0u1Ni2pFCnH50HBqAKQidA5nHNsLJ6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHRLqU+rRDoI/2dsb2JhbABEgkawZYEHggwBAQEEEgEJEQNZAgEIDgMDAQEBCwYXAQYBRQkIAQEEARIIGodrAZszoDOLA4UvYwSIZJtzgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208,217";a="43983633" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 May 2012 16:37:00 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q48GaxF6002002; Tue, 8 May 2012 16:37:00 GMT Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 09:36:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2D38.C93C3173" Date: Tue, 8 May 2012 09:36:54 -0700 Message-ID: <6D075136FCBDDD42AC37D05F3E7055F403A50373@xmb-sjc-232.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF Thread-Index: Ac0tOL7xqlF9SWhCSZ2t6CVbf9DIRA== References: From: "David Benham (dbenham)" To: "Stephan Wenger" , X-OriginalArrivalTime: 08 May 2012 16:36:58.0659 (UTC) FILETIME=[C98E7F30:01CD2D38] Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:37:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2D38.C93C3173 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable +1 Many companies shipping in high volume pay the annual cap and have a marginal cost at or below 10c each and the low volumes (<100K) are free as noted. That leaves non-profits (or have no workable freemium model) shipping in the millions to be about the only segment with an hurdle. =20 From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Friday, May 04, 2012 12:09 PM To: Dean Willis; Lorenzo Miniero Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF =20 =20 From: Dean Willis Date: Friday, 4 May, 2012 16:10=20 [...] [...] I am more worried about the guy implementing a WebRTC security camera that uses an embedded Linux kernel and a software video encoder. Each unit might "produce" video 24x7. But there is no MPEG-LA licensed browser or OS or encoder chip to fall back on. The whole product might sell for less than it might cost him to license the codec. Really? The MPEG-LA license terms for one encoder/decoder: $0 for the first 100,000 units per year. $0.20 for the next several millions, after that $0.10 until the cap is reached. And, the MPEG-LA license is "take it or leave it" (at least for small fish like your hypothetical camera guy), so even the lawyer cost for review should be minimal. =20 No, I continue to believe that the MPEG-LA license is not a hurdle for anyone but those giving stuff away for free, or having a business model that disallows them to pay licensing fees. It's the patents not covered by that license that you may worry about. =20 Stephan =20 ------_=_NextPart_001_01CD2D38.C93C3173 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

+1

Many companies shipping in high volume pay the annual cap and have a = marginal cost at or below 10c each and the low volumes (<100K) are = free as noted.       That leaves = non-profits (or have no workable freemium model) shipping in the = millions to be about the only segment with an = hurdle.

 

From:= = Stephan Wenger [mailto:stewe@stewe.org]
Sent: Friday, May 04, = 2012 12:09 PM
To: Dean Willis; Lorenzo Miniero
Cc: = rtcweb@ietf.org
Subject: Re: [rtcweb] Discussion on codec = choices from a developer who doesn't come to = IETF

 

 

From: Dean Willis <dean.willis@softarmor.com&g= t;
Date: Friday, 4 May, 2012 16:10 =

[…]

[…]

I am more worried about the guy implementing a WebRTC security camera = that uses an embedded Linux kernel and a software video encoder. Each = unit might "produce" video 24x7. But there is no MPEG-LA = licensed browser or OS or encoder chip to fall back on. The whole = product might sell for less than it might cost him to license the = codec.

= Really?  The MPEG-LA license terms for one encoder/decoder: $0 for = the first 100,000 units per year.  $0.20 for the next several = millions, after that $0.10 until the cap is reached.  And, the = MPEG-LA license is "take it or leave it" (at least for small = fish like your hypothetical camera guy), so even the lawyer cost for = review should be minimal.=

 =

= No, I continue to believe that the MPEG-LA license is not a hurdle for = anyone but those giving stuff away for free, or having a business model = that disallows them to pay licensing fees.  It's the patents not = covered by that license that you may worry about.=

 =

= Stephan  

------_=_NextPart_001_01CD2D38.C93C3173-- From tterriberry@mozilla.com Tue May 8 09:48:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A2121F8584 for ; Tue, 8 May 2012 09:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, 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 N1AztUou33IQ for ; Tue, 8 May 2012 09:48:44 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id B666621F856A for ; Tue, 8 May 2012 09:48:44 -0700 (PDT) Received: from [10.250.5.141] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 7CA484AF1D4 for ; Tue, 8 May 2012 09:48:30 -0700 (PDT) Message-ID: <4FA94E5E.4000102@mozilla.com> Date: Tue, 08 May 2012 09:48:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120305 SeaMonkey/2.7.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <20120504104446.2d7b2715@lminiero-acer> <4FA3E48E.1050204@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:48:45 -0000 Justin Uberti wrote: > This "SW encoding chews battery" claim is often mentioned, but in a > video chat, the power draw from the screen and network are often 10x the > CPU power draw, which is typically < 1W (for ARM). So there is very > little impact on talk time between HW and SW encode. > > Mobile devices are often limited in terms of what resolutions they can > encode in software, because they have less overall compute power than > PCs. In my experience, that is the factor to consider, not battery life. Even if they could encode higher resolutions, they typically don't have the bandwidth to push out HD content at several megabits per second (or it would be prohibitively expensive if they did). So I think mobile videoconferencing resolutions around 360p are much more realistic, and perfectly suitable for software. At this point I'll just refer people to the guy who posted here from TI: http://www.ietf.org/mail-archive/web/rtcweb/current/msg03785.html From randell-ietf@jesup.org Tue May 8 10:54:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBFE21F84D0 for ; Tue, 8 May 2012 10:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 dncFcSrbw+cv for ; Tue, 8 May 2012 10:54:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BE53721F84CE for ; Tue, 8 May 2012 10:54:00 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRobn-0003Lu-GG for rtcweb@ietf.org; Tue, 08 May 2012 12:53:59 -0500 Message-ID: <4FA95D6F.2040405@jesup.org> Date: Tue, 08 May 2012 13:52:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FA3754D.6020004@ericsson.com> <4FA40C0F.3000702@jesup.org> <4FA8D1F6.4010103@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SAVPF history (Re: Final plea about SRTP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 17:54:01 -0000 On 5/8/2012 9:34 AM, Roman Shpount wrote: > > On Tue, May 8, 2012 at 3:57 AM, Harald Alvestrand > wrote: > > __ > On 05/04/2012 07:45 PM, Roman Shpount wrote: >> I used to work on hardware endpoints that have been using SAVPF >> since 2004, with hundreds of thousands of units in the field. >> >> >> I thought SAVPF was only standardized in 2008 and AVPF was >> standardized in 2006. AVPF was discussed for a while though, so I >> would assumed you worked with something that implemented one of >> the drafts... > The -00 version of the SAVPF draft is dated 19 October 2003. > > According to > https://datatracker.ietf.org/doc/draft-ietf-avt-profile-savpf/history/ > publication was requested in February 2006, and it was approved by > the IESG in November 2007. The publication delay was 3 months. > > The technical changes that resulted from these 4 years of work can > be seen here: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-avt-profile-savpf-00.txt&url2=draft-ietf-avt-profile-savpf-12.txt > > > > I would say that something that changes to rfc4585 would be more > relevant. Regardless of the actual changes in the draft, my point is > there are very few actual SIP devices that implement SAVPF or AVPF. Perhaps, though maybe it's more common in video (SIP INFO for IDR requests "sucks dead gerbils through garden hoses" - old Amiga slang phrase). > Specifying this as the only profile supported by WebRTC will create yet > another challenge to legacy interop, since it will require not only > processing of ICE messages, and DTLS-SRTP re-encoding, but also RTCP > re-generation. AVPF has the advantage of being backward-compatible with AVP in almost all cases. We used SAVPF internally, but typically hid that from the outside world by advertising AVP (this was long before SDP cap-neg was finalized). (Has anyone truly implemented it? In open source?) IIRC this is even spoken to in the spec. (We used AVP/AVPF instead of SAVP/SAVPF because we used the non-standardized "best effort encryption" draft I worked on with Hadriel, as an alternative/stopgap until cap-neg "worked".) -- Randell Jesup randell-ietf@jesup.org From keith.drage@alcatel-lucent.com Tue May 8 11:35:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D75221F857A for ; Tue, 8 May 2012 11:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.865 X-Spam-Level: X-Spam-Status: No, score=-109.865 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 OYs8DQ8vQZAo for ; Tue, 8 May 2012 11:35:57 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC121F8573 for ; Tue, 8 May 2012 11:35:57 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q48IZtLj015991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 May 2012 20:35:55 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 8 May 2012 20:35:55 +0200 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Date: Tue, 8 May 2012 20:35:52 +0200 Thread-Topic: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF Thread-Index: Ac0tOnUc4pBpWmeiQRCSA+pbDhupRAADoXug Message-ID: References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <20120504104446.2d7b2715@lminiero-acer> <4FA3E48E.1050204@freedesktop.org> <4FA94E5E.4000102@mozilla.com> In-Reply-To: <4FA94E5E.4000102@mozilla.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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 18:35:58 -0000 I suspect the key question is being missed here to make the arguments look = more attractive. Most mobile devices (at least those on 3GPP standards) trying to do anythin= g other than RTCWEB with their screens and cameras will need to support H.2= 64 anyway. So the discussion needs to be around what are the pros and cons of supporti= ng both VP8 and H.264 on the same mobile, as opposed to only having to supp= ort H.264. Regards Keith -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Timothy B. Terriberry Sent: 08 May 2012 17:49 To: rtcweb@ietf.org Subject: Re: [rtcweb] Discussion on codec choices from a developer who does= n't come to IETF Justin Uberti wrote: > This "SW encoding chews battery" claim is often mentioned, but in a > video chat, the power draw from the screen and network are often 10x the > CPU power draw, which is typically < 1W (for ARM). So there is very > little impact on talk time between HW and SW encode. > > Mobile devices are often limited in terms of what resolutions they can > encode in software, because they have less overall compute power than > PCs. In my experience, that is the factor to consider, not battery life. Even if they could encode higher resolutions, they typically don't have=20 the bandwidth to push out HD content at several megabits per second (or=20 it would be prohibitively expensive if they did). So I think mobile=20 videoconferencing resolutions around 360p are much more realistic, and=20 perfectly suitable for software. At this point I'll just refer people to=20 the guy who posted here from TI: http://www.ietf.org/mail-archive/web/rtcweb/current/msg03785.html _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Tue May 8 14:40:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794E11E8074 for ; Tue, 8 May 2012 14:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 t91H5UqPYLxF for ; Tue, 8 May 2012 14:40:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBBF11E8072 for ; Tue, 8 May 2012 14:40:49 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2077990vbb.31 for ; Tue, 08 May 2012 14:40:45 -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=loL5oHA7L3E8qexU76ASenO7lNpsTAJnE+VMhhVPQPU=; b=F71MMOA7iEtRN42Cs9mC/Il/pN8cMxuUXb0edPo5eSjuXY5HdytJNDuKyPf18i8EiH 4TGMVrVTETuiorWp+l1PpVQz32sB7SfpJlDFnRnoUBkMkDHTv76zqAYue0SMbvXpFsKT VYOyJLxh8OPisA2DEEDBnf7/FFDs4HJOs9EXoGzzbObnSLCsLujeDgMx0hUbEinX/tZx ssx3Mhms22TA37IgJMNeVBw754RxxosolDgTKRkLehvEY7TMaaMFUgxR4+4sawuyUo64 UebpZXpyoUogel7VNhQL4rWFczJgxwUuM6ZVjlywNKT/sisd+Tf0GXoq2IAuGhRN12Jk 4PGQ== MIME-Version: 1.0 Received: by 10.52.69.38 with SMTP id b6mr3554188vdu.22.1336513245103; Tue, 08 May 2012 14:40:45 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Tue, 8 May 2012 14:40:45 -0700 (PDT) In-Reply-To: References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <20120504104446.2d7b2715@lminiero-acer> <4FA3E48E.1050204@freedesktop.org> <4FA94E5E.4000102@mozilla.com> Date: Tue, 8 May 2012 14:40:45 -0700 Message-ID: From: Ted Hardie To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:40:50 -0000 On Tue, May 8, 2012 at 11:35 AM, DRAGE, Keith (Keith) wrote: > Most mobile devices (at least those on 3GPP standards) trying to do anything other than RTCWEB with their screens and cameras will need to support H.264 anyway. > My faulty memory is that the availability of hardware acceleration for certain audio codecs used to be restricted and that VoIP clients on 3GPP devices had no access to them. Is that situation cleared up? Can any installed application now access hardware accelerated codec support? regards, Ted From harald@alvestrand.no Tue May 8 14:54:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2787821F8476 for ; Tue, 8 May 2012 14:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 LU4ZIIF1nmLv for ; Tue, 8 May 2012 14:54:34 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6835421F846E for ; Tue, 8 May 2012 14:54:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FE3839E149 for ; Tue, 8 May 2012 23:54:33 +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 ceaRhTmifHCi for ; Tue, 8 May 2012 23:54:33 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0BB9239E0F3 for ; Tue, 8 May 2012 23:54:33 +0200 (CEST) Message-ID: <4FA99618.9050700@alvestrand.no> Date: Tue, 08 May 2012 23:54:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:54:35 -0000 Just because I realized I didnt understand something, I ask..... We rejected RTCP RR as a consent freshness mechanism because RR is trivial to fake. But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs are integrity protected, origin authenticated and replay protected (do I have that right?). What is the reason why this is not sufficient protection to use RTCP RR as a consent freshness mechanism? Harald From ekr@rtfm.com Tue May 8 15:00:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0339E8006 for ; Tue, 8 May 2012 15:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qxTnXvRMXFVs for ; Tue, 8 May 2012 15:00:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC57E9E8001 for ; Tue, 8 May 2012 15:00:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2099968vbb.31 for ; Tue, 08 May 2012 15:00:25 -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=hguICqtfIx5DlrwzrLebS+2DXZtFF14wh3lgKSkEc6k=; b=AhgPvn1BB+WbGA6trp503acgmzQqmFKq40zC/kT6NyhZYuYNKrYlCmnSxWVoLCMP0E d60B56JhyJAkpxz7nwoevcquCtoncoHinW54EDEZiENUpsuwPVcILosItqD25RQoSHga 5xApBEVP9bFmXA2IBXUhmBCWGn1ig7QRRvllHp4ZxGyS0yVl2X0gWq4v1kuDYedXnzGq ATiaKaL1itOaZ3FQdch+2HQ000gNbio2d2TiI+wtCQSP2QeHjTYYhCTQYI0OOcY1SuMZ pQF4TJE7hX/fWwQ5Dp8At2Hts8N3uidmBCDYj1LdgJn4g169MpTtdCyslAv3lsa3yNHg u3NA== Received: by 10.220.141.79 with SMTP id l15mr13173994vcu.48.1336514425032; Tue, 08 May 2012 15:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 8 May 2012 14:59:44 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <4FA99618.9050700@alvestrand.no> References: <4FA99618.9050700@alvestrand.no> From: Eric Rescorla Date: Tue, 8 May 2012 14:59:44 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnpqMssvPnzZ5zUYg62K+cbHcOHbpVKN3VYS74hh+VKGOEfiPPOG4Dgg5iy6hFc5AUcVJx/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 22:00:29 -0000 On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand wrote: > Just because I realized I didnt understand something, I ask..... > > We rejected RTCP RR as a consent freshness mechanism because RR is trivial > to fake. > But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs > are integrity protected, origin authenticated and replay protected (do I > have that right?). > > What is the reason why this is not sufficient protection to use RTCP RR as a > consent freshness mechanism? This isn't a complete analysis, but if you are using SDES for key management, then the site knows the SRTCP keys, so I don't *think* SRTCP is buying you much. I haven't thought through this completely though, so maybe there is still some additional value. -Ekr From randell-ietf@jesup.org Tue May 8 22:46:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3023D21F85E3 for ; Tue, 8 May 2012 22:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 j934ZaCgZTGS for ; Tue, 8 May 2012 22:46:19 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8365721F85D9 for ; Tue, 8 May 2012 22:46:16 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRzj5-0001JU-0t for rtcweb@ietf.org; Wed, 09 May 2012 00:46:15 -0500 Message-ID: <4FAA045E.6010009@jesup.org> Date: Wed, 09 May 2012 01:45:02 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <20120504104446.2d7b2715@lminiero-acer> <4FA3E48E.1050204@freedesktop.org> <4FA94E5E.4000102@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 05:46:20 -0000 On 5/8/2012 2:35 PM, DRAGE, Keith (Keith) wrote: > I suspect the key question is being missed here to make the arguments look more attractive. > > Most mobile devices (at least those on 3GPP standards) trying to do anything other than RTCWEB with their screens and cameras will need to support H.264 anyway. > > So the discussion needs to be around what are the pros and cons of supporting both VP8 and H.264 on the same mobile, as opposed to only having to support H.264. This only has any real import if you're talking hardware implementations. Hardware H.264 doesn't preclude software VP8 (or vice versa), and the software is available, and a trivial amount of flash space. So I see nothing to discuss around "both VP8 and H.264 vs. just H.264 on mobile". -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Tue May 8 23:25:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4221F85EF for ; Tue, 8 May 2012 23:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 B64keaVsrp3M for ; Tue, 8 May 2012 23:25:10 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 464D421F85EE for ; Tue, 8 May 2012 23:25:09 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oNxfG8HuwF53gi9vJlEk5xVt5f0dqo@postini.com; Tue, 08 May 2012 23:25:10 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 02:25:19 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 11:55:00 +0530 From: "Ravindran, Parthasarathi" To: Roman Shpount , Justin Uberti Thread-Topic: [rtcweb] Question about JSEP createOffer Thread-Index: AQHNLSluoHgR0lZnOEGRK8sd9ExIfZa/qTgAgAFS2DA= Date: Wed, 9 May 2012 06:24:59 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.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: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C160337BFinbamail01sonus_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:25:12 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C160337BFinbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Richard & Roman. "Full" re-OFFER MUST supported required for c= ouple of mid session scenario like 1) The session is established with audio and then video shall be added= in the middle in case complete offer is provided in re-OFFER. 2) It is possible to change the codec in the middle of the Session as= Roman mentioned. From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: Tuesday, May 08, 2012 9:03 PM To: Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about JSEP createOffer On Tue, May 8, 2012 at 10:46 AM, Justin Uberti > wrote: Richard, That is an interesting point. Could you give a short example of when such a= "full" re-OFFER would be used? There are a few ways we could handle this c= ase. Actually I was the person who argued that "full" capabilities should be pre= sent in original SIP O/A, when new offer is generated in an existing sessio= n. The use case for this are B2BUA that connect an existing session to a ne= w call or another existing session. Typically, B2BUA would ask one of the c= all parties for the offer (send an INVITE with no body in SIP), get the new= offer, and send this offer to the newly placed call. In order for this to = work, all the calling party capabilities should be listed in this new offer= , in particular all the codecs and all the communications types (audio, vid= eo, text, etc), or call would not be successfully established. _____________ Roman Shpount --_000_387F9047F55E8C42850AD6B3A7A03C6C160337BFinbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Richard &= ; Roman. “Full” re-OFFER MUST supported required for couple of = mid session scenario like

 <= /p>

1) = ;     The session is es= tablished with audio and then video shall be added in the middle in case co= mplete offer is provided in re-OFFER.

2) = ;      It is possi= ble to change the codec in the middle of the Session as Roman mentioned.

 <= /p>

 

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Question about JSEP createOffer

 


On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

Richard,

 

That is an interesting point. Could you give a short= example of when such a "full" re-OFFER would be used? There= are a few ways we could handle this case.

 


Actually I was the person who argued that "full" capabilities sho= uld be present in original SIP O/A, when new offer is generated in an exist= ing session. The use case for this are B2BUA that connect an existing sessi= on to a new call or another existing session. Typically, B2BUA would ask one of the call parties for the offer (send an = INVITE with no body in SIP), get the new offer, and send this offer to the = newly placed call. In order for this to work, all the calling party capabil= ities should be listed in this new offer, in particular all the codecs and all the communications types (audi= o, video, text, etc), or call would not be successfully established.
_____________
Roman Shpount

--_000_387F9047F55E8C42850AD6B3A7A03C6C160337BFinbamail01sonus_-- From pravindran@sonusnet.com Tue May 8 23:34:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE85521F85D1 for ; Tue, 8 May 2012 23:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 LSJ-FBqnVyFW for ; Tue, 8 May 2012 23:34:46 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D921F85D2 for ; Tue, 8 May 2012 23:34:39 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oP/3DK1ivgG4S2pxZPquIOa6bRx0Ta@postini.com; Tue, 08 May 2012 23:34:39 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 02:34:49 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 12:04:34 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , Christer Holmberg Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewALSsOAABK1rwAAF0kPAAAxgqEAAARcP4AAAHvUAAAArGiAAAB9ngAAAAq7AAAIW/WAAAB4jQAAAR30gAASfQ4AABLNEwAAA128gAAErXWAAAIxoAAAASAKgAAAF7EAAAAvPYAAAIyrgAAAaVoAAACEBgAA7qbDAAArq6qQ Date: Wed, 9 May 2012 06:34:33 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericsson.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C160337F1inbamail01sonus_" MIME-Version: 1.0 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:34:47 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C160337F1inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlcGx5LiBUaGVyZSBhcmUgdHdv IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggdGhpcyBzY2VuYXJpbzoNCg0KSXNzdWUgMSkgU0lQIEZv cmtpbmcgOiBUaGlzIGlzIHNvbHZlZCBieSBwZWVyY29ubmVjdGlvbiBjbG9uaW5nDQoNCklzc3Vl IDIpICBVUERBVEUgc3VwcG9ydCB3aXRoaW4gU0lQIGVhcmx5IGRpYWxvZyBpbiB0aGUgbm9uLWZv cmtpbmcgc2NlbmFyaW8uIEhlcmUsIHRoZSBjbG9uaW5nIHdpbGwgbm90IHNvbHZlIGlzc3VlIGFz IHRoZSBhbnN3ZXJlciBvcmlnaW5hdGVkIHRoZSBuZXcgb2ZmZXIgZHVyaW5nIFNEUF9QUkFOU1dF UiBzdGF0ZSAuIElzc3VlIDIgaXMgdGhlIHRpdGxlIG9mIHRoaXMgbWFpbCB0aHJlYWQuDQoNCklN TywgU0RQX1BSQU5TV0VSIHdpbGwgY29tcGxpY2F0ZSB0aGUgb2ZmZXIvYW5zd2VyIHN0YXRlIG1h Y2hpbmUuDQoNClRoYW5rcw0KUGFydGhhDQoNCg0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGlu IFViZXJ0aQ0KU2VudDogVHVlc2RheSwgTWF5IDA4LCAyMDEyIDg6NDAgUE0NClRvOiBDaHJpc3Rl ciBIb2xtYmVyZw0KQ2M6IFJhbmRlbGwgSmVzdXA7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtydGN3ZWJdIFNEUF9QUkFOU1dFUiBmb2xsb3dlZCBieSBTRFBfT0ZGRVIgc2NlbmFyaW8g aW4gSlNFUA0KDQpUaGUgY29uY2x1c2lvbiBvbiB0aGlzIHRocmVhZCBzZWVtcyB0byBiZSB0aGF0 IHRoZSByaWdodCB3YXkgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gaXMgdmlhIFBlZXJDb25uZWN0 aW9uIGNsb25pbmcsIGFuZCB0aGF0IG5vIGNoYW5nZXMgYXJlIG5lZWRlZCB0byB0aGUgSlNFUCBz dGF0ZSBtYWNoaW5lLiBJJ2xsIHdvcmsgd2l0aCBSaWNoYXJkIHRvIGZpZ3VyZSBvdXQgaG93IHdl IHNob3VsZCBleHRlbmQgSlNFUCB0byBzdXBwb3J0IGNsb25pbmcuDQpPbiBUaHUsIE1heSAzLCAy MDEyIGF0IDU6MTYgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K SGksDQoNCj4+Pj5Zb3UgY291bGQgYWxzbyBjaG9vc2Ugbm90IHRvIGFsZXJ0IHRoZSByZW1vdGUg dXNlciB1bnRpbCB0aGUgSUNFIHByb2NlZHVyZXMgaGF2ZSBmaW5pc2hlZCAtIG1vcmUgb3IgbGVz cyB1c2luZyBJQ0Ugd2l0aCBwcmVjb25kaXRpb25zLg0KPj4+Pg0KPj4+PiBPZiBjb3Vyc2UsIHRo YXQgaXMgZ29pbmcgdG8gdHJpZ2dlciBhY3Rpb25zIGluIFNUVU4vVFVSTiBzZXJ2ZXJzLCBldmVu IGlmIHRoZSBjYWxsZWQgcGFydHkgd29uJ3QgYWNjZXB0IHRoZSBjYWxsLCBidXQgYXQgbGVhc3Qg ZnJvbSBhIHVzZXINCj4+Pj4gZXhwZXJpZW5jZSBwZXJzcGVjdGl2ZSB0aGF0IGlzIHN0aWxsIGJl dHRlciB0aGFuIGxpZnRpbmcgdGhlIGhvb2ssIGFuZCBoYXZpbmcgdG8gd2FpdCBmb3Igd2hhdGV2 ZXItdGltZS1pdC10YWtlcy1mb3ItSUNFLXRvLWZpbmlzaCBzZWNvbmRzIGJlZm9yZSBvbmUgY2Fu IHN0YXJ0IHRvIHRhbGsuDQo+Pj4NCj4+PiBUaGlzIGFsc28gaGFzIGEgZG93bnNpZGUgb2YgZGlz Y2xvc2luZyB1c2VyJ3MgSVAgdG8gdGhlIGNhbGxlciB3aXRob3V0IHRoZSB1c2VyIGNvbmZpcm1h dGlvbi4gRm9yIGEgbG90IG9mIGFwcGxpY2F0aW9ucyB0aGlzIGNhbiBiZSBzZXJpb3VzIHNlY3Vy aXR5IGZsYXcuDQo+Pg0KPj4gVGhlIGNsaWVudCBjYW4gc3RpbGwgbG9nIHdoZW4gSUNFIHByb2Nl ZHVyZXMgb2NjdXIuDQo+Pg0KPj4gQmVjYXVzZSwgZXZlbiBpZiBJIHdhaXQgdW50aWwgeW91ciBw aG9uZSBzdGFydHMgdG8gcmluZywgbW9zdCBsaWtlbHkgSSB3b3VsZCBzdGlsbCBnZXQgeW91ciBJ UCBhZGRyZXNzIHdpdGhvdXQgdXNlciBjb25maXJtYXRpb24gKHNwZWFraW5nIGluIFNJUCB0ZXJt cywgcGhvbmVzIG5vcm1hbGx5IGRvbid0IGFzayBmb3IgdXNlciBwZXJtaXNzaW9uIGJlZm9yZSB0 aGV5IHNlbmQgMTh4IHdpdGggU0RQKSwgZXZlbnRob3VnaCB5b3Ugd291bGQgZWFzaWVyIGJlIG1h ZGUgYXdhcmUgb2YgdGhhdCBpdCBoYXBwZW5zLg0KPg0KPiBBbm90aGVyIGFsdGVybmF0aXZlIGlz IG9mIGNvdXJzZSB0byBkbyBJQ0Ugd2l0aCBhbiBTQkMsIGFuZC9vciBoYXZpbmcgYW4gU0JDIGRv aW5nIElDRSBvbiBiZWhhbGYgb2YgeW91IDopDQo+DQo+DQo+IFRoaXMgaXMgdHJ1ZSBmb3IgU0lQ IGJ1dCB3YXMgYXMgZmFyIGFzIEkga25vdyB3YXMgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIGFyb3Vu ZCBpbiBXZWJSVEMuIFdlYlJUQyBzaWduYWxpbmcgc2VydmVyIGFjdHMgYXMgQjJCVUEgc28gYW55 IHR5cGUgb2YgcmluZ2luZyBub3RpZmljYXRpb24gZ29lcyB0aHJvdWdoIHRoZSB3ZWIgc2VydmVy IGFuZCBkb2VzIG5vdCBuZWVkIHRvIGNhcnJ5IGFueSB0eXBlIG9mIGNsaWVudCBhZGRyZXNzIGlu Zm9ybWF0aW9uLiBUaGUgY2xpZW50IGFkZHJlc3MgaW5mb3JtYXRpb24gaXMgb25seSBwcm92aWRl ZA0KPiB3aGVuIFNEUCBhbnN3ZXIgaXMgc2VudCBvciBJQ0UgbmVnb3RpYXRpb24gaXMgc3RhcnRl ZC4NCkFzc3VtaW5nIHlvdSBhcmUgb25seSBnb2luZyB0byBtYWtlIHVzZXIgY29uZmlybWF0aW9u IChyZWFkOiBhY2NlcHQgY2FsbHMpIGluIGNhc2VzIHdoZXJlIHlvdSBhYnNvbHV0ZWx5IHN1cmUg dGhhdCB0aGUgY2FsbGVyIGlzbid0IHNvbWVvbmUgdHJ5aW5nIHRvIGdldCB5b3VyIElQIGFkZHJl c3MuDQoNCkJ1dCwgbmV2ZXIgdGhlIGxlc3MsIGhhdmluZyBhIHNvbHV0aW9uIHdoZXJlIEkgZmly c3QgaGF2ZSB0byBnaXZlIHVzZXIgY29uZmlybWF0aW9uLCBhbmQgdGhlbiB3YWl0IHVudGlsIEkg Y2FuIHN0YXJ0IHRvIHRhbGssIGlzIHByb2JhYmx5IHNvbWV0aGluZyBtb3N0IHBlb3BsZSB3YW50 IHRvIGF2b2lkLiBEZXBlbmRpbmcgdXBvbiwgb2YgY291cnNlLCBob3cgbG9uZyB0aGUgd2FpdGlu ZyB0aW1lIGlzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C160337F1inbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjA3Nzk0MzM2Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjMzNjc4MTc0IDY3 Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4 dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciB0aGUgZGVsYXkg aW4gcmVwbHkuIFRoZXJlIGFyZSB0d28gaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGlzIHNjZW5h cmlvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SXNzdWUgMSkgU0lQIEZvcmtpbmcgOiBUaGlzIGlzIHNvbHZlZCBieSBw ZWVyY29ubmVjdGlvbiBjbG9uaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Jc3N1ZSAyKSZuYnNwOyBVUERBVEUgc3Vw cG9ydCB3aXRoaW4gU0lQIGVhcmx5IGRpYWxvZyBpbiB0aGUgbm9uLWZvcmtpbmcgc2NlbmFyaW8u IEhlcmUsIHRoZSBjbG9uaW5nIHdpbGwgbm90IHNvbHZlIGlzc3VlIGFzIHRoZSBhbnN3ZXJlciBv cmlnaW5hdGVkIHRoZSBuZXcgb2ZmZXINCiBkdXJpbmcgU0RQX1BSQU5TV0VSIHN0YXRlIC4gSXNz dWUgMiBpcyB0aGUgdGl0bGUgb2YgdGhpcyBtYWlsIHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNTywgU0RQ X1BSQU5TV0VSIHdpbGwgY29tcGxpY2F0ZSB0aGUgb2ZmZXIvYW5zd2VyIHN0YXRlIG1hY2hpbmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBNYXkgMDgsIDIwMTIgODo0MCBQTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9s bWJlcmc8YnI+DQo8Yj5DYzo8L2I+IFJhbmRlbGwgSmVzdXA7IHJ0Y3dlYkBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gU0RQX1BSQU5TV0VSIGZvbGxvd2VkIGJ5IFNE UF9PRkZFUiBzY2VuYXJpbyBpbiBKU0VQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgY29uY2x1c2lv biBvbiB0aGlzIHRocmVhZCBzZWVtcyB0byBiZSB0aGF0IHRoZSByaWdodCB3YXkgdG8gYWRkcmVz cyB0aGlzIHByb2JsZW0gaXMgdmlhIFBlZXJDb25uZWN0aW9uIGNsb25pbmcsIGFuZCB0aGF0IG5v IGNoYW5nZXMgYXJlIG5lZWRlZCB0byB0aGUgSlNFUCBzdGF0ZSBtYWNoaW5lLiBJJ2xsIHdvcmsg d2l0aCBSaWNoYXJkIHRvIGZpZ3VyZQ0KIG91dCBob3cgd2Ugc2hvdWxkIGV4dGVuZCBKU0VQIHRv IHN1cHBvcnQgY2xvbmluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIE1heSAzLCAyMDEyIGF0IDU6MTYgUE0sIENocmlzdGVyIEhvbG1iZXJnICZs dDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SGksPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0O1lvdSBj b3VsZCBhbHNvIGNob29zZSBub3QgdG8gYWxlcnQgdGhlIHJlbW90ZSB1c2VyIHVudGlsIHRoZSBJ Q0UgcHJvY2VkdXJlcyBoYXZlIGZpbmlzaGVkIC0gbW9yZSBvciBsZXNzIHVzaW5nIElDRSB3aXRo IHByZWNvbmRpdGlvbnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgT2YgY291cnNlLCB0aGF0IGlzIGdvaW5nIHRvIHRyaWdnZXIgYWN0aW9ucyBpbiBTVFVOL1RV Uk4gc2VydmVycywgZXZlbiBpZiB0aGUgY2FsbGVkIHBhcnR5IHdvbid0IGFjY2VwdCB0aGUgY2Fs bCwgYnV0IGF0IGxlYXN0IGZyb20gYSB1c2VyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBleHBlcmll bmNlIHBlcnNwZWN0aXZlIHRoYXQgaXMgc3RpbGwgYmV0dGVyIHRoYW4gbGlmdGluZyB0aGUgaG9v aywgYW5kIGhhdmluZyB0byB3YWl0IGZvciB3aGF0ZXZlci10aW1lLWl0LXRha2VzLWZvci1JQ0Ut dG8tZmluaXNoIHNlY29uZHMgYmVmb3JlIG9uZSBjYW4gc3RhcnQgdG8gdGFsay48YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBhbHNvIGhhcyBhIGRvd25zaWRlIG9mIGRp c2Nsb3NpbmcgdXNlcidzIElQIHRvIHRoZSBjYWxsZXIgd2l0aG91dCB0aGUgdXNlciBjb25maXJt YXRpb24uIEZvciBhIGxvdCBvZiBhcHBsaWNhdGlvbnMgdGhpcyBjYW4gYmUgc2VyaW91cyBzZWN1 cml0eSBmbGF3Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGNsaWVudCBjYW4gc3Rp bGwgbG9nIHdoZW4gSUNFIHByb2NlZHVyZXMgb2NjdXIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBCZWNhdXNlLCBldmVuIGlmIEkgd2FpdCB1bnRpbCB5b3VyIHBob25lIHN0YXJ0cyB0byBy aW5nLCBtb3N0IGxpa2VseSBJIHdvdWxkIHN0aWxsIGdldCB5b3VyIElQIGFkZHJlc3Mgd2l0aG91 dCB1c2VyIGNvbmZpcm1hdGlvbiAoc3BlYWtpbmcgaW4gU0lQIHRlcm1zLCBwaG9uZXMgbm9ybWFs bHkgZG9uJ3QgYXNrIGZvciB1c2VyIHBlcm1pc3Npb24gYmVmb3JlIHRoZXkgc2VuZCAxOHggd2l0 aCBTRFApLCBldmVudGhvdWdoIHlvdSB3b3VsZCBlYXNpZXINCiBiZSBtYWRlIGF3YXJlIG9mIHRo YXQgaXQgaGFwcGVucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbm90aGVyIGFsdGVybmF0aXZlIGlz IG9mIGNvdXJzZSB0byBkbyBJQ0Ugd2l0aCBhbiBTQkMsIGFuZC9vciBoYXZpbmcgYW4gU0JDIGRv aW5nIElDRSBvbiBiZWhhbGYgb2YgeW91IDopPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoaXMgaXMgdHJ1ZSBmb3IgU0lQIGJ1dCB3YXMgYXMgZmFyIGFzIEkga25vdyB3YXMgc3BlY2lm aWNhbGx5IGRlc2lnbmVkIGFyb3VuZCBpbiBXZWJSVEMuIFdlYlJUQyBzaWduYWxpbmcgc2VydmVy IGFjdHMgYXMgQjJCVUEgc28gYW55IHR5cGUgb2YgcmluZ2luZyBub3RpZmljYXRpb24gZ29lcyB0 aHJvdWdoIHRoZSB3ZWIgc2VydmVyIGFuZCBkb2VzIG5vdCBuZWVkIHRvIGNhcnJ5IGFueSB0eXBl IG9mIGNsaWVudCBhZGRyZXNzIGluZm9ybWF0aW9uLg0KIFRoZSBjbGllbnQgYWRkcmVzcyBpbmZv cm1hdGlvbiBpcyBvbmx5IHByb3ZpZGVkPGJyPg0KJmd0OyB3aGVuIFNEUCBhbnN3ZXIgaXMgc2Vu dCBvciBJQ0UgbmVnb3RpYXRpb24gaXMgc3RhcnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bc3N1bWluZyB5b3UgYXJlIG9ubHkgZ29pbmcg dG8gbWFrZSB1c2VyIGNvbmZpcm1hdGlvbiAocmVhZDogYWNjZXB0IGNhbGxzKSBpbiBjYXNlcyB3 aGVyZSB5b3UgYWJzb2x1dGVseSBzdXJlIHRoYXQgdGhlIGNhbGxlciBpc24ndCBzb21lb25lIHRy eWluZyB0byBnZXQgeW91ciBJUCBhZGRyZXNzLjxicj4NCjxicj4NCkJ1dCwgbmV2ZXIgdGhlIGxl c3MsIGhhdmluZyBhIHNvbHV0aW9uIHdoZXJlIEkgZmlyc3QgaGF2ZSB0byBnaXZlIHVzZXIgY29u ZmlybWF0aW9uLCBhbmQgdGhlbiB3YWl0IHVudGlsIEkgY2FuIHN0YXJ0IHRvIHRhbGssIGlzIHBy b2JhYmx5IHNvbWV0aGluZyBtb3N0IHBlb3BsZSB3YW50IHRvIGF2b2lkLiBEZXBlbmRpbmcgdXBv biwgb2YgY291cnNlLCBob3cgbG9uZyB0aGUgd2FpdGluZyB0aW1lIGlzLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpSZWdhcmRzLDxicj4N Cjxicj4NCkNocmlzdGVyPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C160337F1inbamail01sonus_-- From Ranjit.Avasarala@Polycom.com Tue May 8 23:49:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9230621F8624 for ; Tue, 8 May 2012 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, 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 MbK3v5-wscqB for ; Tue, 8 May 2012 23:49:24 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 880F421F8623 for ; Tue, 8 May 2012 23:49:23 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 9 May 2012 14:49:21 +0800 From: "Avasarala, Ranjit" To: "rtcweb@ietf.org" Date: Wed, 9 May 2012 14:49:13 +0800 Thread-Topic: Mapping between SIP and ROAP/JSEP Thread-Index: Ac0tr4YLviHfLY88RY29wN4t47YFow== Message-ID: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> 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_1F2A2C70609D9E41844A2126145FC09804BCD25222HKGMBOXPRD22p_" MIME-Version: 1.0 Subject: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:49:24 -0000 --_000_1F2A2C70609D9E41844A2126145FC09804BCD25222HKGMBOXPRD22p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Is there any interest in the coming up with a mapping between SIP and ROAP/= JSEP protocols? Though JSEP is a set of APIs as of now which map closely w= ith ROAP APIs, ROAP has messages like OFFER,ANSWER and OK which can be mapp= ed to SIP. Comment? Thanks Regards Ranjit --_000_1F2A2C70609D9E41844A2126145FC09804BCD25222HKGMBOXPRD22p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Is there an= y interest in the coming up with a mapping between SIP and ROAP/JSEP protoc= ols?  Though JSEP is a set of APIs as of now which map closely with RO= AP APIs, ROAP has messages like OFFER,ANSWER and OK which can be mapped to = SIP.

 

Comment?

 

Thanks

 

Regards

Ranji= t

 

= --_000_1F2A2C70609D9E41844A2126145FC09804BCD25222HKGMBOXPRD22p_-- From pravindran@sonusnet.com Tue May 8 23:52:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCC21F84E4 for ; Tue, 8 May 2012 23:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, 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 Z3ZBFWh1Dfxz for ; Tue, 8 May 2012 23:52:46 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 209F121F8505 for ; Tue, 8 May 2012 23:52:46 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oUPUnrWMlb5xZk+pP8WAwRzeCsKDMM@postini.com; Tue, 08 May 2012 23:52:46 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 02:52:56 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 12:22:41 +0530 From: "Ravindran, Parthasarathi" To: "Avasarala, Ranjit" , "rtcweb@ietf.org" Thread-Topic: Mapping between SIP and ROAP/JSEP Thread-Index: Ac0tr4YLviHfLY88RY29wN4t47YFowAAJYtA Date: Wed, 9 May 2012 06:52:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16033818@inba-mail01.sonusnet.com> References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16033818inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:52:47 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16033818inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ranjit, I agree with you that Interworking document for JSEP to SIP is important fo= r developing the interworking solution. I'll interested in contributing one= such draft. Such a draft will help in identify the gap in JSEP to support = SIP interworking like UPDATE during early dialog. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Avasarala, Ranjit Sent: Wednesday, May 09, 2012 12:19 PM To: rtcweb@ietf.org Subject: [rtcweb] Mapping between SIP and ROAP/JSEP Hi Is there any interest in the coming up with a mapping between SIP and ROAP/= JSEP protocols? Though JSEP is a set of APIs as of now which map closely w= ith ROAP APIs, ROAP has messages like OFFER,ANSWER and OK which can be mapp= ed to SIP. Comment? Thanks Regards Ranjit --_000_387F9047F55E8C42850AD6B3A7A03C6C16033818inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ranjit,

 

I agree with you that = Interworking document for JSEP to SIP is important for developing the inter= working solution. I’ll interested in contributing one such draft. Suc= h a draft will help in identify the gap in JSEP to support SIP interworking like UPDATE during early dialog.

 

Thanks

Partha

 

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Avasarala, Ranjit
Sent: Wednesday, May 09, 2012 12:19 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Mapping between SIP and ROAP/JSEP

 

Hi

 

Is there any interest in the coming up with a mappin= g between SIP and ROAP/JSEP protocols?  Though JSEP is a set of APIs a= s of now which map closely with ROAP APIs, ROAP has messages like OFFER,ANS= WER and OK which can be mapped to SIP.

 

Comment?

 

Thanks

 

Regards

Ranjit

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C16033818inbamail01sonus_-- From harald@alvestrand.no Tue May 8 23:56:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7A21F85EE for ; Tue, 8 May 2012 23:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.435 X-Spam-Level: X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 atKg0wBjXZ0O for ; Tue, 8 May 2012 23:56:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 40EDB21F85EA for ; Tue, 8 May 2012 23:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C650639E262; Wed, 9 May 2012 08:56:13 +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 EjlNdrEOJAfC; Wed, 9 May 2012 08:56:13 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 45A2839E08B; Wed, 9 May 2012 08:56:13 +0200 (CEST) Message-ID: <4FAA150C.5020301@alvestrand.no> Date: Wed, 09 May 2012 08:56:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Eric Rescorla References: <4FA99618.9050700@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:56:17 -0000 On 05/08/2012 11:59 PM, Eric Rescorla wrote: > On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand wrote: >> Just because I realized I didnt understand something, I ask..... >> >> We rejected RTCP RR as a consent freshness mechanism because RR is trivial >> to fake. >> But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs >> are integrity protected, origin authenticated and replay protected (do I >> have that right?). >> >> What is the reason why this is not sufficient protection to use RTCP RR as a >> consent freshness mechanism? > This isn't a complete analysis, but if you are using SDES for key management, > then the site knows the SRTCP keys, so I don't *think* SRTCP is buying you > much. I haven't thought through this completely though, so maybe there is > still some additional value. Ah - had forgotten that the attacker is assumed to observe the signalling path. Thanks. From harald@alvestrand.no Wed May 9 00:01:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5199A21F85EF for ; Wed, 9 May 2012 00:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 O5jI-OKmcpwn for ; Wed, 9 May 2012 00:01:30 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6DD21F8559 for ; Wed, 9 May 2012 00:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5504239E262 for ; Wed, 9 May 2012 09:01:29 +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 KtFCv6blcXye for ; Wed, 9 May 2012 09:01:28 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 67B7439E08B for ; Wed, 9 May 2012 09:01:28 +0200 (CEST) Message-ID: <4FAA1647.4080901@alvestrand.no> Date: Wed, 09 May 2012 09:01:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C16033818@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16033818@inba-mail01.sonusnet.com> Content-Type: multipart/alternative; boundary="------------090802030803090305090309" Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:01:31 -0000 This is a multi-part message in MIME format. --------------090802030803090305090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/09/2012 08:52 AM, Ravindran, Parthasarathi wrote: > > Ranjit, > > I agree with you that Interworking document for JSEP to SIP is > important for developing the interworking solution. I?ll interested in > contributing one such draft. Such a draft will help in identify the > gap in JSEP to support SIP interworking like UPDATE during early dialog. > Since JSEP is an API, and has been implemented, I suggest that the most reasonable form of documentation is an opensource SIP implementation on top of JSEP, not an internet-draft. If someone wants to contribute such code, I'm sure we can host it as part of webrtc-samples, if that helps - the other piece would be a recipe for setting up some opensource SIP server to prove that it actually works. Running code has the advantage that it is easy to test it. --------------090802030803090305090309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 05/09/2012 08:52 AM, Ravindran, Parthasarathi wrote:

Ranjit,

 

I agree with you that Interworking document for JSEP to SIP is important for developing the interworking solution. I’ll interested in contributing one such draft. Such a draft will help in identify the gap in JSEP to support SIP interworking like UPDATE during early dialog.

Since JSEP is an API, and has been implemented, I suggest that the most reasonable form of documentation is an opensource SIP implementation on top of JSEP, not an internet-draft.

If someone wants to contribute such code, I'm sure we can host it as part of webrtc-samples, if that helps - the other piece would be a recipe for setting up some opensource SIP server to prove that it actually works.

Running code has the advantage that it is easy to test it.

--------------090802030803090305090309-- From pravindran@sonusnet.com Wed May 9 00:15:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D467721F85E3 for ; Wed, 9 May 2012 00:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 PEEvWWqV8N6N for ; Wed, 9 May 2012 00:15:25 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id BF85F21F85C9 for ; Wed, 9 May 2012 00:15:24 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oZjBLqhC2g22CjmKla95I0M8Q6mds8@postini.com; Wed, 09 May 2012 00:15:24 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 03:15:34 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 12:45:19 +0530 From: "Ravindran, Parthasarathi" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Mapping between SIP and ROAP/JSEP Thread-Index: Ac0tr4YLviHfLY88RY29wN4t47YFowAAJYtA//+mr4D//6OCsA== Date: Wed, 9 May 2012 07:15:18 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16033869@inba-mail01.sonusnet.com> References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> <387F9047F55E8C42850AD6B3A7A03C6C16033818@inba-mail01.sonusnet.com> <4FAA1647.4080901@alvestrand.no> In-Reply-To: <4FAA1647.4080901@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16033869inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:15:27 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16033869inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, My guess is that running code already exists in the form of SIP over websoc= ket. The point is not about the running code. The running code will not cov= er all the offer/answer state machine issues which I'm talking about. The r= unning code is just equivalent to proof of concept but will not cover all t= he deployable solution and does not cover all the existing offer/answer . Even though JSEP is projected as API, offer/pr-answer/answer state MUST be = traversed in some magic way between two web-browsers for establishing the s= ession and these states are not possible to directly map with RFC 3264 or R= FC 3261 (SIP) usage. So, there is a need of interworking document. The poin= t to be noted is that the interworking between JSEP to SIP shall occur at b= rowser or at WebRTC server. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Wednesday, May 09, 2012 12:31 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP On 05/09/2012 08:52 AM, Ravindran, Parthasarathi wrote: Ranjit, I agree with you that Interworking document for JSEP to SIP is important fo= r developing the interworking solution. I'll interested in contributing one= such draft. Such a draft will help in identify the gap in JSEP to support = SIP interworking like UPDATE during early dialog. Since JSEP is an API, and has been implemented, I suggest that the most rea= sonable form of documentation is an opensource SIP implementation on top of= JSEP, not an internet-draft. If someone wants to contribute such code, I'm sure we can host it as part o= f webrtc-samples, if that helps - the other piece would be a recipe for set= ting up some opensource SIP server to prove that it actually works. Running code has the advantage that it is easy to test it. --_000_387F9047F55E8C42850AD6B3A7A03C6C16033869inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

My guess is that runni= ng code already exists in the form of SIP over websocket. The point is not = about the running code. The running code will not cover all the offer/answe= r state machine issues which I’m talking about. The running code is just equivalent to proof of concept but will no= t cover all the deployable solution and does not cover all the existing off= er/answer .

 

Even though JSEP is pr= ojected as API, offer/pr-answer/answer state MUST be traversed in some magi= c way between two web-browsers for establishing the session and these state= s are not possible to directly map with RFC 3264 or RFC 3261 (SIP) usage. So, there is a need of interworking docu= ment. The point to be noted is that the interworking between JSEP to SIP sh= all occur at browser or at WebRTC server.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ie= tf.org] On Behalf Of Harald Alvestrand
Sent: Wednesday, May 09, 2012 12:31 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP

 

On 05/09/2012 08:52 AM, Ravindran, Parthasarathi wro= te:

Ranjit,

 

I agree with you that = Interworking document for JSEP to SIP is important for developing the inter= working solution. I’ll interested in contributing one such draft. Suc= h a draft will help in identify the gap in JSEP to support SIP interworking like UPDATE during early dialog.

Since= JSEP is an API, and has been implemented, I suggest that the most reasonab= le form of documentation is an opensource SIP implementation on top of JSEP, not an internet-draft.

If someone wants to contribute such code, I'm sure we can host it as part o= f webrtc-samples, if that helps - the other piece would be a recipe for set= ting up some opensource SIP server to prove that it actually works.

Running code has the advantage that it is easy to test it.

--_000_387F9047F55E8C42850AD6B3A7A03C6C16033869inbamail01sonus_-- From magnus.westerlund@ericsson.com Wed May 9 00:31:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517D21F85A0 for ; Wed, 9 May 2012 00:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFinzyyMFYvE for ; Wed, 9 May 2012 00:31:16 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 665F321F859E for ; Wed, 9 May 2012 00:31:16 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-55-4faa1d42b9d4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 90.EC.32015.24D1AAF4; Wed, 9 May 2012 09:31:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 09:31:14 +0200 Message-ID: <4FAA1D41.8070003@ericsson.com> Date: Wed, 9 May 2012 09:31:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <4FA99618.9050700@alvestrand.no> In-Reply-To: <4FA99618.9050700@alvestrand.no> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:31:17 -0000 On 2012-05-08 23:54, Harald Alvestrand wrote: > Just because I realized I didnt understand something, I ask..... > > We rejected RTCP RR as a consent freshness mechanism because RR is > trivial to fake. > But - now we have SRTP as mandatory-to-use, which means that all RTCP > RRs are integrity protected, origin authenticated and replay protected > (do I have that right?). > > What is the reason why this is not sufficient protection to use RTCP RR > as a consent freshness mechanism? > I agree that SRTP will not really buy you much. Even using DTLS-SRTP there are attack vectors for the case where the attacker is willing to start in the attacked network and then move his signalling and crypto state to an off-path source address spoofing consent freshness generating bot. Thus leaving the stream alive for a long time. The issue with RTCP is the amount of entropy in each RTCP packets that are hard to guess given an off-path attacker and which the media sender verifying consent can determine correctly. Revisiting the discussion from September last year on this topic. Especially my estimate of entropy sources in RTCP that can't be guessed: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html The only two fields that an off-path attacker can't easily spoof in an RTCP RR are: - last SR (LSR) - Extended highest sequence number And here the first one is the one that is more valuable as it is the senders RTCP SR NTP timestamp field. Yes, it will increase as time goes one, but the lower bits of this field when the actual RTCP SR was sent is difficult to spoof correctly. The sequence number is also a bit difficult to spoof if you don't see the packets being sent. However, as this is not a field copied directly from the latest received RTCP SR packet and thus need to be tolerant to packet losses etc and thus accept a window of the from the latest actually sent any sent the last few seconds. I do think we can have consent freshness based on that three RTCP packets in a time window of 30 seconds or some number of reporting intervals that do not contain a clear error an actual receiver wouldn't do, would keep the media stream alive. I would probably also add in cases I get 3 RTCP packets in a row that matches security but contains errors would directly kill the stream. Here actually SRTCP does help. Because you can use SRTCP to ensure that the denial of service vector on this second rule can't be triggered by someone outside of the security context. However, the question about consent freshness I think needs to consider also if this RTCP rule is in fact reasonable for legacy interworking cases. For a gateway responding to STUN messages are probably easier than in addition to being able to do ICE initially also need a full RTP stack to generate RTCP reports for any legacy end-point that doesn't implement RTCP. This may however be a mote point depending on what requirements on congestion control we put on the legacy interworking gateway. My personal perspective is that we actually need to consider all the aspects and see if in the end there is any advantage of either using RTCP or only using STUN. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mperumal@cisco.com Wed May 9 00:35:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767A021F849A for ; Wed, 9 May 2012 00:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 NPEXSn1+E2Kn for ; Wed, 9 May 2012 00:34:59 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5943A21F8491 for ; Wed, 9 May 2012 00:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2384; q=dns/txt; s=iport; t=1336548899; x=1337758499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6SliWO4zQ+OEjgDi0O+wjManBKR6F8s6kApHj7gfygI=; b=Vz30egN1EOPDIv1VjNzFem1F5MLO1dk+qhhr9lJM8LGDROu3cXjMJeFb hlYkvhp66HiLlLxnQUHgAc0qgyrL7LAPc6clSwhatpOA5uuDdFr9aYcdC TXm4KxFempheDWedp+eJZvRCFmahUyitjnICspmLflMJ/e92D1ejPcJbA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJEdqk9Io8UY/2dsb2JhbABEtEeCDAEBAQQBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEmHwkIAQEEAQoICAEZh2wLmnugMIsMGYUWYwSIYptzgWmCcYFOBwER X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="11770981" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 May 2012 07:34:57 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q497YvPo024040; Wed, 9 May 2012 07:34:57 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 13:04:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 May 2012 13:04:56 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020865B735@XMB-BGL-414.cisco.com> In-Reply-To: <4FAA150C.5020301@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Consent freshness - revisiting the RTCP option Thread-Index: Ac0tsNqCEaA9e71pQsqr9NpOv87TXwAA46mg References: <4FA99618.9050700@alvestrand.no> <4FAA150C.5020301@alvestrand.no> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Harald Alvestrand" , "Eric Rescorla" X-OriginalArrivalTime: 09 May 2012 07:34:57.0084 (UTC) FILETIME=[3B99B7C0:01CD2DB6] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:35:00 -0000 More reasons why RTCP may not be suitable for consent freshness: 1. RTCP (as described in RFC3550) is receiver based, so the browser can't explicitly request for consent. If consent freshness fails (for e.g, RTCP packets temporarily lost because of network flapping), the browser would have to wait for the peer to send RTCP before it can start transmitting media. Worst, if the peer isn't an active sender it may not send any RTCP RR until it receives media. It could send a bare minimum RTCP RR (an RR with RC=3D0 and SDES with CNAME), but that has zero entropy: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html 2. There are still some endpoints that don't send / pay attention to RTCP: http://www.ietf.org/mail-archive/web/rai/current/msg01257.html For these cases an intermediary like an SBC would have to manufacture them. Manufacturing them for just consent freshness would be expensive compared to generating STUN request/response. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand |Sent: Wednesday, May 09, 2012 12:26 PM |To: Eric Rescorla |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option | |On 05/08/2012 11:59 PM, Eric Rescorla wrote: |> On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand wrote: |>> Just because I realized I didnt understand something, I ask..... |>> |>> We rejected RTCP RR as a consent freshness mechanism because RR is trivial |>> to fake. |>> But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs |>> are integrity protected, origin authenticated and replay protected (do I |>> have that right?). |>> |>> What is the reason why this is not sufficient protection to use RTCP RR as a |>> consent freshness mechanism? |> This isn't a complete analysis, but if you are using SDES for key management, |> then the site knows the SRTCP keys, so I don't *think* SRTCP is buying you |> much. I haven't thought through this completely though, so maybe there is |> still some additional value. |Ah - had forgotten that the attacker is assumed to observe the |signalling path. Thanks. | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From likepeng@huawei.com Wed May 9 01:21:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B156721F85B1 for ; Wed, 9 May 2012 01:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.446 X-Spam-Level: ** X-Spam-Status: No, score=2.446 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOJfgJZCS2Bd for ; Wed, 9 May 2012 01:21:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35821F85AF for ; Wed, 9 May 2012 01:21:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFZ03100; Wed, 09 May 2012 04:21:48 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 01:18:33 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 01:18:36 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 9 May 2012 16:18:31 +0800 From: Likepeng To: "Avasarala, Ranjit" , "rtcweb@ietf.org" Thread-Topic: Mapping between SIP and ROAP/JSEP Thread-Index: Ac0tr4YLviHfLY88RY29wN4t47YFowAC8oJA Date: Wed, 9 May 2012 08:18:31 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2035816DE@szxeml525-mbs.china.huawei.com> References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.51] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F2035816DEszxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 08:21:54 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2035816DEszxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayBpdCBpcyB1c2VmdWwgdG8gaGF2ZSBzdWNoIGEgZHJhZnQgd2hpY2ggcHJvdmlkZXMg YSBtYXBwaW5nIGJldHdlZW4gU0lQIGFuZCBST0FQL0pTRVAgcHJvdG9jb2xzLg0KDQpQcmV2aW91 c2x5IEN1bGxlbiBoYXMgYW4gZXhwaXJlZCBkcmFmdCByZWxhdGVkIHRvIHRoaXM6DQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qZW5uaW5ncy1ydGN3ZWItc2lnbmFsaW5nLWdhdGV3 YXktMDANCg0KU29tZSB0aW1lIGFnbywgSSBzdWJtaXR0ZWQgYSBkcmFmdCB0byBtYXAgUk9BUCB3 aXRoIFhNUFAvSmluZ2xlLg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s aS1ydGN3ZWItcm9hcC1qaW5nbGUtaW50ZXJ3b3JraW5nLw0KDQpJIG5lZWQgdG8gdXBkYXRlIGl0 IHRvIHJlZmxlY3QgdGhlIEpTRVAgY29uY2VwdC4NCg0KSSB3b3VsZCBhcHByZWNpYXRlIGlmIGFu eWJvZHkgaGFzIGludGVyZXN0IHRvIHdvcmsgd2l0aCBtZSBhYm91dCB0aGlzLg0KDQpUaGFua3Ms DQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0Kt6K8/sjLOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEF2YXNhcmFsYSwgUmFuaml0DQq3 osvNyrG85DogMjAxMsTqNdTCOcjVIDE0OjQ5DQrK1bz+yMs6IHJ0Y3dlYkBpZXRmLm9yZw0K1vfM 4jogW3J0Y3dlYl0gTWFwcGluZyBiZXR3ZWVuIFNJUCBhbmQgUk9BUC9KU0VQDQoNCkhpDQoNCklz IHRoZXJlIGFueSBpbnRlcmVzdCBpbiB0aGUgY29taW5nIHVwIHdpdGggYSBtYXBwaW5nIGJldHdl ZW4gU0lQIGFuZCBST0FQL0pTRVAgcHJvdG9jb2xzPyAgVGhvdWdoIEpTRVAgaXMgYSBzZXQgb2Yg QVBJcyBhcyBvZiBub3cgd2hpY2ggbWFwIGNsb3NlbHkgd2l0aCBST0FQIEFQSXMsIFJPQVAgaGFz IG1lc3NhZ2VzIGxpa2UgT0ZGRVIsQU5TV0VSIGFuZCBPSyB3aGljaCBjYW4gYmUgbWFwcGVkIHRv IFNJUC4NCg0KQ29tbWVudD8NCg0KVGhhbmtzDQoNClJlZ2FyZHMNClJhbmppdA0KDQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F2035816DEszxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I think it is useful to have such a draft which provides a mappin= g between SIP and ROAP/JSEP protocols.

 

Previously Cullen has an expired draft related to this:

http://tools.ietf.org/html/draft-jennings-rtcweb-signaling= -gateway-00

 

Some time ago, I submitted a draft to map ROAP with XMPP/Jingle.<= o:p>

http://datatracker.ietf.org/doc/draft-li-rtcweb-roap-j= ingle-interworking/

 

I need to update it to reflect the JSEP concept.

 

I would appreciate if anybody has interest to work with me about = this.

 

Thanks,

Kind Regards

Kepeng

=B7=A2=BC=FE=C8=CB: rtcweb-= bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] =B4=FA= =B1=ED Avasarala, Ranjit
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA5=D4=C29=C8=D5 14:49
=CA=D5=BC=FE=C8=CB: rtcweb@ietf.org
=D6=F7=CC=E2: [rtcweb] Mapping between SIP and ROAP/JSEP

 

Hi

 

Is there any interest in the co= ming up with a mapping between SIP and ROAP/JSEP protocols?  Though JS= EP is a set of APIs as of now which map closely with ROAP APIs, ROAP has me= ssages like OFFER,ANSWER and OK which can be mapped to SIP.

 

Comment?

 

Thanks

 

Regards

Ranjit

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F2035816DEszxeml525mbschi_-- From harald@alvestrand.no Wed May 9 02:59:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5498C21F85AF for ; Wed, 9 May 2012 02:59:51 -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 Q9cYZfQxCskT for ; Wed, 9 May 2012 02:59:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AEFA121F84D6 for ; Wed, 9 May 2012 02:59:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0028939E262; Wed, 9 May 2012 11:59:50 +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 EC5DfvjyNw5n; Wed, 9 May 2012 11:59:48 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 94C7C39E08B; Wed, 9 May 2012 11:59:48 +0200 (CEST) Message-ID: <4FAA4013.4020609@alvestrand.no> Date: Wed, 09 May 2012 11:59:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <4FA99618.9050700@alvestrand.no> <4FAA150C.5020301@alvestrand.no> <1D062974A4845E4D8A343C65380492020865B735@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020865B735@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:59:51 -0000 On 05/09/2012 09:34 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > More reasons why RTCP may not be suitable for consent freshness: > 1. RTCP (as described in RFC3550) is receiver based, so the browser > can't explicitly request for consent. If consent freshness fails (for > e.g, RTCP packets temporarily lost because of network flapping), the > browser would have to wait for the peer to send RTCP before it can start > transmitting media. Worst, if the peer isn't an active sender it may not > send any RTCP RR until it receives media. It could send a bare minimum > RTCP RR (an RR with RC=0 and SDES with CNAME), but that has zero > entropy: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html Of course endpoints are expected to be RFC 3550 compliant, which includes obeying the diktat of section 6.3.5: "Every SSRC that hasn't sent an RTP or RTCP packet for 5*5 seconds is dead". > 2. There are still some endpoints that don't send / pay attention to > RTCP: > http://www.ietf.org/mail-archive/web/rai/current/msg01257.html > > For these cases an intermediary like an SBC would have to manufacture > them. Manufacturing them for just consent freshness would be expensive > compared to generating STUN request/response. For non-RTCP entities, we need an RTCP-generating gateway in order to interwork. End of story. (My opinion.) From ted.ietf@gmail.com Wed May 9 08:52:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3436921F846B for ; Wed, 9 May 2012 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 Gv325i00Vwsl for ; Wed, 9 May 2012 08:52:14 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE8E21F8566 for ; Wed, 9 May 2012 08:52:14 -0700 (PDT) Received: by qcsq13 with SMTP id q13so399578qcs.31 for ; Wed, 09 May 2012 08:52:14 -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:cc:content-type; bh=wXOVrGFEG0uBPY9Yi3zCk0VWvq6Qe1QcXhy/X6sQw/s=; b=lGy/W3Im8rVwC7663US8V/s/In3EQl5Vxx8rwoz8mXXrSRjrB0BJ+olue5a3j14Jo6 JlkYLo9AqtTKEi6qTR9Y22deajVtsInBxNWdgXuo222ixZKtumNgWRiYbkeuuyXr/l0M BpWCn7WOBMYyalZoZoe1wpX5LU7MOZLCT4dRqeDh77TdZAHfCzHM7ApQc1c5TQ1f72xP 3KvGWSBxkoGwb7Yc4dL/QX40yEkIFrzK0JTku7Pt3YPBAkiz/sBxcBdq03jz4te1LkDw Yz4m7GBQIZvX6V12naI4Ab5reoZxBCvKzYBvXnu82xKPbOfmlZeNAWb3ijgOBEX1ZDRb LAfA== MIME-Version: 1.0 Received: by 10.229.135.202 with SMTP id o10mr318470qct.84.1336578734129; Wed, 09 May 2012 08:52:14 -0700 (PDT) Received: by 10.229.25.199 with HTTP; Wed, 9 May 2012 08:52:13 -0700 (PDT) Date: Wed, 9 May 2012 08:52:13 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Strawman agenda and documents deadline for interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:52:17 -0000 Howdy, We would like document updates for the interim to be complete by June 4th, so that folks have time to review them before the interim meeting. Slides associated with the documents should be in by June 9th. Below is the current strawman agenda; please comment. regards, Ted, Cullen, Magnus Day 1 - Use Cases (2 H) * New use cases needing additional discussion if not resolved on mailing list. * Use cases that require cloning (yes or no?) - WebRTC's RTP Usage (3 H) * Topologies that need to be supported - what can be at one end of peer connection and what can be at other end * Walk through of all the pieces suggested - how to map media streams to rtp session. -- example: describe how retransmission SSRCs relate to main SSRCs - mapping between RTP and what happens in JS - JSEP * Discussion of State Machine * Interactions allowed * SDP specification -- mapping between SDP and what happens in JS - Security * Continued Consent * Identity and IdP * Details of Security Architecture From juberti@google.com Wed May 9 19:54:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A069E800B for ; Wed, 9 May 2012 19:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 BoSESSVLIlN5 for ; Wed, 9 May 2012 19:54:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 943AF9E8006 for ; Wed, 9 May 2012 19:54:15 -0700 (PDT) Received: by yhq56 with SMTP id 56so1224818yhq.31 for ; Wed, 09 May 2012 19:54:15 -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:x-system-of-record; bh=x7D12QA14AxgJjr/i7yYnBCh9/Mw4S0/WCGiYOvEaYg=; b=fTvNv56kT/Fnw2OgPyNDq8FKWCaAK00tDgnun6N/9hxLatyP6QEpx7HtOgNF0N7i1d ov7dz4SftmNaZjQuO7y7RWIaNS23P+yGT9j8ffeVL8bQxrNHOj79KrSKcLymz/PexaLW lEXbtNLJuyJDgBiSvT/dSB1W6IM4E/vLEDZ+hWJoDGYkNsHkkv9aK5QDmKbAcI9uanCg UwjXgWN4oziPrlPCypdXF/gHtvEpxXl7S+yhgVzXMtdcFKrrBHnLw7goJ5J8Awyp/CHb k8dBquwaWnBg6lXX2/iR9UT+e+9ADFhv3MK+KBd1y/hup2aZuk01fwvAvH3/nLkWAAFv RvDg== 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-system-of-record:x-gm-message-state; bh=x7D12QA14AxgJjr/i7yYnBCh9/Mw4S0/WCGiYOvEaYg=; b=dQu+Vq57Os7EJsrdtj2nYRVTLc0BYRmU3F2yUFO8Hk2wxMSvsfM9oQLH42do0Vxifp U+gk1Fg8Vn4rcdLBjxSu6LHUqAChMV3yeZ4YTqDixtNV7ZYODBXXBaKl240V0GM5HY9k iytvRMY08lAxsuR+ZTMPY/71qpSiBG2n2J5I+RCRnVXetVhes2sOQbah8er1KkYb8Xk1 rUKGsP5YtdvNRIQbasHKyMspepCftkWcYGrwclggj2REuCQchcIdGIpmelmaOM+ln32H a1sGdFMzvSK9fN0c0Dj6I65pMaX7AeEzl17Q504W+zX2XAC4+hkebJWw4QgIaCrObJAZ ek6w== Received: by 10.50.153.168 with SMTP id vh8mr2808185igb.16.1336618454987; Wed, 09 May 2012 19:54:14 -0700 (PDT) Received: by 10.50.153.168 with SMTP id vh8mr2808178igb.16.1336618454870; Wed, 09 May 2012 19:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.218 with HTTP; Wed, 9 May 2012 19:53:53 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2035816DE@szxeml525-mbs.china.huawei.com> References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2035816DE@szxeml525-mbs.china.huawei.com> From: Justin Uberti Date: Wed, 9 May 2012 22:53:53 -0400 Message-ID: To: Likepeng Content-Type: multipart/alternative; boundary=e89a8f2357c733e8e604bfa5bc47 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmn3eaofKDtVHd9XcmlizxyLwJc6mUKQvAc/g2FKLXtTBbTYKwMSCDT4830rx/JmLPCmDGH0qZKAYLYcCDaDDpLiAy3L7+DJqq0xPMkxE3sRGCNm62nHocOVi3f3Z7IKwQG2Sw+ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 02:54:16 -0000 --e89a8f2357c733e8e604bfa5bc47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would be willing to review a JSEP-XMPP draft. On Wed, May 9, 2012 at 4:18 AM, Likepeng wrote: > I think it is useful to have such a draft which provides a mapping > between SIP and ROAP/JSEP protocols.**** > > ** ** > > Previously Cullen has an expired draft related to this:**** > > http://tools.ietf.org/html/draft-jennings-rtcweb-signaling-gateway-00**** > > ** ** > > Some time ago, I submitted a draft to map ROAP with XMPP/Jingle.**** > > http://datatracker.ietf.org/doc/draft-li-rtcweb-roap-jingle-interworking/= * > *** > > ** ** > > I need to update it to reflect the JSEP concept.**** > > ** ** > > I would appreciate if anybody has interest to work with me about this.***= * > > ** ** > > Thanks,**** > > Kind Regards**** > > Kepeng**** > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* rtcweb-bounces@ietf.org [mailto:rtcweb-bou= nces@ietf.org] *=E4=BB=A3=E8=A1=A8 *Avasarala, > Ranjit > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2012=E5=B9=B45=E6=9C=889=E6=97=A5= 14:49 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* rtcweb@ietf.org > *=E4=B8=BB=E9=A2=98:* [rtcweb] Mapping between SIP and ROAP/JSEP**** > > ** ** > > Hi**** > > ** ** > > Is there any interest in the coming up with a mapping between SIP and > ROAP/JSEP protocols? Though JSEP is a set of APIs as of now which map > closely with ROAP APIs, ROAP has messages like OFFER,ANSWER and OK which > can be mapped to SIP.**** > > ** ** > > Comment?**** > > ** ** > > Thanks**** > > ** ** > > Regards**** > > Ranjit**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f2357c733e8e604bfa5bc47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would be willing to review a JSEP-XMPP draft.


--e89a8f2357c733e8e604bfa5bc47-- From stpeter@stpeter.im Wed May 9 20:00:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6711E8087 for ; Wed, 9 May 2012 20:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 6nFBfFsrz0Ec for ; Wed, 9 May 2012 20:00:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 606DF9E8006 for ; Wed, 9 May 2012 20:00:41 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6C17C40058; Wed, 9 May 2012 21:16:03 -0600 (MDT) Message-ID: <4FAB2F57.6080805@stpeter.im> Date: Wed, 09 May 2012 21:00:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Justin Uberti References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2035816DE@szxeml525-mbs.china.huawei.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 03:00:41 -0000 On 5/9/12 8:53 PM, Justin Uberti wrote: > I would be willing to review a JSEP-XMPP draft. Same here. Peter From juberti@google.com Wed May 9 20:02:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2935911E80E9 for ; Wed, 9 May 2012 20:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXc-p3IXFDPF for ; Wed, 9 May 2012 20:02:40 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6F11E80B0 for ; Wed, 9 May 2012 20:02:40 -0700 (PDT) Received: by yhq56 with SMTP id 56so1231160yhq.31 for ; Wed, 09 May 2012 20:02:40 -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:x-system-of-record; bh=mvACcfLeMov1xdres+n1+CjUw1u5SKdqGNBll1inQtM=; b=kvPFimsxDo7BA5WH5QbRKsinF/m2AELptNFR/9TDPc2v9efhrQDBeOZb/6RTrAU/wA L6BAn9fpnFQ3nwiud5ZnC9nnG+uKZxh5d6F73ZPKDbMjpEHIsKWqGCWwr0HRj4hxKO0z NfY39TOGdWlWvW0DPuc8pbz/xEAhk2ErvzDGoPAjWBxcroGmYTpJ5rT8/F7xGQbdJ1Ey qTfzajZTk7jqlNnh54ppDhmOxpunQC5RBX2AOPApgj7PRyd7rpRKfpcVzX1FqKwvHLr2 je8ESJaJ9TdybQ5di+Al5JZoewzMcFFTXNqCX7M9qqOnUfF9MDnC/11IgKfGx/Hfu8Ot 8UvQ== 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-system-of-record:x-gm-message-state; bh=mvACcfLeMov1xdres+n1+CjUw1u5SKdqGNBll1inQtM=; b=fAT6WieWMsIVrQMtGYW9BvG05DWp1HC2tKxw7UmZ1vgEGPwWAvclFr9qQC94Vz7/lL ZFKJYtt6qm58sHr4YfQkiP3hGczNRewlGjiXgF9bmf4Fge+yuWWLBUQOoBHC6Lal8oog H7vYDi2d4b7f8/RwqhQ2E5+w1Il7GtUJ4lnXHfSJLQj500hMYwg6yOPpAysF23LdHRIQ 1w+azlg+lkyzFV2I6A/EQpSr3LwbcCwChwFUesNu5p7l/r0Fu6c0vu8M+48P9Rf0mbw3 vCPB97pecvARs/DeVT6VflmpSqcTQsdklKkA30eOW1vIE3UQMzyzHEe11kOTO7104fNj rLvQ== Received: by 10.50.149.226 with SMTP id ud2mr1423502igb.74.1336618959789; Wed, 09 May 2012 20:02:39 -0700 (PDT) Received: by 10.50.149.226 with SMTP id ud2mr1423496igb.74.1336618959634; Wed, 09 May 2012 20:02:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.218 with HTTP; Wed, 9 May 2012 20:02:16 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> From: Justin Uberti Date: Wed, 9 May 2012 23:02:16 -0400 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=e89a8f2347b54a00e904bfa5da3b X-System-Of-Record: true X-Gm-Message-State: ALoCoQmIUEsXQNYiHivo7jSeqc5ZcPi7PIO8SYNkZ4qNvtd0sM3WAMdh0YsNTWWNk2w6XePJseOOxI0YWvU0qMnORFjeQMY4AEKxS3W5UMe6/ovyIsXMLugbjalsPhrk390wJsbP5qos Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 03:02:41 -0000 --e89a8f2347b54a00e904bfa5da3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > I agree with Richard & Roman. =E2=80=9CFull=E2=80=9D re-OFFER MUST suppo= rted required > for couple of mid session scenario like **** > > ** ** > > **1) **The session is established with audio and then video shall be > added in the middle in case complete offer is provided in re-OFFER. > You don't need a complete offer here, just a "full" offer for the video m= =3D section. This should already work today. > **** > > **2) ** It is possible to change the codec in the middle of the > Session as Roman mentioned. > This also doesn't require a complete offer. The application would need to remember what codecs are available so that it could change the offered codec to something other than what it is currently using, but it would not need to resend all codecs. I agree Roman's case of a B2BUA seems like it would need a full offer, although the idea of connecting an existing call to a new destination seems like an uncommon case; the application could simply start a new call (i.e. create a new PeerConnection), right? If we decide we need to support this, the simplest way of handling this would be to simply extend the |hints| parameter in createOffer to have some sort of "complete" flag. > **** > > ** ** > > ** ** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Roman Shpount > *Sent:* Tuesday, May 08, 2012 9:03 PM > *To:* Justin Uberti > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Question about JSEP createOffer**** > > ** ** > > > **** > > On Tue, May 8, 2012 at 10:46 AM, Justin Uberti wrote= : > **** > > Richard,**** > > ** ** > > That is an interesting point. Could you give a short example of when such > a "full" re-OFFER would be used? There are a few ways we could handle thi= s > case.**** > > ** ** > > > Actually I was the person who argued that "full" capabilities should be > present in original SIP O/A, when new offer is generated in an existing > session. The use case for this are B2BUA that connect an existing session > to a new call or another existing session. Typically, B2BUA would ask one > of the call parties for the offer (send an INVITE with no body in SIP), g= et > the new offer, and send this offer to the newly placed call. In order for > this to work, all the calling party capabilities should be listed in this > new offer, in particular all the codecs and all the communications types > (audio, video, text, etc), or call would not be successfully established. > _____________ > Roman Shpount**** > --e89a8f2347b54a00e904bfa5da3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, May 9, 2012 at 2:24 AM, Ravindra= n, Parthasarathi <pravindran@sonusnet.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I agree with Richard &= ; Roman. =E2=80=9CFull=E2=80=9D re-OFFER MUST supported required for couple= of mid session scenario like

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The session is estab= lished with audio and then video shall be added in the middle in case compl= ete offer is provided in re-OFFER.

You don't need a complete offer here, jus= t a "full" offer for the video m=3D section. This should already = work today.=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0It is possible= to change the codec in the middle of the Session as Roman mentioned.

This also doesn't require a complete offe= r. The application would need to remember what codecs are available so that= it could change the offered codec to something other than what it is curre= ntly using, but it would not need to resend all codecs.=C2=A0

I agree Roman's case of a B2BUA seems like it would= need a full offer, although the idea of connecting an existing call to a n= ew destination seems like an uncommon case; the application could simply st= art a new call (i.e. create a new PeerConnection), right?

If we decide we need to support this, the simplest way = of handling this would be to simply extend the |hints| parameter in createO= ffer to have some sort of "complete" flag.
=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Question about JSEP createOffer<= /span>

=C2=A0


On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

Richard,

=C2=A0

That is an interesting point. Could you give a short= example of when such a "full" re-OFFER would be used?=C2=A0There= are a few ways we could handle this case.

=C2=A0


Actually I was the person who argued that "full" capabilities sho= uld be present in original SIP O/A, when new offer is generated in an exist= ing session. The use case for this are B2BUA that connect an existing sessi= on to a new call or another existing session. Typically, B2BUA would ask one of the call parties for the offer (send an = INVITE with no body in SIP), get the new offer, and send this offer to the = newly placed call. In order for this to work, all the calling party capabil= ities should be listed in this new offer, in particular all the codecs and all the communications types (audi= o, video, text, etc), or call would not be successfully established.
_____________
Roman Shpount


--e89a8f2347b54a00e904bfa5da3b-- From glenzorn@gmail.com Wed May 9 22:43:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26121F8517 for ; Wed, 9 May 2012 22:43:00 -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 sTlVHKvAo4ge for ; Wed, 9 May 2012 22:43:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1851D21F8516 for ; Wed, 9 May 2012 22:43:00 -0700 (PDT) Received: by dacx6 with SMTP id x6so1303322dac.31 for ; Wed, 09 May 2012 22:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QFUTWJmkOmUL/Z0nxR9tre3hZa/5JeMOy/wWLNxDLbk=; b=abj29+bBSUwqxtUY+bZgmajwP5h5FVJv4Whlw0dOC5Qw4M/5H7ld2RRc8rCeQUGNZG TP0+tVmvUp3xPsLrTTtPb9A2bolaGsmU4+1Yr+asHgyj3ZYDpoZORfIMMYo6mpa742Kk j5tUchZE94mebhfq2hagng2tYVeFeXgJMr0TfJJ4qYtPzrChxJnzKO3qK616rGx2neWl t2HNKVKuROmCRWUjA0mlznixem/iEFXyEWGzvTs0paCRxixt92b2zVC9KSQt2GSB6fgm FD/1fA3AHvMKEvPZRwNlK3+KG/B2cnWYg+MsDqwuNnO/P/cQcdWcGT/H7mRMv0HY67/j 8FTg== Received: by 10.68.221.72 with SMTP id qc8mr6328852pbc.63.1336628579820; Wed, 09 May 2012 22:42:59 -0700 (PDT) Received: from [192.168.1.98] (ppp-58-11-240-243.revip2.asianet.co.th. [58.11.240.243]) by mx.google.com with ESMTPS id kb12sm8448609pbb.15.2012.05.09.22.42.57 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 22:42:59 -0700 (PDT) Message-ID: <4FAB5560.9090703@gmail.com> Date: Thu, 10 May 2012 12:42:56 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <1F2A2C70609D9E41844A2126145FC09804BCD25222@HKGMBOXPRD22.polycom.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2035816DE@szxeml525-mbs.china.huawei.com> <4FAB2F57.6080805@stpeter.im> In-Reply-To: <4FAB2F57.6080805@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mapping between SIP and ROAP/JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 05:43:00 -0000 On 05/10/2012 10:00 AM, Peter Saint-Andre wrote: > On 5/9/12 8:53 PM, Justin Uberti wrote: >> I would be willing to review a JSEP-XMPP draft. > Same here. Me, too. > > Peter > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Thu May 10 01:11:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC92B21F8607 for ; Thu, 10 May 2012 01:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 7bxf+BF6hwBy for ; Thu, 10 May 2012 01:11:07 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3538321F85D9 for ; Thu, 10 May 2012 01:11:04 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT6t4F8QurpxKGBlOfDj7LwHMIMoVNEBH@postini.com; Thu, 10 May 2012 01:11:04 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 10 May 2012 04:11:14 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 10 May 2012 13:40:58 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: [rtcweb] Question about JSEP createOffer Thread-Index: AQHNLSluoHgR0lZnOEGRK8sd9ExIfZa/qTgAgAFS2DCAAQAFAIAAsD9g Date: Thu, 10 May 2012 08:10:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16033CC2inbamail01sonus_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:11:09 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16033CC2inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KDQpUaGUgbmV3IG1lZGlhIHR5cGUvY29kZWMgY2hhbmdlIGJ5IHRoZSBhbnN3ZXJl ciByZXF1aXJlcyB0aGUgY29tcGxldGUgc2V0IG9mIGNvZGVjIGZyb20gb2ZmZXJlci4gSXQgaXMg bm90IGFwcHJvcHJpYXRlIHRvIHJlbWVtYmVyIHRoZSBwcmV2aW91c2x5IG9mZmVyZWQgY29kZWMg JiBjYXBhYmlsaXRpZXMgYXMgaXQgaXMgc3ViamVjdCB0byB2YXJ5IGluIHRoZSBtaWQtc2Vzc2lv bi4gRm9yIGV4YW1wbGUsIGl0IGlzIHBvc3NpYmxlIGZvciB0aGUgb2ZmZXJlciB0byByZW1vdmUg d2ViY2FtIGluIHRoZSBtaWRkbGUgb2YgdGhlIGF1ZGlvIHNlc3Npb24gd2hlcmVpbiBhbnN3ZXJl ciBzaG91bGQgbm90IGV4cGVjdCB0aGF0IHZpZGVvIGlzIHN1cHBvcnRlZCBieSBvZmZlcmVyIGFz IGl0IHdhcyBvZmZlcmVkIGluaXRpYWxseS4NCg0KUGxlYXNlIHJlYWQgaW5saW5lIGZvciBtb3Jl IGNvbW1lbnRzLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWls dG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIE1heSAxMCwgMjAxMiA4OjMy IEFNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogUm9tYW4gU2hwb3VudDsgcnRj d2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUXVlc3Rpb24gYWJvdXQgSlNFUCBj cmVhdGVPZmZlcg0KDQoNCk9uIFdlZCwgTWF5IDksIDIwMTIgYXQgMjoyNCBBTSwgUmF2aW5kcmFu LCBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbTxtYWlsdG86cHJhdmluZHJh bkBzb251c25ldC5jb20+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCBSaWNoYXJkICYgUm9tYW4uIOKA nEZ1bGzigJ0gcmUtT0ZGRVIgTVVTVCBzdXBwb3J0ZWQgcmVxdWlyZWQgZm9yIGNvdXBsZSBvZiBt aWQgc2Vzc2lvbiBzY2VuYXJpbyBsaWtlDQoNCg0KMSkgICAgICBUaGUgc2Vzc2lvbiBpcyBlc3Rh Ymxpc2hlZCB3aXRoIGF1ZGlvIGFuZCB0aGVuIHZpZGVvIHNoYWxsIGJlIGFkZGVkIGluIHRoZSBt aWRkbGUgaW4gY2FzZSBjb21wbGV0ZSBvZmZlciBpcyBwcm92aWRlZCBpbiByZS1PRkZFUi4NCllv dSBkb24ndCBuZWVkIGEgY29tcGxldGUgb2ZmZXIgaGVyZSwganVzdCBhICJmdWxsIiBvZmZlciBm b3IgdGhlIHZpZGVvIG09IHNlY3Rpb24uIFRoaXMgc2hvdWxkIGFscmVhZHkgd29yayB0b2RheS4N CjxwYXJ0aGE+ICBJSVVDIGZvciBhdWRpbyBzZXNzaW9uLCBlYWNoIHRpbWUgcmUtb2ZmZXIgTVVT VCBjb250YWluIOKAnGZ1bGzigJ0gb2ZmZXIgZm9yIHZpZGVvIHNlY3Rpb24gPC9wYXJ0aGE+DQoN CjIpICAgICAgIEl0IGlzIHBvc3NpYmxlIHRvIGNoYW5nZSB0aGUgY29kZWMgaW4gdGhlIG1pZGRs ZSBvZiB0aGUgU2Vzc2lvbiBhcyBSb21hbiBtZW50aW9uZWQuDQpUaGlzIGFsc28gZG9lc24ndCBy ZXF1aXJlIGEgY29tcGxldGUgb2ZmZXIuIFRoZSBhcHBsaWNhdGlvbiB3b3VsZCBuZWVkIHRvIHJl bWVtYmVyIHdoYXQgY29kZWNzIGFyZSBhdmFpbGFibGUgc28gdGhhdCBpdCBjb3VsZCBjaGFuZ2Ug dGhlIG9mZmVyZWQgY29kZWMgdG8gc29tZXRoaW5nIG90aGVyIHRoYW4gd2hhdCBpdCBpcyBjdXJy ZW50bHkgdXNpbmcsIGJ1dCBpdCB3b3VsZCBub3QgbmVlZCB0byByZXNlbmQgYWxsIGNvZGVjcy4N CjxwYXJ0aGE+IFlvdXIgcHJvcG9zYWwgaXMgbGltaXRpbmcgYXMgdGhlIGFuc3dlcmVyIGhhcyBu byBjaG9pY2UgdG8gdGhlIHNlbGVjdCB0aGUgcHJlZmVycmVkIGNvZGVjIDwvcGFydGhhPg0KDQpJ IGFncmVlIFJvbWFuJ3MgY2FzZSBvZiBhIEIyQlVBIHNlZW1zIGxpa2UgaXQgd291bGQgbmVlZCBh IGZ1bGwgb2ZmZXIsIGFsdGhvdWdoIHRoZSBpZGVhIG9mIGNvbm5lY3RpbmcgYW4gZXhpc3Rpbmcg Y2FsbCB0byBhIG5ldyBkZXN0aW5hdGlvbiBzZWVtcyBsaWtlIGFuIHVuY29tbW9uIGNhc2U7IHRo ZSBhcHBsaWNhdGlvbiBjb3VsZCBzaW1wbHkgc3RhcnQgYSBuZXcgY2FsbCAoaS5lLiBjcmVhdGUg YSBuZXcgUGVlckNvbm5lY3Rpb24pLCByaWdodD8NCg0KSWYgd2UgZGVjaWRlIHdlIG5lZWQgdG8g c3VwcG9ydCB0aGlzLCB0aGUgc2ltcGxlc3Qgd2F5IG9mIGhhbmRsaW5nIHRoaXMgd291bGQgYmUg dG8gc2ltcGx5IGV4dGVuZCB0aGUgfGhpbnRzfCBwYXJhbWV0ZXIgaW4gY3JlYXRlT2ZmZXIgdG8g aGF2ZSBzb21lIHNvcnQgb2YgImNvbXBsZXRlIiBmbGFnLg0KPHBhcnRoYT4geW91ciBBUEkgcHJv cG9zYWwgbG9va3MgZ29vZCAgYXMgaXQgaXMgcG9zc2libGUgdG8gcmUtdXNlIHRoZSBleGlzdGlu ZyBvciBvZmZlciBmdWxsIGJhc2VkIG9uIHRoZSBhcHBsaWNhdGlvbiBuZWVkcy4gQnV0IHRoZSBh cHBsaWNhdGlvbiBkZXZlbG9wZXIgIE1VU1QgYXdhcmUgb2YgdGhlIGltcGxpY2F0aW9uIGFzIGl0 IGNhbGxzIGZvciBpbnRlcm9wIGlzc3VlIGluIGNhc2Ugb2YgZmVkZXJhdGlvbiBzY2VuYXJpbyBp ZiB0aGUgZnVsbCBvZmZlciBpcyBub3Qgc2VudCBhY3Jvc3MuIDwvcGFydGhhPg0KDQoNCg0KDQpG cm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IFR1ZXNkYXksIE1h eSAwOCwgMjAxMiA5OjAzIFBNDQpUbzogSnVzdGluIFViZXJ0aQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFF1ZXN0aW9u IGFib3V0IEpTRVAgY3JlYXRlT2ZmZXINCg0KDQpPbiBUdWUsIE1heSA4LCAyMDEyIGF0IDEwOjQ2 IEFNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbT4+IHdyb3RlOg0KUmljaGFyZCwNCg0KVGhhdCBpcyBhbiBpbnRlcmVzdGluZyBwb2lu dC4gQ291bGQgeW91IGdpdmUgYSBzaG9ydCBleGFtcGxlIG9mIHdoZW4gc3VjaCBhICJmdWxsIiBy ZS1PRkZFUiB3b3VsZCBiZSB1c2VkPyBUaGVyZSBhcmUgYSBmZXcgd2F5cyB3ZSBjb3VsZCBoYW5k bGUgdGhpcyBjYXNlLg0KDQoNCkFjdHVhbGx5IEkgd2FzIHRoZSBwZXJzb24gd2hvIGFyZ3VlZCB0 aGF0ICJmdWxsIiBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIHByZXNlbnQgaW4gb3JpZ2luYWwgU0lQ IE8vQSwgd2hlbiBuZXcgb2ZmZXIgaXMgZ2VuZXJhdGVkIGluIGFuIGV4aXN0aW5nIHNlc3Npb24u IFRoZSB1c2UgY2FzZSBmb3IgdGhpcyBhcmUgQjJCVUEgdGhhdCBjb25uZWN0IGFuIGV4aXN0aW5n IHNlc3Npb24gdG8gYSBuZXcgY2FsbCBvciBhbm90aGVyIGV4aXN0aW5nIHNlc3Npb24uIFR5cGlj YWxseSwgQjJCVUEgd291bGQgYXNrIG9uZSBvZiB0aGUgY2FsbCBwYXJ0aWVzIGZvciB0aGUgb2Zm ZXIgKHNlbmQgYW4gSU5WSVRFIHdpdGggbm8gYm9keSBpbiBTSVApLCBnZXQgdGhlIG5ldyBvZmZl ciwgYW5kIHNlbmQgdGhpcyBvZmZlciB0byB0aGUgbmV3bHkgcGxhY2VkIGNhbGwuIEluIG9yZGVy IGZvciB0aGlzIHRvIHdvcmssIGFsbCB0aGUgY2FsbGluZyBwYXJ0eSBjYXBhYmlsaXRpZXMgc2hv dWxkIGJlIGxpc3RlZCBpbiB0aGlzIG5ldyBvZmZlciwgaW4gcGFydGljdWxhciBhbGwgdGhlIGNv ZGVjcyBhbmQgYWxsIHRoZSBjb21tdW5pY2F0aW9ucyB0eXBlcyAoYXVkaW8sIHZpZGVvLCB0ZXh0 LCBldGMpLCBvciBjYWxsIHdvdWxkIG5vdCBiZSBzdWNjZXNzZnVsbHkgZXN0YWJsaXNoZWQuDQpf X19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C16033CC2inbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3Rpbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSBuZXcgbWVkaWEgdHlwZS9jb2RlYyBjaGFuZ2UgYnkgdGhlIGFuc3dlcmVyIHJlcXVpcmVz IHRoZSBjb21wbGV0ZSBzZXQgb2YgY29kZWMgZnJvbSBvZmZlcmVyLiBJdCBpcyBub3QgYXBwcm9w cmlhdGUgdG8gcmVtZW1iZXIgdGhlIHByZXZpb3VzbHkgb2ZmZXJlZCBjb2RlYw0KICZhbXA7IGNh cGFiaWxpdGllcyBhcyBpdCBpcyBzdWJqZWN0IHRvIHZhcnkgaW4gdGhlIG1pZC1zZXNzaW9uLiBG b3IgZXhhbXBsZSwgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBvZmZlcmVyIHRvIHJlbW92ZSB3ZWJj YW0gaW4gdGhlIG1pZGRsZSBvZiB0aGUgYXVkaW8gc2Vzc2lvbiB3aGVyZWluIGFuc3dlcmVyIHNo b3VsZCBub3QgZXhwZWN0IHRoYXQgdmlkZW8gaXMgc3VwcG9ydGVkIGJ5IG9mZmVyZXIgYXMgaXQg d2FzIG9mZmVyZWQgaW5pdGlhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHJlYWQgaW5saW5lIGZvciBt b3JlIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlBhcnRoYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBK dXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBNYXkgMTAsIDIwMTIgODozMiBBTTxicj4NCjxiPlRvOjwvYj4gUmF2aW5k cmFuLCBQYXJ0aGFzYXJhdGhpPGJyPg0KPGI+Q2M6PC9iPiBSb21hbiBTaHBvdW50OyBydGN3ZWJA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFF1ZXN0aW9uIGFib3V0 IEpTRVAgY3JlYXRlT2ZmZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDksIDIwMTIgYXQgMjoy NCBBTSwgUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmlu ZHJhbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2aW5kcmFuQHNvbnVzbmV0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGFncmVlIHdpdGggUmljaGFyZCAmYW1wOyBSb21hbi4g4oCcRnVsbOKAnSByZS1PRkZFUiBNVVNU IHN1cHBvcnRlZCByZXF1aXJlZCBmb3IgY291cGxlIG9mIG1pZCBzZXNzaW9uIHNjZW5hcmlvDQog bGlrZSA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNlc3Npb24gaXMgZXN0YWJsaXNoZWQgd2l0aCBhdWRp byBhbmQgdGhlbiB2aWRlbyBzaGFsbCBiZSBhZGRlZCBpbiB0aGUgbWlkZGxlIGluIGNhc2UgY29t cGxldGUgb2ZmZXIgaXMgcHJvdmlkZWQgaW4gcmUtT0ZGRVIuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgZG9uJ3Qg bmVlZCBhIGNvbXBsZXRlIG9mZmVyIGhlcmUsIGp1c3QgYSAmcXVvdDtmdWxsJnF1b3Q7IG9mZmVy IGZvciB0aGUgdmlkZW8gbT0gc2VjdGlvbi4gVGhpcyBzaG91bGQgYWxyZWFkeSB3b3JrIHRvZGF5 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtwYXJ0aGEmZ3Q7Jm5ic3A7IElJVUMg Zm9yIGF1ZGlvIHNlc3Npb24sIGVhY2ggdGltZSByZS1vZmZlciBNVVNUIGNvbnRhaW4g4oCcZnVs bOKAnSBvZmZlciBmb3IgdmlkZW8gc2VjdGlvbiAmbHQ7L3BhcnRoYSZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yKTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDtJdCBpcyBwb3NzaWJsZSB0byBjaGFuZ2UgdGhlIGNvZGVjIGluIHRoZSBtaWRkbGUgb2Yg dGhlIFNlc3Npb24gYXMgUm9tYW4gbWVudGlvbmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBhbHNvIGRvZXNuJ3QgcmVxdWlyZSBhIGNvbXBsZXRlIG9mZmVyLiBUaGUgYXBwbGljYXRp b24gd291bGQgbmVlZCB0byByZW1lbWJlciB3aGF0IGNvZGVjcyBhcmUgYXZhaWxhYmxlIHNvIHRo YXQgaXQgY291bGQgY2hhbmdlIHRoZSBvZmZlcmVkIGNvZGVjIHRvIHNvbWV0aGluZyBvdGhlciB0 aGFuIHdoYXQgaXQgaXMgY3VycmVudGx5IHVzaW5nLCBidXQgaXQgd291bGQgbm90IG5lZWQgdG8g cmVzZW5kIGFsbA0KIGNvZGVjcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7cGFy dGhhJmd0OyBZb3VyIHByb3Bvc2FsIGlzIGxpbWl0aW5nIGFzIHRoZSBhbnN3ZXJlciBoYXMgbm8g Y2hvaWNlIHRvIHRoZSBzZWxlY3QgdGhlIHByZWZlcnJlZCBjb2RlYyAmbHQ7L3BhcnRoYSZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYWdyZWUgUm9tYW4ncyBjYXNlIG9mIGEgQjJCVUEgc2VlbXMgbGlrZSBpdCB3b3VsZCBu ZWVkIGEgZnVsbCBvZmZlciwgYWx0aG91Z2ggdGhlIGlkZWEgb2YgY29ubmVjdGluZyBhbiBleGlz dGluZyBjYWxsIHRvIGEgbmV3IGRlc3RpbmF0aW9uIHNlZW1zIGxpa2UgYW4gdW5jb21tb24gY2Fz ZTsgdGhlIGFwcGxpY2F0aW9uIGNvdWxkIHNpbXBseSBzdGFydCBhIG5ldyBjYWxsIChpLmUuIGNy ZWF0ZSBhIG5ldyBQZWVyQ29ubmVjdGlvbiksDQogcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGRlY2lkZSB3ZSBuZWVkIHRv IHN1cHBvcnQgdGhpcywgdGhlIHNpbXBsZXN0IHdheSBvZiBoYW5kbGluZyB0aGlzIHdvdWxkIGJl IHRvIHNpbXBseSBleHRlbmQgdGhlIHxoaW50c3wgcGFyYW1ldGVyIGluIGNyZWF0ZU9mZmVyIHRv IGhhdmUgc29tZSBzb3J0IG9mICZxdW90O2NvbXBsZXRlJnF1b3Q7IGZsYWcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jmx0O3BhcnRoYSZndDsgeW91ciBBUEkgcHJvcG9zYWwgbG9va3MgZ29vZCZu YnNwOyBhcyBpdCBpcyBwb3NzaWJsZSB0byByZS11c2UgdGhlIGV4aXN0aW5nIG9yIG9mZmVyIGZ1 bGwgYmFzZWQgb24gdGhlIGFwcGxpY2F0aW9uIG5lZWRzLiBCdXQgdGhlIGFwcGxpY2F0aW9uIGRl dmVsb3BlciZuYnNwOw0KIE1VU1QgYXdhcmUgb2YgdGhlIGltcGxpY2F0aW9uIGFzIGl0IGNhbGxz IGZvciBpbnRlcm9wIGlzc3VlIGluIGNhc2Ugb2YgZmVkZXJhdGlvbiBzY2VuYXJpbyBpZiB0aGUg ZnVsbCBvZmZlciBpcyBub3Qgc2VudCBhY3Jvc3MuICZsdDsvcGFydGhhJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjI1aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBNYXkgMDgsIDIwMTIgOTowMyBQTTxicj4NCjxiPlRvOjwvYj4gSnVz dGluIFViZXJ0aTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtydGN3ZWJdIFF1ZXN0aW9uIGFib3V0IEpTRVAgY3JlYXRlT2ZmZXI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFR1ZSwgTWF5IDgsIDIwMTIgYXQgMTA6NDYgQU0sIEp1c3RpbiBVYmVydGkgJmx0 OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJl cnRpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UmljaGFyZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGF0IGlzIGFuIGludGVyZXN0aW5nIHBvaW50LiBDb3VsZCB5b3UgZ2l2 ZSBhIHNob3J0IGV4YW1wbGUgb2Ygd2hlbiBzdWNoIGEgJnF1b3Q7ZnVsbCZxdW90OyByZS1PRkZF UiB3b3VsZCBiZSB1c2VkPyZuYnNwO1RoZXJlIGFyZSBhIGZldyB3YXlzIHdlIGNvdWxkIGhhbmRs ZSB0aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KQWN0dWFsbHkgSSB3YXMgdGhlIHBlcnNvbiB3aG8gYXJndWVkIHRoYXQg JnF1b3Q7ZnVsbCZxdW90OyBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIHByZXNlbnQgaW4gb3JpZ2lu YWwgU0lQIE8vQSwgd2hlbiBuZXcgb2ZmZXIgaXMgZ2VuZXJhdGVkIGluIGFuIGV4aXN0aW5nIHNl c3Npb24uIFRoZSB1c2UgY2FzZSBmb3IgdGhpcyBhcmUgQjJCVUEgdGhhdCBjb25uZWN0IGFuIGV4 aXN0aW5nIHNlc3Npb24gdG8gYSBuZXcgY2FsbCBvciBhbm90aGVyIGV4aXN0aW5nIHNlc3Npb24u DQogVHlwaWNhbGx5LCBCMkJVQSB3b3VsZCBhc2sgb25lIG9mIHRoZSBjYWxsIHBhcnRpZXMgZm9y IHRoZSBvZmZlciAoc2VuZCBhbiBJTlZJVEUgd2l0aCBubyBib2R5IGluIFNJUCksIGdldCB0aGUg bmV3IG9mZmVyLCBhbmQgc2VuZCB0aGlzIG9mZmVyIHRvIHRoZSBuZXdseSBwbGFjZWQgY2FsbC4g SW4gb3JkZXIgZm9yIHRoaXMgdG8gd29yaywgYWxsIHRoZSBjYWxsaW5nIHBhcnR5IGNhcGFiaWxp dGllcyBzaG91bGQgYmUgbGlzdGVkIGluIHRoaXMgbmV3DQogb2ZmZXIsIGluIHBhcnRpY3VsYXIg YWxsIHRoZSBjb2RlY3MgYW5kIGFsbCB0aGUgY29tbXVuaWNhdGlvbnMgdHlwZXMgKGF1ZGlvLCB2 aWRlbywgdGV4dCwgZXRjKSwgb3IgY2FsbCB3b3VsZCBub3QgYmUgc3VjY2Vzc2Z1bGx5IGVzdGFi bGlzaGVkLjxicj4NCl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C16033CC2inbamail01sonus_-- From juberti@google.com Thu May 10 06:48:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A371721F864B for ; Thu, 10 May 2012 06:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMRErnerBVWL for ; Thu, 10 May 2012 06:48:58 -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 652B121F8629 for ; Thu, 10 May 2012 06:48:58 -0700 (PDT) Received: by qadz3 with SMTP id z3so361154qad.10 for ; Thu, 10 May 2012 06:48:58 -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:x-system-of-record; bh=ZlERH/3JVzl4gkX7ZMqxcfYWYVnxrs76vzH82NgXObc=; b=QzfuEyE7Joj40BNRtZQVFMTnP1sHH1cxUEodI611FbxAFOPZmdvl1ULU3w2jTeI1Jd rcNMFsalZPssAZoMZ6qZ4w+dcF/6Va9QJ8r/F9tQNPpYoY2YdKp+tB39RmYW+Hcya+JT HL0awnL4szr/mWD9dyUmlxq5cwm8GVa4NhiK5cfQHhTlgQzr92IM4D4vCKcZ7tM88Par 65nXChjYXpTRn2fIfB4IinWVPgOTPxigLVOBWH+srqzqWpvMWlWaN371WJOL+YSwIoty a0vmByJkiTBqR12YWoUXtT8SDGFBIITr/6ewXdxprPg/Ys44ADf1oQhZcchrrfIcvPAZ amWQ== 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-system-of-record:x-gm-message-state; bh=ZlERH/3JVzl4gkX7ZMqxcfYWYVnxrs76vzH82NgXObc=; b=Vg545T8ITS1QCGWFPyeSTpwn/WKku/AwxVfpB4hN9VtrK927zaylNkG8ZxXRWG6DdG of3nruvFH5xKtHiNhpElfwNNThC24qImhzfoNxaogExPrcwbway1Ut6ATJKqzOqioos+ VEhNuATuiaIyDuH4WP1Qz4Ahb3C4u8oAUu/YIGjDid64ZGuIT8j1rHQsiBTaXhBQ84uF 1zIyA3EvR61kVp0WUeQwU+EHxQkwR9h9C3639mtPCE30Nt8wb/fXrQEMHoAF4f+mMWMR Rb1Qwun47t3VhOmvNbdDSYFbSwCnZcpaobZdRo5ws8nsKCQUMbpdxg2maG67BMcnDtIl fhhQ== Received: by 10.224.215.135 with SMTP id he7mr11763969qab.48.1336657737789; Thu, 10 May 2012 06:48:57 -0700 (PDT) Received: by 10.224.215.135 with SMTP id he7mr11763930qab.48.1336657737484; Thu, 10 May 2012 06:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Thu, 10 May 2012 06:48:37 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@inba-mail01.sonusnet.com> References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@inba-mail01.sonusnet.com> From: Justin Uberti Date: Thu, 10 May 2012 09:48:37 -0400 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=20cf300513f6a10a7104bfaee1c5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmTdzpi4Jq/k9a9YpGwRSh/OXqIHL+0VrnBK6iJ/T43igRYbo04mzwWGjiwFKZj5Oj5MukNbk+xjTlm444mTRJ+5TneUO2DAdCTHZVukOsYWtRnhbjo2JGx5inR9MyADSSaUNQu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 13:48:59 -0000 --20cf300513f6a10a7104bfaee1c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 10, 2012 at 4:10 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Justin,**** > > ** ** > > The new media type/codec change by the answerer requires the complete set > of codec from offerer. It is not appropriate to remember the previously > offered codec & capabilities as it is subject to vary in the mid-session. > For example, it is possible for the offerer to remove webcam in the middl= e > of the audio session wherein answerer should not expect that video is > supported by offerer as it was offered initially.**** > > ** ** > > Please read inline for more comments.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Thursday, May 10, 2012 8:32 AM > *To:* Ravindran, Parthasarathi > *Cc:* Roman Shpount; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Question about JSEP createOffer**** > > ** ** > > ** ** > > On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > I agree with Richard & Roman. =E2=80=9CFull=E2=80=9D re-OFFER MUST suppor= ted required for > couple of mid session scenario like **** > > **** > > 1) The session is established with audio and then video shall be > added in the middle in case complete offer is provided in re-OFFER.**** > > You don't need a complete offer here, just a "full" offer for the video m= =3D > section. This should already work today. **** > > IIUC for audio session, each time re-offer MUST contain =E2=80= =9Cfull=E2=80=9D > offer for video section > If you have an audio session, and you add video, the offer to add video will include a "full" offer for video. But changes just to the audio session itself will obviously not include anything about video. Maybe I don't understand what you are suggesting. > **** > > 2) It is possible to change the codec in the middle of the Session > as Roman mentioned.**** > > This also doesn't require a complete offer. The application would need > to remember what codecs are available so that it could change the offered > codec to something other than what it is currently using, but it would no= t > need to resend all codecs. **** > > Your proposal is limiting as the answerer has no choice to the > select the preferred codec > I thought the offerer wanted to change the codec. Why would the answerer need to make a selection? If the 'answerer' wants to use a different codec, it should make an offer of its own. **** > > ** ** > > I agree Roman's case of a B2BUA seems like it would need a full offer, > although the idea of connecting an existing call to a new destination see= ms > like an uncommon case; the application could simply start a new call (i.e= . > create a new PeerConnection), right?**** > > ** ** > > If we decide we need to support this, the simplest way of handling this > would be to simply extend the |hints| parameter in createOffer to have so= me > sort of "complete" flag.**** > > your API proposal looks good as it is possible to re-use the > existing or offer full based on the application needs. But the applicatio= n > developer MUST aware of the implication as it calls for interop issue in > case of federation scenario if the full offer is not sent across. > The application developer only needs to do this if supporting these edge cases is relevant to their application. > **** > > **** > > **** > > **** > > **** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Roman Shpount > *Sent:* Tuesday, May 08, 2012 9:03 PM > *To:* Justin Uberti > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Question about JSEP createOffer**** > > **** > > > **** > > On Tue, May 8, 2012 at 10:46 AM, Justin Uberti wrote= : > **** > > Richard,**** > > **** > > That is an interesting point. Could you give a short example of when such > a "full" re-OFFER would be used? There are a few ways we could handle thi= s > case.**** > > **** > > > Actually I was the person who argued that "full" capabilities should be > present in original SIP O/A, when new offer is generated in an existing > session. The use case for this are B2BUA that connect an existing session > to a new call or another existing session. Typically, B2BUA would ask one > of the call parties for the offer (send an INVITE with no body in SIP), g= et > the new offer, and send this offer to the newly placed call. In order for > this to work, all the calling party capabilities should be listed in this > new offer, in particular all the codecs and all the communications types > (audio, video, text, etc), or call would not be successfully established. > _____________ > Roman Shpount**** > > ** ** > --20cf300513f6a10a7104bfaee1c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, May 10, 2012 at 4:10 AM, Ravindr= an, Parthasarathi <pravindran@sonusnet.com> wrote:
=

Justin,

=C2=A0

The new media type/codec = change by the answerer requires the complete set of codec from offerer. It = is not appropriate to remember the previously offered codec & capabilities as it is subject to vary in the mid-session. For exampl= e, it is possible for the offerer to remove webcam in the middle of the aud= io session wherein answerer should not expect that video is supported by of= ferer as it was offered initially.

=C2=A0

Please read inline for mo= re comments.

=C2=A0

Thanks

Partha

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Thursday, May 10, 2012 8:32 AM
To: Ravindran, Parthasarathi
Cc: Roman Shpount; rtcweb@ietf.org


Subject: Re: [rtcweb] Question about JSEP createOffer<= /div>

=C2=A0

=C2=A0<= /p>

On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasar= athi <pravi= ndran@sonusnet.com> wrote:

I agree with Richard &= ; Roman. =E2=80=9CFull=E2=80=9D re-OFFER MUST supported required for couple= of mid session scenario like

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The session is established with audio and= then video shall be added in the middle in case complete offer is provided= in re-OFFER.

You don't need a complete offer here, just a &qu= ot;full" offer for the video m=3D section. This should already work to= day.=C2=A0

<partha>=C2= =A0 IIUC for audio session, each time re-offer MUST contain =E2=80=9Cfull= =E2=80=9D offer for video section </partha>


If you have = an audio session, and you add video, the offer to add video will include a = "full" offer for video. But changes just to the audio session its= elf will obviously not include anything about video. Maybe I don't unde= rstand what you are suggesting.

<= /span>

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0It is possible to change the codec = in the middle of the Session as Roman mentioned.

This also doesn't require a complete offer. The = application would need to remember what codecs are available so that it cou= ld change the offered codec to something other than what it is currently us= ing, but it would not need to resend all codecs.=C2=A0

<partha> Your= proposal is limiting as the answerer has no choice to the select the prefe= rred codec </partha>


I thought th= e offerer wanted to change the codec. Why would the answerer need to make a= selection? If the 'answerer' wants to use a different codec, it sh= ould make an offer of its own.

<= /span>

=C2=A0

I agree Roman's case of a B2BUA seems like it wo= uld need a full offer, although the idea of connecting an existing call to = a new destination seems like an uncommon case; the application could simply= start a new call (i.e. create a new PeerConnection), right?

=C2=A0

If we decide we need to support this, the simplest w= ay of handling this would be to simply extend the |hints| parameter in crea= teOffer to have some sort of "complete" flag.

<partha> your= API proposal looks good=C2=A0 as it is possible to re-use the existing or = offer full based on the application needs. But the application developer=C2= =A0 MUST aware of the implication as it calls for interop issue in case of fed= eration scenario if the full offer is not sent across. </partha>


The ap= plication developer only needs to do this if supporting these edge cases is= relevant to their application.

<= /span>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Question about JSEP createOffer<= u>

=C2=A0


On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:

Richard,

=C2=A0

That is an interesting point. Could you give a short= example of when such a "full" re-OFFER would be used?=C2=A0There= are a few ways we could handle this case.

=C2=A0


Actually I was the person who argued that "full" capabilities sho= uld be present in original SIP O/A, when new offer is generated in an exist= ing session. The use case for this are B2BUA that connect an existing sessi= on to a new call or another existing session. Typically, B2BUA would ask one of the call parties for the offer (send an = INVITE with no body in SIP), get the new offer, and send this offer to the = newly placed call. In order for this to work, all the calling party capabil= ities should be listed in this new offer, in particular all the codecs and all the communications types (audi= o, video, text, etc), or call would not be successfully established.
_____________
Roman Shpount

=C2=A0


--20cf300513f6a10a7104bfaee1c5-- From fluffy@iii.ca Thu May 10 07:13:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63AF21F865A for ; Thu, 10 May 2012 07:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 tgQ5kqoW0esP for ; Thu, 10 May 2012 07:13:46 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA021F864C for ; Thu, 10 May 2012 07:13:46 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45A8922E259; Thu, 10 May 2012 10:13:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 08:13:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericss on.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:13:47 -0000 On May 3, 2012, at 2:34 PM, Roman Shpount wrote: > On Thu, May 3, 2012 at 4:29 PM, Christer Holmberg = wrote: > You could also choose not to alert the remote user until the ICE = procedures have finished - more or less using ICE with preconditions. >=20 > Of course, that is going to trigger actions in STUN/TURN servers, even = if the called party won't accept the call, but at least from a user = experience perspective that is still better than lifting the hook, and = having to wait for whatever-time-it-takes-for-ICE-to-finish seconds = before one can start to talk. >=20 >=20 > This also has a downside of disclosing user's IP to the caller without = the user confirmation. For a lot of applications this can be serious = security flaw.=20 > _____________ The initial media flow could be forced to provide only relay ICE = candidates to help mitigate this. (I think we decided awhile back that = was one of the things we would provide support for in the API). Later = with the user answers or consents in same way, the ICE can move the = media to a non relay flow.=20 From roman@telurix.com Thu May 10 09:40:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F8321F8645 for ; Thu, 10 May 2012 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, 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 hLycdC2xEN7t for ; Thu, 10 May 2012 09:40:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03F0B21F84FD for ; Thu, 10 May 2012 09:40:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2232149pbc.31 for ; Thu, 10 May 2012 09:40: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=XYBUQix3eYI5pz4IVUCdgUWaZyr8Y/NHF8kSAkQBaD0=; b=a8EssEJ++iv84XE4LfKKyWquIC2sYAcO2tqnMOhgWFi492HQ3QIIIHHzBukvrKY7V0 y5gbLzsGKcxWv9OK/Sg0PfIDJYvLs5wAYfEx1/EdcQb/l3Lz4cDX3v+6bNowfkjqA3LM 2fc5UnP/zwezk+8bSR+59zdXtjSg1L5pXjtYk6bufeC1D5Rmpld/fiFLMYxDlcuad+pE akrKYZzpK9Fypu/7y3QZIKEvnCZKme7n2QweguxAzQO8ICsO3KZt4Z4i9Qu5wk4BgNWt PlEUgtxXW/BVJF42UhiXMX+pdNORRFotp14C+3QyDKco3HqcUahlVIKHWc8/f1/vlpKs WN8w== Received: by 10.68.132.103 with SMTP id ot7mr1100995pbb.59.1336668026608; Thu, 10 May 2012 09:40:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id rj4sm9978172pbc.30.2012.05.10.09.40.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 09:40:23 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2232054pbc.31 for ; Thu, 10 May 2012 09:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.233.102 with SMTP id tv6mr21611526pbc.153.1336668022066; Thu, 10 May 2012 09:40:22 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Thu, 10 May 2012 09:40:21 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 10 May 2012 12:40:21 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b33d550a34e5b04bfb146c5 X-Gm-Message-State: ALoCoQl4kp8c+6QIJ+++xa/aAu2RYXLQAuxobOJSZN//5WHz7uheS9/IbWAWxPDUkDzfYQ3h3rsh Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:40:28 -0000 --047d7b33d550a34e5b04bfb146c5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 10:13 AM, Cullen Jennings wrote: > > On May 3, 2012, at 2:34 PM, Roman Shpount wrote: > > > On Thu, May 3, 2012 at 4:29 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > You could also choose not to alert the remote user until the ICE > procedures have finished - more or less using ICE with preconditions. > > > > Of course, that is going to trigger actions in STUN/TURN servers, even > if the called party won't accept the call, but at least from a user > experience perspective that is still better than lifting the hook, and > having to wait for whatever-time-it-takes-for-ICE-to-finish seconds before > one can start to talk. > > > > > > This also has a downside of disclosing user's IP to the caller without > the user confirmation. For a lot of applications this can be serious > security flaw. > > _____________ > > The initial media flow could be forced to provide only relay ICE > candidates to help mitigate this. (I think we decided awhile back that was > one of the things we would provide support for in the API). Later with the > user answers or consents in same way, the ICE can move the media to a non > relay flow. > > Just to make this clear, in this scenario, once application receives the offer, it will generate a provisional answer with only relay candidates, send this answer to the calling party, completes the ICE process on the called party side, and then alert the called party. Once called user accepts the call, application will send the final answer with relay, reflexive and local candidates. This can also be implemented with final answer with only relay candidates by the called party before user accepts the the call, and O/A in the opposite direction once the call is accepted. There is still a slight chance of clipping the media from the calling party towards the called party since the answer might not arrive to the calling party or ICE process from the calling party to the called party might not complete before the called party answers. To avoid this, application will need to send a separate message via signaling or data channel once the ICE process on the calling side completes and only alert the called party once this signaling message is received. What it boils down to is that application should setup the media channel (provide relay candidates only from the called side, if IP privacy is a concern), send a separate signaling message when it is done, and then alert the user. This will significantly slow down the actual call setup and will use a bunch of extra resources, but will solve the clipping problem. _____________ Roman Shpount --047d7b33d550a34e5b04bfb146c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 10:13 AM, Cullen Jen= nings <fluffy@iii.ca> wrote:

On May 3, 2012, at 2:34 PM, Roman Shpount wrote:

> On Thu, May 3, 2012 at 4:29 PM, Christer Holmberg <christer.holmberg@ericsson.com> wr= ote:
> You could also choose not to alert the remote user until the ICE proce= dures have finished - more or less using ICE with preconditions.
>
> Of course, that is going to trigger actions in STUN/TURN servers, even= if the called party won't accept the call, but at least from a user ex= perience perspective that is still better than lifting the hook, and having= to wait for whatever-time-it-takes-for-ICE-to-finish seconds before one ca= n start to talk.
>
>
> This also has a downside of disclosing user's IP to the caller wit= hout the user confirmation. For a lot of applications this can be serious s= ecurity flaw.
> _____________

The initial media flow could be forced to provide only relay IC= E candidates to help mitigate this. (I think we decided awhile back that wa= s one of the things we would provide support for in the API). Later with th= e user answers or consents in same way, the ICE can move the media to a non= relay flow.

Just to make this clear, in this scenario, once appli= cation receives the offer, it will generate a provisional answer with only = relay candidates, send this answer to the calling party, completes the ICE = process on the called party side, and then alert the called party. Once cal= led user accepts the call, application will send the final answer with rela= y, reflexive and local candidates. This can also be implemented with final = answer with only relay candidates by the called party before user accepts t= he the call, and O/A in the opposite direction once the call is accepted. T= here is still a slight chance of clipping the media from the calling party = towards the called party since the answer might not arrive to the calling p= arty or ICE process from the calling party to the called party might not co= mplete before the called party answers. To avoid this, application will nee= d to send a separate message via signaling or data channel once the ICE pro= cess on the calling side completes and only alert the called party once thi= s signaling message is received. What it boils down to is that application = should setup the media channel (provide relay candidates only from the call= ed side, if IP privacy is a concern), send a separate signaling message whe= n it is done, and then alert the user. This will significantly slow down th= e actual call setup and will use a bunch of extra resources, but will solve= the clipping problem.
_____________
Roman Shpount
=A0

--047d7b33d550a34e5b04bfb146c5-- From roman@telurix.com Thu May 10 09:54:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6785321F8709 for ; Thu, 10 May 2012 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, 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 CL7W2cIuNWmm for ; Thu, 10 May 2012 09:54:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B125F21F8512 for ; Thu, 10 May 2012 09:54:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so2068240yhq.31 for ; Thu, 10 May 2012 09:54: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=FvSa+QYF60dAokD2kXwGtJkeSEU/m9oaJQjTAOoJbq0=; b=o0Igq6pPndLTysj0weLRsvixwGDkHb/7OYpX3uEBTFfVTrTFdv3YeqlYc4433Xl4wk dQXnH8M3EjTSqHhiZIAVXDANvL3QCF+Nif6N0qvzz/renWkGSanle/qQ1ArD3DcDsC2Z L1HX+ItTZdHGvcfu+10PpJVf/wMThWEQ0eG91RuvYJGl+jkBW8CSnuj7l4TDWWPAzMNF 0cXy1EHn+LmnBddAQUfs0p1tYOOJl/a/04HmuGAvRqrklcUJuvAXgqQpLDgy8+qLP1pj 36/sLsqQKNRk0Vt06njuEBkn+Kc2QJTis8zAAlFYqANiriFnEXT+7PNNvYWCbtcVlYpv +caQ== Received: by 10.68.212.133 with SMTP id nk5mr1504379pbc.130.1336668840912; Thu, 10 May 2012 09:54:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id ov3sm10002792pbb.35.2012.05.10.09.53.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 09:53:59 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2246888pbc.31 for ; Thu, 10 May 2012 09:53:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.74 with SMTP id he10mr2067975pbc.69.1336668838925; Thu, 10 May 2012 09:53:58 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Thu, 10 May 2012 09:53:58 -0700 (PDT) In-Reply-To: References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@inba-mail01.sonusnet.com> Date: Thu, 10 May 2012 12:53:58 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8ff24e1153975a04bfb177fb X-Gm-Message-State: ALoCoQk0rN6MqiJ4wScekta7U09j9dM6ikYj8d4PF6OQt1Uga2ElyM7JSwMP5BWrupItS8QYrFMD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about JSEP createOffer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:54:02 -0000 --e89a8ff24e1153975a04bfb177fb Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 9:48 AM, Justin Uberti wrote: > > **** >> >> ** ** >> >> I agree Roman's case of a B2BUA seems like it would need a full offer, >> although the idea of connecting an existing call to a new destination seems >> like an uncommon case; the application could simply start a new call (i.e. >> create a new PeerConnection), right?**** >> >> ** ** >> >> If we decide we need to support this, the simplest way of handling this >> would be to simply extend the |hints| parameter in createOffer to have some >> sort of "complete" flag.**** >> >> your API proposal looks good as it is possible to re-use the >> existing or offer full based on the application needs. But the application >> developer MUST aware of the implication as it calls for interop issue in >> case of federation scenario if the full offer is not sent across. >> > > The application developer only needs to do this if supporting these edge > cases is relevant to their application. > >> **** >> >> If you inter-operate with anything SIP, you need to do a full new offer every time you get a re-INVITE without a body. The reason for this is you are working with an external system. Thus you cannot guess if this re-INVITE was generated by an existing call or some sort of third party call control application which will need a full offer. This is not something that is specific to SIP only. Every time you will implement any type of interconnect between disjoint systems you will deal with a similar problem. _____________ Roman Shpount --e89a8ff24e1153975a04bfb177fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 9:48 A= M, Justin Uberti <juberti@google.com> wrote:

<= /span>

=A0

I agree Roman's case of a B2BUA seems like it wo= uld need a full offer, although the idea of connecting an existing call to = a new destination seems like an uncommon case; the application could simply= start a new call (i.e. create a new PeerConnection), right?

=A0

If we decide we need to support this, the simplest w= ay of handling this would be to simply extend the |hints| parameter in crea= teOffer to have some sort of "complete" flag.

<partha> your= API proposal looks good=A0 as it is possible to re-use the existing or off= er full based on the application needs. But the application developer=A0 MUST aware of the implication as it calls for interop issue in case of fed= eration scenario if the full offer is not sent across. </partha>


The application developer only needs to do this if supporting these ed= ge cases is relevant to their application.

<= /span>



If you inter-operate with anything SIP, you need to do a full new of= fer every time you get a re-INVITE without a body. The reason for this is y= ou are working with an external system. Thus you cannot guess if this re-IN= VITE was generated by an existing call or some sort of third party call con= trol application which will need a full offer. This is not something that i= s specific to SIP only. Every time you will implement any type of interconn= ect between disjoint systems you will deal with a similar problem.
_____________
Roman Shpount

--e89a8ff24e1153975a04bfb177fb-- From martin.thomson@gmail.com Thu May 10 10:03:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5721F86F4 for ; Thu, 10 May 2012 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 oSM+GaA13H1m for ; Thu, 10 May 2012 10:03:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9721F86BD for ; Thu, 10 May 2012 10:03:40 -0700 (PDT) Received: by bkty8 with SMTP id y8so1751855bkt.31 for ; Thu, 10 May 2012 10:03:39 -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=WNoIM+0is5Cgm54vDxXJnwnfsuSc0MYhh7LoEyxGcMY=; b=aZ9ePad5/wvbCb8izsqvbN2YEe1rRguBn2IsbIy7f8znBZGJZBG3UK58oA7y50A7kE jrCywAgE94MJIIm4mGIEG4u1HEOMJE6A5kw3pUOJfKfkZhlj5PeUTmCtPZdYFDKxfB/Z F3JMi9VM8gQGNch+DsZxqCXbYY5t/jPdRefuvwbYtG9LPgExKVZj2B+oaIQgNX6baT2H Vqk3QHTUilSC5I6U150JHZtzX8l+3PDqUtWYhHEuiVhbCP79o3bRUA+iwc8BuJUeC9gu bb4U22Vrou4mh3boMsQUR0L68imMsarGv5+dgCNvt572ae5l70ZgbMZyCUe8qv7AplBs DipA== MIME-Version: 1.0 Received: by 10.204.149.216 with SMTP id u24mr3041223bkv.36.1336669419862; Thu, 10 May 2012 10:03:39 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Thu, 10 May 2012 10:03:39 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 10 May 2012 10:03:39 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:03:46 -0000 On 10 May 2012 07:13, Cullen Jennings wrote: > The initial media flow could be forced to provide only relay ICE candidat= es to help mitigate this. (I think we decided awhile back that was one of t= he things we would provide support for in the API). Later with the user ans= wers or consents in same way, the ICE can move the media to a non relay flo= w. That's right. But you pretty much have to leave this in the hands of the application. Unless you want to provide an authenticated indication of user answer on the media path so that when the user picks up the phone you can provide other local candidates... From fluffy@iii.ca Thu May 10 12:06:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35DD21F8594 for ; Thu, 10 May 2012 12:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 cinijwoMeV5T for ; Thu, 10 May 2012 12:06:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E358021F8595 for ; Thu, 10 May 2012 12:06:00 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C4FD322E253; Thu, 10 May 2012 15:05:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> Date: Thu, 10 May 2012 13:05:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericss on.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:06:01 -0000 I'm a very confused on what type of forking (with ICE) use case people = want to satisfy.=20 I agree with you that PRANSWER does make things more complicated but I = presented at several of the meetings about how things just don't work = without it or something like it so I don't see how to avoid it.=20 On May 9, 2012, at 12:34 AM, Ravindran, Parthasarathi wrote: > Hi Justin, > =20 > Sorry for the delay in reply. There are two issues associated with = this scenario: > =20 > Issue 1) SIP Forking : This is solved by peerconnection cloning > =20 > Issue 2) UPDATE support within SIP early dialog in the non-forking = scenario. Here, the cloning will not solve issue as the answerer = originated the new offer during SDP_PRANSWER state . Issue 2 is the = title of this mail thread. > =20 > IMO, SDP_PRANSWER will complicate the offer/answer state machine. > =20 > Thanks > Partha > =20 > =20 > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Justin Uberti > Sent: Tuesday, May 08, 2012 8:40 PM > To: Christer Holmberg > Cc: Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in = JSEP > =20 > The conclusion on this thread seems to be that the right way to = address this problem is via PeerConnection cloning, and that no changes = are needed to the JSEP state machine. I'll work with Richard to figure = out how we should extend JSEP to support cloning. >=20 > On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg = wrote: > Hi, >=20 > >>>>You could also choose not to alert the remote user until the ICE = procedures have finished - more or less using ICE with preconditions. > >>>> > >>>> Of course, that is going to trigger actions in STUN/TURN servers, = even if the called party won't accept the call, but at least from a user > >>>> experience perspective that is still better than lifting the = hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish = seconds before one can start to talk. > >>> > >>> This also has a downside of disclosing user's IP to the caller = without the user confirmation. For a lot of applications this can be = serious security flaw. > >> > >> The client can still log when ICE procedures occur. > >> > >> Because, even if I wait until your phone starts to ring, most = likely I would still get your IP address without user confirmation = (speaking in SIP terms, phones normally don't ask for user permission = before they send 18x with SDP), eventhough you would easier be made = aware of that it happens. > > > > Another alternative is of course to do ICE with an SBC, and/or = having an SBC doing ICE on behalf of you :) > > > > > > This is true for SIP but was as far as I know was specifically = designed around in WebRTC. WebRTC signaling server acts as B2BUA so any = type of ringing notification goes through the web server and does not = need to carry any type of client address information. The client address = information is only provided > > when SDP answer is sent or ICE negotiation is started. >=20 > Assuming you are only going to make user confirmation (read: accept = calls) in cases where you absolutely sure that the caller isn't someone = trying to get your IP address. >=20 > But, never the less, having a solution where I first have to give user = confirmation, and then wait until I can start to talk, is probably = something most people want to avoid. Depending upon, of course, how long = the waiting time is. >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu May 10 12:06:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63311E80BE for ; Thu, 10 May 2012 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 ov4WgoYp6OWs for ; Thu, 10 May 2012 12:06:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B911E80BA for ; Thu, 10 May 2012 12:06:34 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1693422E256; Thu, 10 May 2012 15:06:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 13:06:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericss on.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:06:35 -0000 Uh, I don't think we are ready to design anything yet - I am still 100% = confused on what the use case we are trying to solve is. Is it forking = on at the browser, in intermediate node, in SIP, parallel, sequential or = what? I want to see the end user use cases we need to deal with. The = example Randell gave seems reasonable but seem like it would best be = handled with just multiple independent PeerConnection. The combination = of requiring ICE and SIP parallel forking is very complicated - = particularly without Reliable provisions responses and all the = complexity that ensues. So before we go down this path, lets get clearer on what we are trying = to accomplish. Cullen On May 8, 2012, at 9:09 AM, Justin Uberti wrote: > The conclusion on this thread seems to be that the right way to = address this problem is via PeerConnection cloning, and that no changes = are needed to the JSEP state machine. I'll work with Richard to figure = out how we should extend JSEP to support cloning. >=20 > On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg = wrote: > Hi, >=20 > >>>>You could also choose not to alert the remote user until the ICE = procedures have finished - more or less using ICE with preconditions. > >>>> > >>>> Of course, that is going to trigger actions in STUN/TURN servers, = even if the called party won't accept the call, but at least from a user > >>>> experience perspective that is still better than lifting the = hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish = seconds before one can start to talk. > >>> > >>> This also has a downside of disclosing user's IP to the caller = without the user confirmation. For a lot of applications this can be = serious security flaw. > >> > >> The client can still log when ICE procedures occur. > >> > >> Because, even if I wait until your phone starts to ring, most = likely I would still get your IP address without user confirmation = (speaking in SIP terms, phones normally don't ask for user permission = before they send 18x with SDP), eventhough you would easier be made = aware of that it happens. > > > > Another alternative is of course to do ICE with an SBC, and/or = having an SBC doing ICE on behalf of you :) > > > > > > This is true for SIP but was as far as I know was specifically = designed around in WebRTC. WebRTC signaling server acts as B2BUA so any = type of ringing notification goes through the web server and does not = need to carry any type of client address information. The client address = information is only provided > > when SDP answer is sent or ICE negotiation is started. >=20 > Assuming you are only going to make user confirmation (read: accept = calls) in cases where you absolutely sure that the caller isn't someone = trying to get your IP address. >=20 > But, never the less, having a solution where I first have to give user = confirmation, and then wait until I can start to talk, is probably = something most people want to avoid. Depending upon, of course, how long = the waiting time is. >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu May 10 12:51:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2202421F8649 for ; Thu, 10 May 2012 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Dbp61wQ4L-6b for ; Thu, 10 May 2012 12:51:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39D2721F8644 for ; Thu, 10 May 2012 12:51:32 -0700 (PDT) Received: by dacx6 with SMTP id x6so2250267dac.31 for ; Thu, 10 May 2012 12:51:32 -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=PyBNUiVWk3Cnkzn5ptjQ8JZxGhPYqfV6b7YRXHO711c=; b=IVAhAmEa133lb087jwlMlTf7IOb89b2KJJm680y3cqF7yDI1KMWGZMIKSnppImrngy XgpIWJHcH6fBTVBTGoJVcykFCVFCwTFSnwzYCVtjiV/didQFuDtT5a6t5UJdi51w+kdq Sbb1QXh2H4XWSPwnNJWbjpMuxG2RA/MaafNCD03/kh4r01KRWC8ezl9gIArSJXBs9QO0 lZx3fL//eSkKcLXC6lc1nrNfJ7HGx5YXVSMjkzQfqqghnbG/kFcx5Rd9NR5837mqhcxR qLNIDjsCO7NQTOk+38QNQoNhdwRMau2EGxBD/NBAXN/OOqOwK1hxw/NBpfRtZTey/Hq9 rVqQ== Received: by 10.68.203.98 with SMTP id kp2mr57401pbc.103.1336679491908; Thu, 10 May 2012 12:51:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id ud10sm10390649pbc.25.2012.05.10.12.51.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 12:51:30 -0700 (PDT) Received: by dacx6 with SMTP id x6so2250227dac.31 for ; Thu, 10 May 2012 12:51:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.74 with SMTP id he10mr3612079pbc.69.1336679489369; Thu, 10 May 2012 12:51:29 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Thu, 10 May 2012 12:51:29 -0700 (PDT) In-Reply-To: <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> Date: Thu, 10 May 2012 15:51:29 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=e89a8ff24e1124777404bfb3f206 X-Gm-Message-State: ALoCoQlISgi9bdT6YEMDWYwE1C3oNAJ/J9dJN2VYABTy9KV6FQaFkbqu6Ooqg5iYUywMCTsl2+q/ Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:51:33 -0000 --e89a8ff24e1124777404bfb3f206 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 3:06 PM, Cullen Jennings wrote: > > Uh, I don't think we are ready to design anything yet - I am still 100% > confused on what the use case we are trying to solve is. Is it forking on > at the browser, in intermediate node, in SIP, parallel, sequential or what? > I want to see the end user use cases we need to deal with. The example > Randell gave seems reasonable but seem like it would best be handled with > just multiple independent PeerConnection. The combination of requiring ICE > and SIP parallel forking is very complicated - particularly without > Reliable provisions responses and all the complexity that ensues. > > So before we go down this path, lets get clearer on what we are trying to > accomplish. > > One use case is interop with SIP with parallel forking, reliable provisioning responses, UPDATE, and ICE. The big question regarding this use case is availability of anything that supports parallel forking, reliable provisioning and UPDATE. I actually think ICE makes implementation of this use case easier, not harder. The real end user use case is any type of service where calling destination is a small group of people. This allows to initiate a single offer and send it to all the members of the group. In most cases only one person will reply, but, in a smaller set of cases, several people from the group will answer. In the later case, you need a mechanism to clone the original peer connection (or to create additional peer connections based on the original offer) and deal with additional answers independently. This is a very common use case for any type of service where people use multiple devices. For instance if we add voice/video calling to a web mail program, I can be logged in from multiple devices. It can also be a shared account (like support@acme.com) where several different people are logged in to the same account. When someone places a call to a shared account, several people can answer at the same time. I know this can be addressed by sending a separate message and reversing the call setup direction (each accepting party creates an offer and sends it back), but this causes another set of issues related to slow call setup and media clipping. _____________ Roman Shpount --e89a8ff24e1124777404bfb3f206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 3:06 PM, Cullen Jenn= ings <fluffy@iii.ca> wrote:

Uh, I don't think we are ready to design anything yet - I am still 100%= confused on what the use case we are trying to solve is. Is it forking on = at the browser, in intermediate node, in SIP, parallel, sequential or what?= I want to see the end user use cases we need to deal with. The example Ran= dell gave seems reasonable but seem like it would best be handled with just= multiple independent PeerConnection. The combination of requiring ICE and = SIP parallel forking is very complicated - particularly without Reliable pr= ovisions responses and all the complexity that ensues.

So before we go down this path, lets get clearer on what we are trying to a= ccomplish.


One use case is interop with SIP with parallel forking, reliab= le provisioning responses, UPDATE, and ICE. The big question regarding this= use case is availability of anything that supports parallel forking, relia= ble provisioning and UPDATE. I actually think ICE makes implementation of t= his use case easier, not harder.

The real end user use case is any type of service where calling destina= tion is a small group of people. This allows to initiate a single offer and= send it to all the members of the group. In most cases only one person wil= l reply, but, in a smaller set of cases, several people from the group will= answer. In the later case, you need a mechanism to clone the original peer= connection (or to create additional peer connections based on the original= offer) and deal with additional answers independently.

This is a very common use case for any type of service where people use= multiple devices. For instance if we add voice/video calling to a web mail= program, I can be logged in from multiple devices. It can also be a shared= account (like support@acme.com) wh= ere several different people are logged in to the same account. When someon= e places a call to a shared account, several people can answer at the same = time.

I know this can be addressed by sending a separate message=A0 and rever= sing the call setup direction (each accepting party creates an offer and se= nds it back), but this causes another set of issues related to slow call se= tup and media clipping.
_____________
Roman Shpount

--e89a8ff24e1124777404bfb3f206-- From martin.thomson@gmail.com Thu May 10 12:53:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0F21F866E for ; Thu, 10 May 2012 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, GB_I_LETTER=-2, 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 OXv9Y-qyHXbu for ; Thu, 10 May 2012 12:53:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6421F85FC for ; Thu, 10 May 2012 12:53:14 -0700 (PDT) Received: by bkty8 with SMTP id y8so1907375bkt.31 for ; Thu, 10 May 2012 12:53:13 -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=RrMKimw6bLC9mjvWKI9SBh/+5zsq4PrZg6Lsqs0ZP9c=; b=MUUsRdqfG1KRvXiZjo3imS+EIY5FA+72zATgdVc2wpCW79w0DLFt3rHCnFbUl/1k7j LyBEGHRJxh1K6Ga3wOZIb6/9/Hj0RIl0Ue6LbeMEy/JsZalnUUasSPYTz2Be4wewyBlc R69vqdS6fyDmZktB/+ITn9OWLOqjd2FGffeRQLJf/a0b6IYAlmkxH9CBk9OOlq6YQE8D EBb5Jto3yCmYUpePHG8ZVOapNk7taYjAzfHIMVgx4oRCB/fAyxuFWfrbBjICXnD3dW5k kdyVtqD+JXvuRFdS9gIED+qlmqRE1qeEdrlzk0JZDEgrfOdo6gKxBxZBIkeue0pGRDFF n5RQ== MIME-Version: 1.0 Received: by 10.205.33.136 with SMTP id so8mr3489342bkb.1.1336679593714; Thu, 10 May 2012 12:53:13 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Thu, 10 May 2012 12:53:13 -0700 (PDT) In-Reply-To: <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> Date: Thu, 10 May 2012 12:53:13 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:53:15 -0000 On 10 May 2012 12:05, Cullen Jennings wrote: > I'm a very confused on what type of forking (with ICE) use case people want to satisfy. Here's the use case as I understand it: create offer and send to some thing the offer actually hits multiple things multiple answers arrive want to establish sessions with all of them That's the use case. Adding it to the use cases draft (or not) is probably something that needs to be debated more. --Martin p.s. How the offer reaches multiple things doesn't matter much. I see too many emails on these lists that include the letters S, I and P together. From fluffy@iii.ca Thu May 10 13:55:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E3211E8074 for ; Thu, 10 May 2012 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 hN3bZvyigDYJ for ; Thu, 10 May 2012 13:55:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA84921F85D3 for ; Thu, 10 May 2012 13:55:24 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFD2422E257; Thu, 10 May 2012 16:55:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 14:55:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:55:25 -0000 On May 10, 2012, at 1:51 PM, Roman Shpount wrote: >=20 > On Thu, May 10, 2012 at 3:06 PM, Cullen Jennings = wrote: >=20 > Uh, I don't think we are ready to design anything yet - I am still = 100% confused on what the use case we are trying to solve is. Is it = forking on at the browser, in intermediate node, in SIP, parallel, = sequential or what? I want to see the end user use cases we need to deal = with. The example Randell gave seems reasonable but seem like it would = best be handled with just multiple independent PeerConnection. The = combination of requiring ICE and SIP parallel forking is very = complicated - particularly without Reliable provisions responses and all = the complexity that ensues. >=20 > So before we go down this path, lets get clearer on what we are trying = to accomplish. >=20 >=20 > One use case is interop with SIP with parallel forking, reliable = provisioning responses, UPDATE, and ICE. The big question regarding this = use case is availability of anything that supports parallel forking, = reliable provisioning and UPDATE. I actually think ICE makes = implementation of this use case easier, not harder. >=20 > The real end user use case is any type of service where calling = destination is a small group of people. This allows to initiate a single = offer and send it to all the members of the group. In most cases only = one person will reply, but, in a smaller set of cases, several people = from the group will answer. In the later case, you need a mechanism to = clone the original peer connection (or to create additional peer = connections based on the original offer) and deal with additional = answers independently.=20 >=20 > This is a very common use case for any type of service where people = use multiple devices. For instance if we add voice/video calling to a = web mail program, I can be logged in from multiple devices. It can also = be a shared account (like support@acme.com) where several different = people are logged in to the same account. When someone places a call to = a shared account, several people can answer at the same time. >=20 > I know this can be addressed by sending a separate message and = reversing the call setup direction (each accepting party creates an = offer and sends it back), but this causes another set of issues related = to slow call setup and media clipping. > _____________ > Roman Shpount >=20 So let me try and make sure I understand this uses case. The web browser = sends some signaling to a server that convert it to a sip call to the = fork@example.com address. This sends it to the example.com sip server = that parallel forks it to two SIP UASs that are so two phones ring at = the same time. Now both theses phones are going to negotiate ICE by = using reliably provisional responses.=20 What products actually do parallel forking like this and return = provisional reliable responses with ICE. I'm sort of questioning this is = a common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX = systems I have seen that support ringing multiple phones at the same = time don't seem to do this way. They manage to hide the parallel forking = with a B2BUA model and make it look like sequential forking.=20 From juberti@google.com Thu May 10 13:56:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5B121F85D3 for ; Thu, 10 May 2012 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tui108V8yQRC for ; Thu, 10 May 2012 13:56:28 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC021F85CF for ; Thu, 10 May 2012 13:56:27 -0700 (PDT) Received: by qabj40 with SMTP id j40so1073005qab.15 for ; Thu, 10 May 2012 13:56:27 -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:x-system-of-record; bh=RWW6QX03lS/qyvW0v1S19WA01DwNt13DZYTzv9QmFX4=; b=UFMJPFS38ej8jO8FhRYdDx1BGjQOXsfxCOS50odIJUW3EnyeDwepvg/6kkDo6b/DI9 PqYGxFw94k5A6oxIDZRdUh+c3lkj49S0xy3X7gAN+GtUPC0uPr7a9MNhS4X+G2gOQNf3 94pUJoSUiUbt/1Opkdu4CD8v2ySoFmB7qc4Hgj6imZBOGLPoaTjNCW28551WWEwNarQI 8SQg2j5YtY5kMMpf40BlJ4QLHmTm8vrsOBriUK2SVC89HA/gl9JZbEc3Ak7ztCtrTLz8 TOHXAeDa6sVhRPxAZIVCoqeGrXuq2rzK9QiFsgIH9kcauypbPMnsyPE7CqJZ63RGhKuZ uaHg== 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-system-of-record:x-gm-message-state; bh=RWW6QX03lS/qyvW0v1S19WA01DwNt13DZYTzv9QmFX4=; b=RTCxah3qsx15xj+T1/3lXtg2ppO+PT0xlvP8k6beuvW61hLbdSH0vDezfVTrgLdOcL 2q0h1w8mDoYEfNZ2opvDoxDHAueutoLpPSJxUFatSyRx63H8QVapDr/pREnJChU1X4gj yZB+NkRJwa54nGxYHCyxcwHIw/X0m/iIv4odvByDhs9yrlXuxTifXbRlobFwlebmxqwR bCJjLHmIj1Wbi1L+BVyPVrFE5Fyt7EXIq3O0nZ6vFfcPR/7TgPYZeRp14zlrw0gn4xdh EyckgknPgkDvMeULKHNMrQxiOzOf/TCOn+buS1OgKo8u6hO3t7P/y5foRvW0tc7YPzSn kEQw== Received: by 10.229.114.203 with SMTP id f11mr3001468qcq.10.1336683387505; Thu, 10 May 2012 13:56:27 -0700 (PDT) Received: by 10.229.114.203 with SMTP id f11mr3001453qcq.10.1336683387267; Thu, 10 May 2012 13:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Thu, 10 May 2012 13:56:07 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> From: Justin Uberti Date: Thu, 10 May 2012 16:56:07 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=00235429db9079ac4c04bfb4da15 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmmgLspk0tXUgtSzHs0NfDlYuhgA+bETr637rAMjBE2SssXB8mptzGRtX3hrrIAqFOnqDpmXF0qL1rNOgGb94hXgKOTtUjE513CQlphP7tHHvh0p1nXBUNKCymz+xKBCxZCAmyR Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:56:29 -0000 --00235429db9079ac4c04bfb4da15 Content-Type: text/plain; charset=UTF-8 The other use case is the one Partha originally mentioned, and recently resurfaced: Issue 2) UPDATE support within SIP early dialog in the non-forking scenario. Here, the cloning will not solve issue as the answerer originated the new offer during SDP_PRANSWER state . Issue 2 is the title of this mail thread. which I think expands to: 1. local PC1 sends offer, forks to remote PC1 and PC2 2. remote PC1 receives offer, sends pranswer 3. local PC1 applies this pranswer 4. remote PC2 receives offer, sends pranswer 5. local PC1 applies this pranswer 6. remote PC1 sends update (i.e. new offer) 7. local PC1 does ??? Richard mentioned that this could be solved by cloning, and I think I agree. local PC1 can clone at step 5, and create local PC2. local PC2 stays in the pranswer state; local PC1 applies the previous pranswer as final, and then handles the new offer (update). On Thu, May 10, 2012 at 3:53 PM, Martin Thomson wrote: > On 10 May 2012 12:05, Cullen Jennings wrote: > > I'm a very confused on what type of forking (with ICE) use case people > want to satisfy. > > Here's the use case as I understand it: > > create offer and send to some thing > the offer actually hits multiple things > multiple answers arrive > want to establish sessions with all of them > > That's the use case. Adding it to the use cases draft (or not) is > probably something that needs to be debated more. > > --Martin > > p.s. How the offer reaches multiple things doesn't matter much. I see > too many emails on these lists that include the letters S, I and P > together. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00235429db9079ac4c04bfb4da15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The other use case is the one Partha originally mentioned, and recentl= y resurfaced:

Issue 2)=C2=A0 UPDATE support within SIP early dialog in the non-forking s= cenario. Here, the cloning will not solve issue as the answerer originated = the new offer during SDP_PRANSWER state . Issue 2 is the title of this mail= thread.


which I think expands to:
1. local PC1 sends = offer, forks to remote PC1 and PC2
2. remote PC1 receives offer, = sends pranswer
3. local PC1 applies this pranswer
4. remote PC2 receives offer, sends pranswer
5. local PC1 applies this pranswer
6. remote PC1 sends updat= e (i.e. new offer)
7. local PC1 does ???=C2=A0

Richard mentioned that this could be solved by cloning, and I think = I agree.
local PC1 can clone at step 5, and create local PC2. local PC2 stays i= n the pranswer state; local PC1 applies the previous pranswer as final, and= then handles the new offer (update).


On Thu, May 10, 2012 at 3:53 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 10 May 2012 12:05, Cullen Jennings <fluffy@iii.ca> wrote:
> I'm a very confused on what type of forking (with ICE) use case pe= ople want to satisfy.

Here's the use case as I understand it:

create offer and send to some thing
the offer actually hits multiple things
multiple answers arrive
want to establish sessions with all of them

That's the use case. =C2=A0Adding it to the use cases draft (or not) is=
probably something that needs to be debated more.

--Martin

p.s. How the offer reaches multiple things doesn't matter much. =C2=A0I= see
too many emails on these lists that include the letters S, I and P
together.
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--00235429db9079ac4c04bfb4da15-- From fluffy@iii.ca Thu May 10 13:56:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA4B11E8099 for ; Thu, 10 May 2012 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BAzP53vtD-u for ; Thu, 10 May 2012 13:56:39 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2545D11E8091 for ; Thu, 10 May 2012 13:56:39 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF0BF22E25C; Thu, 10 May 2012 16:56:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 14:56:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> To: Martin Thomson X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:56:39 -0000 I was looking more for the actually sort of end user use case where this = might happen.=20 On May 10, 2012, at 1:53 PM, Martin Thomson wrote: > On 10 May 2012 12:05, Cullen Jennings wrote: >> I'm a very confused on what type of forking (with ICE) use case = people want to satisfy. >=20 > Here's the use case as I understand it: >=20 > create offer and send to some thing > the offer actually hits multiple things > multiple answers arrive > want to establish sessions with all of them >=20 > That's the use case. Adding it to the use cases draft (or not) is > probably something that needs to be debated more. >=20 > --Martin >=20 > p.s. How the offer reaches multiple things doesn't matter much. I see > too many emails on these lists that include the letters S, I and P > together. From martin.thomson@gmail.com Thu May 10 14:07:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65E21F85AE for ; Thu, 10 May 2012 14:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.754 X-Spam-Level: X-Spam-Status: No, score=-3.754 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 kexhflmq9uNV for ; Thu, 10 May 2012 14:07:37 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC81821F852D for ; Thu, 10 May 2012 14:07:36 -0700 (PDT) Received: by bkty8 with SMTP id y8so1971398bkt.31 for ; Thu, 10 May 2012 14:07:35 -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=sWOhhB2kC/9NNQMDMyYoGEJHE8AvynK7KLar8js4uvk=; b=hM+4d5jfg53mMTtPPf3QigyThbASqgSMMpjRxvgtRUXkjvqSLwg6oq7WfDu55l0wFF +L1lS3J30kOFYlkiJxlsODXls0Bf3regw3BQ7GoXyApwFyXH7q9dQR10zY/sUmVnvbug S8YK8NA4jYJBkWQwUfpVhE+C2yvrI3h15ITG8RrTnJu1Pv05PDsPjmoon3nbsice1h1K YeY3olUlpHlvZR3RtHvtB6GGb32ruQqa6LaNXGfizasgvjkVuxyBbbOKVHxHujeTABdu GfeY/s++2Pbe4ggzObx9OMGyZJcBqfusXILICngmYxeJdoe5gZC3TwwUyVZFZKuf+Jzq e0Sg== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr3734294bkv.26.1336684055876; Thu, 10 May 2012 14:07:35 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Thu, 10 May 2012 14:07:35 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> Date: Thu, 10 May 2012 14:07:35 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:07:38 -0000 On 10 May 2012 13:56, Cullen Jennings wrote: > I was looking more for the actually sort of end user use case where this might happen. I ring you. Your mobile and home phone both ring. You answer your mobile, your daughter answers the home phone. I get to talk to both of you. Of course, that's not such a great outcome. I can hear both of you, but you can't hear each other unless I have really bad echo cancellation. I tend to think of this as solving a really interesting signaling problem that doesn't really have any practical application. If you want to talk to both people, then you should signal the creation of a conference call. --Martin From ibc@aliax.net Thu May 10 14:13:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADFF21F8624 for ; Thu, 10 May 2012 14:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[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 J1Psp9BnTPAC for ; Thu, 10 May 2012 14:13:02 -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 1E2AE11E80A5 for ; Thu, 10 May 2012 14:13:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1455446wgb.13 for ; Thu, 10 May 2012 14:13: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:content-transfer-encoding:x-gm-message-state; bh=42MdfdjJBisiNRtr+1eKpbmYIeuDsPcjir/8ac5JP04=; b=ePb58q7LVK9ZLTtqFx1zpUEGjgn8A2o18TEfKrxfMtK+Ag+uUd8VB0w4dfpNV10rbC Zz/lqTWfLHR4i3RV1iz6g6LMoyiuTWxzCEovlLQQx6t+rpyQ8+YOjhTfO6mbw7a7n5Kx OW3Wi4AeKYd0RdBBeHCKePKfr6m+Jf074cHTslBpuFkbA1vpdySzmDHizVJLQcUnWZPM uhACvGAzRlXwyppUThbdERpeUHxVt+eri6tISqUbjLEo0/2SavAslifX1to4lKcIK9lY PQ+J4AX9dTm/H7WHU6F8Ki2ccaHEZsv3WpBg4/aoDkTZbgOAZeRKfhU9EY3c27nOe6v1 SoyA== Received: by 10.180.93.38 with SMTP id cr6mr1133296wib.16.1336684381287; Thu, 10 May 2012 14:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.0.237 with HTTP; Thu, 10 May 2012 14:12:41 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 10 May 2012 23:12:41 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmLwQaWhA4gOhreYqWu5jmA7aCv6UMNiG0bVVL1W7PgzBBJRj106vKvICP33jpRrQHLO19v Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:13:04 -0000 2012/5/10 Cullen Jennings : > The Nortel, Cisco, Avaya, Siemens etc enterprises PBX systems I have seen= that support ringing multiple phones at the same time don't seem to do thi= s way. They manage to hide the parallel forking with a B2BUA model and make= it look like sequential forking. Hi Cullen, I strongly prefer that WebRTC use cases are based on real standards (i.e. pure SIP proxies) instead of non-standard devices (like B2BUA's that are defined nowhere). At least for me, the use case in which a "call" arrives to two different devices and both generate direct (early-media) to the origin is a mandatory use case for WebRTC, and I don't think that we should discard this use case by design in any way. Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Thu May 10 14:23:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FE411E80B2 for ; Thu, 10 May 2012 14:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.080, 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 qRvirLJyG2IA for ; Thu, 10 May 2012 14:23:32 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB50B11E80B4 for ; Thu, 10 May 2012 14:23:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2532959pbc.31 for ; Thu, 10 May 2012 14:23:32 -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=OeVFkNqoc/DNyUC5LdYuY9l56wEM8ftRBcXuvMFxRNQ=; b=fzMJNGthbuWHlr7ZX6GDZ5E/G7+e75thLKIVoCs8sQN9SsiWKNMJigYdYKO7QJRtpN Z2yPc4Gw5MHpgkOCuchQMP5ASUC8zvw3YCZ3ymCoD/7Zc/Uf7Z3CyPXrFRJirRXaP6xo n/JMLeYXDET07+eUwVm4hXX4wy0wxZOteEf9UyWkGUJ+b1I+vYNLzW6gaRdWO8seKXVG WYdkk8BuWVhKtKnDs/FA4aivGVk/gRDsjfqbxujtU7oPxJLUj4SZbcVeIF2HXoMbTL9v YG9lWsYHAWZkCMfG2oa24KLhEd/cWY92M4nWR2bYC6RwxkSKBRz3798GxKIYl1uSWRYI V2tg== Received: by 10.68.134.2 with SMTP id pg2mr12348415pbb.27.1336685012480; Thu, 10 May 2012 14:23:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id ny10sm4146563pbb.38.2012.05.10.14.23.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 14:23:31 -0700 (PDT) Received: by dacx6 with SMTP id x6so2346022dac.31 for ; Thu, 10 May 2012 14:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.233.102 with SMTP id tv6mr23985203pbc.153.1336685010477; Thu, 10 May 2012 14:23:30 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Thu, 10 May 2012 14:23:30 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> Date: Thu, 10 May 2012 17:23:30 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b33d55039e28404bfb53bca X-Gm-Message-State: ALoCoQlv6pmCyt2fX74XMtYRqZ0j9vD2dqe7CVuhPz+Jb6JysbNMBoTHZoOGzjXxwiD5Kj/dD75U Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:23:33 -0000 --047d7b33d55039e28404bfb53bca Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings wrote: > > One use case is interop with SIP with parallel forking, reliable > provisioning responses, UPDATE, and ICE. The big question regarding this > use case is availability of anything that supports parallel forking, > reliable provisioning and UPDATE. I actually think ICE makes implementation > of this use case easier, not harder. > > So let me try and make sure I understand this uses case. The web browser > sends some signaling to a server that convert it to a sip call to the > fork@example.com address. This sends it to the example.com sip server > that parallel forks it to two SIP UASs that are so two phones ring at the > same time. Now both theses phones are going to negotiate ICE by using > reliably provisional responses. > > What products actually do parallel forking like this and return > provisional reliable responses with ICE. I'm sort of questioning this is a > common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX > systems I have seen that support ringing multiple phones at the same time > don't seem to do this way. They manage to hide the parallel forking with a > B2BUA model and make it look like sequential forking. > > Let's say a standard SIP proxy (call it opensips for specificity) placing a forked call to two ICE enabled IP phones. Both phones answer with 200 OK. _____________ Roman Shpount --047d7b33d55039e28404bfb53bca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 4:55 PM, Cullen Jenn= ings <fluffy@iii.ca> wrote:
> One use case is interop with SIP with parallel forking, reliable provi= sioning responses, UPDATE, and ICE. The big question regarding this use cas= e is availability of anything that supports parallel forking, reliable prov= isioning and UPDATE. I actually think ICE makes implementation of this use = case easier, not harder.

So let me try and make sure I understand this uses case. The we= b browser sends some signaling to a server that convert it to a sip call to= the fork@example.com address. This= sends it to the example.c= om sip server that parallel forks it to two SIP UASs =A0that are so two= phones ring at the same time. Now both theses phones are going to negotiat= e ICE by using reliably provisional responses.

What products actually do parallel forking like this and return provisional= reliable responses with ICE. I'm sort of questioning this is a common = use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX systems I h= ave seen that support ringing multiple phones at the same time don't se= em to do this way. They manage to hide the parallel forking with a B2BUA mo= del and make it look like sequential forking.


Let's say a standard SIP proxy (call it opensips= for specificity) placing a forked call to two ICE enabled IP phones. Both = phones answer with 200 OK.

_____________
Roman Shpount

--047d7b33d55039e28404bfb53bca-- From fluffy@iii.ca Thu May 10 15:29:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8594B21F85F2 for ; Thu, 10 May 2012 15:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 0cSG-7sPyBMt for ; Thu, 10 May 2012 15:29:30 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AF46D21F85F0 for ; Thu, 10 May 2012 15:29:30 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D578422E25B; Thu, 10 May 2012 18:29:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 16:29:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <865D30F8-A632-4D2C-97B4-693854F03210@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 22:29:31 -0000 On May 10, 2012, at 3:23 PM, Roman Shpount wrote: >=20 > On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings = wrote: > > One use case is interop with SIP with parallel forking, reliable = provisioning responses, UPDATE, and ICE. The big question regarding this = use case is availability of anything that supports parallel forking, = reliable provisioning and UPDATE. I actually think ICE makes = implementation of this use case easier, not harder. >=20 > So let me try and make sure I understand this uses case. The web = browser sends some signaling to a server that convert it to a sip call = to the fork@example.com address. This sends it to theexample.com sip = server that parallel forks it to two SIP UASs that are so two phones = ring at the same time. Now both theses phones are going to negotiate ICE = by using reliably provisional responses. >=20 > What products actually do parallel forking like this and return = provisional reliable responses with ICE. I'm sort of questioning this is = a common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX = systems I have seen that support ringing multiple phones at the same = time don't seem to do this way. They manage to hide the parallel forking = with a B2BUA model and make it look like sequential forking. >=20 >=20 > Let's say a standard SIP proxy (call it opensips for specificity) = placing a forked call to two ICE enabled IP phones. Both phones answer = with 200 OK. With a standard SIP proxy, only one of the 200 would be sent back to the = web browser.=20= From roman@telurix.com Thu May 10 15:40:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770A021F85BB for ; Thu, 10 May 2012 15:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Gpk7DMFy4RtX for ; Thu, 10 May 2012 15:40:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C326521F853C for ; Thu, 10 May 2012 15:40:41 -0700 (PDT) Received: by dacx6 with SMTP id x6so2408659dac.31 for ; Thu, 10 May 2012 15:40: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gMZ3ynjxvttAMEqp+/ZODKE9PyNz2zIXSsaYpbbLKQA=; b=NxtgeWYyvLF1iuQeeNuX1AfR9orzEza8Vx/L9PhVKG7ifEsHJYUA+6SROnFf65dfHp oq8jZqFOhTjuZN8jUoty0iC9tp6JB6wfVh8tYJxoUmhtHJ3LWatlYJMhYoVmfImfy6Tf prOjSyJGs/w51wW0l4VDSvok8cM5ytS7Oxuw3SE5xycrvwtcsMBQi8cTO49YprCrj2A1 5WqdbnhnV1ymm+vvPebjtxmCc91xAICt69byRdrL2gaf89bHPZE1v1OY/DmlKOY6iG+l YrrP1YVKy7I2ZQEIYi50eAbYWtnDU/IvSzBl+2bwUvmjc18I+eYUav7XE5VAYV30g0fM JbbA== Received: by 10.68.216.98 with SMTP id op2mr24986642pbc.93.1336689641530; Thu, 10 May 2012 15:40:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id d2sm10739052pbw.39.2012.05.10.15.40.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 15:40:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2596216pbc.31 for ; Thu, 10 May 2012 15:40:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.196 with SMTP id re4mr23495390pbc.111.1336689639944; Thu, 10 May 2012 15:40:39 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Thu, 10 May 2012 15:40:39 -0700 (PDT) In-Reply-To: <865D30F8-A632-4D2C-97B4-693854F03210@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> <865D30F8-A632-4D2C-97B4-693854F03210@iii.ca> Date: Thu, 10 May 2012 18:40:39 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=e89a8ff2437129f22904bfb64ffe X-Gm-Message-State: ALoCoQnftblRUNp57nrx5KJhFeJyLTqWzqb64XX/xYKBR11jq7z5huiMMq7OoTTZYC0rCzW0G2/n Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 22:40:42 -0000 --e89a8ff2437129f22904bfb64ffe Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 10, 2012 at 6:29 PM, Cullen Jennings wrote: > > On May 10, 2012, at 3:23 PM, Roman Shpount wrote: > > > > > On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings wrote: > > > One use case is interop with SIP with parallel forking, reliable > provisioning responses, UPDATE, and ICE. The big question regarding this > use case is availability of anything that supports parallel forking, > reliable provisioning and UPDATE. I actually think ICE makes implementation > of this use case easier, not harder. > > > > So let me try and make sure I understand this uses case. The web browser > sends some signaling to a server that convert it to a sip call to the > fork@example.com address. This sends it to theexample.com sip server that > parallel forks it to two SIP UASs that are so two phones ring at the same > time. Now both theses phones are going to negotiate ICE by using reliably > provisional responses. > > > > What products actually do parallel forking like this and return > provisional reliable responses with ICE. I'm sort of questioning this is a > common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX > systems I have seen that support ringing multiple phones at the same time > don't seem to do this way. They manage to hide the parallel forking with a > B2BUA model and make it look like sequential forking. > > > > > > Let's say a standard SIP proxy (call it opensips for specificity) > placing a forked call to two ICE enabled IP phones. Both phones answer with > 200 OK. > > With a standard SIP proxy, only one of the 200 would be sent back to the > web browser. AFAIK a standard proxy will forward multiple 200 OK responses (see section 16.7 of RFC 3261). We have the same problem with 183 responses from two phones anyway. _____________ Roman Shpount --e89a8ff2437129f22904bfb64ffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 6:29 P= M, Cullen Jennings <fluffy@iii.ca> wrote:

On May 10, 2012, at 3:23 PM, Roman Shpount wrote:

>
> On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> > One use case is interop with SIP with parallel forking, reliable = provisioning responses, UPDATE, and ICE. The big question regarding this us= e case is availability of anything that supports parallel forking, reliable= provisioning and UPDATE. I actually think ICE makes implementation of this= use case easier, not harder.
>
> So let me try and make sure I understand this uses case. The web= browser sends some signaling to a server that convert it to a sip call to = the fork@example.com address. This = sends it to theexample.= com sip server that parallel forks it to two SIP UASs =A0that are so tw= o phones ring at the same time. Now both theses phones are going to negotia= te ICE by using reliably provisional responses.
>
> What products actually do parallel forking like this and return provis= ional reliable responses with ICE. I'm sort of questioning this is a co= mmon use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX system= s I have seen that support ringing multiple phones at the same time don'= ;t seem to do this way. They manage to hide the parallel forking with a B2B= UA model and make it look like sequential forking.
>
>
> Let's say a standard SIP proxy (call it opensips for specificity) = placing a forked call to two ICE enabled IP phones. Both phones answer with= 200 OK.

With a standard SIP proxy, only one of the 200 would be sent back to = the web browser.

AFAIK a standard proxy will forward = multiple 200 OK responses (see section 16.7 of RFC 3261). We have the same = problem with 183 responses from two phones anyway.
_____________
Roman Shpount
--e89a8ff2437129f22904bfb64ffe-- From fluffy@iii.ca Thu May 10 15:47:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44E11E80B0 for ; Thu, 10 May 2012 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 fy4jatFwg7N8 for ; Thu, 10 May 2012 15:47:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7428511E80AF for ; Thu, 10 May 2012 15:47:53 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 015D222E253; Thu, 10 May 2012 18:47:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 10 May 2012 16:47:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> To: Martin Thomson X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 22:47:54 -0000 On May 10, 2012, at 3:07 PM, Martin Thomson wrote: > On 10 May 2012 13:56, Cullen Jennings wrote: >> I was looking more for the actually sort of end user use case where = this might happen. >=20 > I ring you. > Your mobile and home phone both ring. > You answer your mobile, your daughter answers the home phone. > I get to talk to both of you. >=20 > Of course, that's not such a great outcome. I can hear both of you, > but you can't hear each other unless I have really bad echo > cancellation. >=20 > I tend to think of this as solving a really interesting signaling > problem that doesn't really have any practical application. If you > want to talk to both people, then you should signal the creation of a > conference call. >=20 > --Martin That an good use cases, except the people need to be able to hear each = other. It gets called lots of things but some PBXs call it bridged line = appearance. Variation of it have been discussed in bliss and = draft-ietf-bliss-shared-appearances. It really comes down to where you = think the conferencing should happen. If it does not happened on the the = callers phone, seems like existing jsep idea should be able to do this. = (given the callee is the phone that is most likely out of administrative = control of the other two phones that set up bridged line a appearance, = assuming that phone can and is willing to do the conferencing seems like = a bad architecture for this problem). Again lot of systems do this today = in SIP and seem to do it without needing forcing the callers phones to = deal with multiple simultaneous calls signaled in some way I don't even = know how to signal in SIP.=20 From stefan.lk.hakansson@ericsson.com Fri May 11 06:01:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6C21F86FD for ; Fri, 11 May 2012 06:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 T2QMGXXivKRU for ; Fri, 11 May 2012 06:01:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 62BE521F86FA for ; Fri, 11 May 2012 06:01:03 -0700 (PDT) X-AuditID: c1b4fb25-b7b48ae0000025b3-e2-4fad0d8d725e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B4.AC.09651.D8D0DAF4; Fri, 11 May 2012 15:01:02 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 15:01:00 +0200 Message-ID: <4FAD0D8C.7020701@ericsson.com> Date: Fri, 11 May 2012 15:01:00 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 13:01:04 -0000 I've been sketching on a new use-case. The use-case is intended to derive requirements that enable low complex central nodes for multi party sessions, which in turn leads to requirements regarding (essentially) keying solution for SRTP and the possibility for the app to control/set things in the media configuration (in other words, for JSEP): Multi-party with low complexity central node ============================================== A geographically spread (charity, non-profit, school) organization offers its members multi-party video communication via a shared virtual room that participants can enter and leave at any time. At times there are many persons in the virtual room (20+), at other times very few (3-5, or even 0-1). The application will control if few participants (a subset) are shown at a higher fidelity or if many (all) are shown at a lower fidelity or a mix of some few at high fidelity and the rest at much lower fidelity given the existing bandwidth limitations between participants. Since there are at times many persons in the virtual room, it is not feasible to set up a mesh. The bandwidth needed by a participant exceeds what many members have access to, especially in their uplinks, so instead a central media node is deployed. In addition, the organization does not have access to much funds, but has to rely on cheap hardware (often donated) operated by volunteers. From this use-case a high level requirement saying something like "It must be possible to set up media streams and encryption in such a way that processing in a central node is minimized (no transcoding required, no RTP packet rewriting, no decryption/re-encryption for every outgoing flow - just simple forwarding)." can be derived. This can in turn be broken down into more detailed requirements such as: - The keying solution must allow each participants to encrypt to multiple receivers without any decryption+encryption in the middle node - RTP sessions that have SSRCs from multiple PeerConnections being interconneted must be supported. From a given end-point all SSRCs will come over one PC, but the full path will be different towards different sets of SSRCs. - Signalling must be capable of establishing a common set of receiver configurations over all participants. - The API must allow for the above, i.e.: -- The app must be able to chose a keying solution that enables encryption to multiple receivers (if the app can have any control over keying method used) -- The app must be able to control SSRCs to use for outgoing streams -- The app must be able to control the receiver configuration the browser uses Is this something we should consider adding to the use-case document? Br, Stefan From juberti@google.com Fri May 11 07:24:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9189421F86E1 for ; Fri, 11 May 2012 07:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6e0v4TFOxdr for ; Fri, 11 May 2012 07:24:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7AA21F86E3 for ; Fri, 11 May 2012 07:24:35 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2409833qcs.31 for ; Fri, 11 May 2012 07:24:32 -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:x-system-of-record; bh=KQ//wLydbgrnnPYV5YfxLu8T71SLO0Y+9kiMZIM3dE4=; b=a5I0SmqqzDq9BT0Vte4x/Bkr3JUMSYk842LeIrnNE9m5UYXKmvVnwnk5RnlExu4IY1 qXPFRaispckBTAI5MSyHxKjnChF5KQ7A8QV2u3yNlV55QkSnTq8YX5Dzj3LhwXObZY6o WKHvHJGvJUYo8qn02YrMvlqhU2ClfpLbki4Eh/NJVQwVPfcSH/ZwF683vGMLZFeCnOAv VnZr37Qn+Dlj4W77fqZZ7b7YSes8CjQ5KIkcA6hwJ2T2GAEU9a8r8yVI5mPul9hFV7Ss QeFPRc7/WCw8v57iTSx2qfPQ7nKasuo3XiURZGvrecptGO+KzHwE4KievgiJJ+4EzpAH QStQ== 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-system-of-record:x-gm-message-state; bh=KQ//wLydbgrnnPYV5YfxLu8T71SLO0Y+9kiMZIM3dE4=; b=g+4XsnzCJ6q2g8oXFBjErw3ipiyFEfXQR6gEI8bFcTYoIgB5jNFfQhbAnDgJSB6/h9 8H7tQJffzOaSNSkWzB449sknLY/WFvTl6gTTWLnbhMZn8JV9vAW5HSfuTI1W8EGvpQpL abn/Mzeqhnc5MlMzV+saX+FL21+t+MY6x5FH2QUI3nPYq4ThN3biGbwsaJqacMnvcFvW 2eSo3EZZ9f1zz4LQdOFQUgcv0mt3USTOIFZA2pKWyFbD7Pxvn0fhmCDZ1gEyaE3P3IvM giv2oFdD78xM8eAJHsYhmCN6Z4Xsr5v3VMgQsgzzYrlB+0SGuXb7rBCZPHLQx3E/+Df8 xY1Q== Received: by 10.224.219.144 with SMTP id hu16mr18210025qab.97.1336746272686; Fri, 11 May 2012 07:24:32 -0700 (PDT) Received: by 10.224.219.144 with SMTP id hu16mr18209970qab.97.1336746272206; Fri, 11 May 2012 07:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.129 with HTTP; Fri, 11 May 2012 07:24:12 -0700 (PDT) In-Reply-To: <4FAD0D8C.7020701@ericsson.com> References: <4FAD0D8C.7020701@ericsson.com> From: Justin Uberti Date: Fri, 11 May 2012 10:24:12 -0400 Message-ID: To: Stefan Hakansson LK Content-Type: multipart/alternative; boundary=20cf3074b596b5b1a404bfc37e64 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmEutQIa8khf8H6RHZ5X5pJxrPG/rlUvZwkkWi4mdJ98VX/og9rhP9hMeD8JsDxs/Q3P7QHUGIIpaHJTokqqLrZMk+XxuU0bCbX6LbblERDQpGsFGJXy4EMJx9f/n0NG5cpZ3Is Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 14:24:36 -0000 --20cf3074b596b5b1a404bfc37e64 Content-Type: text/plain; charset=UTF-8 SRTP encryption is cheap, practically free on today's CPUs. I agree with the general use case but I don't agree with the conclusion that we need to require that the middlebox does not rewrite packets or perform crypto, mainly since it will increase system complexity (and the system is already quite complex). On Fri, May 11, 2012 at 9:01 AM, Stefan Hakansson LK < stefan.lk.hakansson@ericsson.com> wrote: > I've been sketching on a new use-case. The use-case is intended to > derive requirements that enable low complex central nodes for multi > party sessions, which in turn leads to requirements regarding > (essentially) keying solution for SRTP and the possibility for the app > to control/set things in the media configuration (in other words, for > JSEP): > > > Multi-party with low complexity central node > ==============================**================ > > A geographically spread (charity, non-profit, school) organization > offers its members multi-party video communication via a shared virtual > room that participants can enter and leave at any time. At times there > are many persons in the virtual room (20+), at other times very few > (3-5, or even 0-1). > > The application will control if few participants (a subset) are shown at > a higher fidelity or if many (all) are shown at a lower fidelity or a > mix of some few at high fidelity and the rest at much lower fidelity > given the existing bandwidth limitations between participants. > > Since there are at times many persons in the virtual room, it is not > feasible to set up a mesh. The bandwidth needed by a participant exceeds > what many members have access to, especially in their uplinks, so > instead a central media node is deployed. In addition, the organization > does not have access to much funds, but has to rely on cheap hardware > (often donated) operated by volunteers. > > From this use-case a high level requirement saying something like > > "It must be possible to set up media streams and encryption in such > a way that processing in a central node is minimized (no transcoding > required, no RTP packet rewriting, no decryption/re-encryption for every > outgoing flow - just simple forwarding)." > > can be derived. This can in turn be broken down into more detailed > requirements such as: > > - The keying solution must allow each participants to encrypt to > multiple receivers without any decryption+encryption in the middle node > > - RTP sessions that have SSRCs from multiple PeerConnections being > interconneted must be supported. From a given end-point all SSRCs will > come over one PC, but the full path will be different towards different > sets of SSRCs. > > - Signalling must be capable of establishing a common set of receiver > configurations over all participants. > > - The API must allow for the above, i.e.: > -- The app must be able to chose a keying solution that enables > encryption to multiple receivers (if the app can have any control over > keying method used) > -- The app must be able to control SSRCs to use for outgoing streams > -- The app must be able to control the receiver configuration the > browser uses > > Is this something we should consider adding to the use-case document? > > Br, > Stefan > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf3074b596b5b1a404bfc37e64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SRTP encryption is cheap, practically free on today's CPUs. I agree wit= h the general use case but I don't agree with the conclusion that we ne= ed to require that the middlebox does not rewrite packets or perform crypto= , mainly since it will increase system complexity (and the system is alread= y quite complex).

On Fri, May 11, 2012 at 9:01 AM, Stefan Haka= nsson LK <stefan.lk.hakansson@ericsson.com> w= rote:
I've been sketching on a new use-case. T= he use-case is intended to
derive requirements that enable low complex central nodes for multi
party sessions, which in turn leads to requirements regarding
(essentially) keying solution for SRTP and the possibility for the app
to control/set things in the media configuration (in other words, for JSEP)= :


Multi-party with low complexity central node
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A geographically spread (charity, non-profit, school) organization
offers its members multi-party video communication via a shared virtual
room that participants can enter and leave at any time. At times there
are many persons in the virtual room (20+), at other times very few
(3-5, or even 0-1).

The application will control if few participants (a subset) are shown at a higher fidelity or if many (all) are shown at a lower fidelity or a
mix of some few at high fidelity and the rest at much lower fidelity
given the existing bandwidth limitations between participants.

Since there are at times many persons in the virtual room, it is not
feasible to set up a mesh. The bandwidth needed by a participant exceeds what many members have access to, especially in their uplinks, so
instead a central media node is deployed. In addition, the organization
does not have access to much funds, but has to rely on cheap hardware
(often donated) operated by volunteers.

=C2=A0From this use-case a high level requirement saying something like

"It must be possible to set up media streams and encryption in such a way that processing in a central node is minimized (no transcoding
required, no RTP packet rewriting, no decryption/re-encryption for every outgoing flow - just simple forwarding)."

can be derived. This can in turn be broken down into more detailed
requirements such as:

- The keying solution must allow each participants to encrypt to
multiple receivers without any decryption+encryption in the middle node

- RTP sessions that have SSRCs from multiple PeerConnections being
interconneted must be supported. From a given end-point all SSRCs will
come over one PC, but the full path will be different towards different
sets of SSRCs.

- Signalling must be capable of establishing a common set of receiver
configurations over all participants.

- The API must allow for the above, i.e.:
-- The app must be able to chose a keying solution that enables
encryption to multiple receivers (if the app can have any control over
keying method used)
-- The app must be able to control SSRCs to use for outgoing streams
-- The app must be able to control the receiver configuration the
browser uses

Is this something we should consider adding to the use-case document?

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

--20cf3074b596b5b1a404bfc37e64-- From richard.ejzak@alcatel-lucent.com Fri May 11 07:26:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF5521F86F1 for ; Fri, 11 May 2012 07:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.169 X-Spam-Level: X-Spam-Status: No, score=-9.169 tagged_above=-999 required=5 tests=[AWL=1.430, 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 uzJEFX8se61v for ; Fri, 11 May 2012 07:26:27 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA221F86E1 for ; Fri, 11 May 2012 07:26:27 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4BEQQZX013435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 May 2012 09:26:26 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BEQPaC023531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 11 May 2012 09:26:26 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 11 May 2012 09:26:26 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Fri, 11 May 2012 09:26:24 -0500 Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0u/vIxRg+N5xQOTEenJG92qq9XSAAdziPw Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> In-Reply-To: <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 14:26:27 -0000 Support for multiple registered contacts and (parallel) forking are pretty = fundamental to SIP. This has little to do with conferencing. Some systems= (not all) may support only serial forking or may serialize media interacti= ons associated with parallel forking, but forking remains widely deployed a= nd useful. The point is not to support simultaneous media flow with all forked targets= (your talking to me and my daughter at the same time in Martin's example),= but to support the ability to negotiate ICE and DTLS independently with ea= ch target before one of them "answers", to minimize the potential for clipp= ing. True parallel forking has been around for a long time and is supported in s= ome (not all) existing systems. We do not mandate ICE support (for example= ) because it is commonly deployed, but because it is useful; the same princ= iple should apply here. I have not heard that simultaneous alerting of mul= tiple registered contacts is not useful, but just that some existing system= s find ways of serializing the media interactions. That is relatively easi= er to do when you don't support ICE and DTLS since media can flow almost as= soon as you signal the SDP changes. But things are different with ICE and DTLS, particularly if you want to avo= id media intermediaries. Significant clipping is a real possibility if we = have to restart ICE/DTLS after the "winner" responds with 200 OK. This is not a separate use case, but a given aspect of interworking with SI= P. Richard=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings Sent: Thursday, May 10, 2012 5:48 PM To: Martin Thomson Cc: Randell Jesup; rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP On May 10, 2012, at 3:07 PM, Martin Thomson wrote: > On 10 May 2012 13:56, Cullen Jennings wrote: >> I was looking more for the actually sort of end user use case where this= might happen. >=20 > I ring you. > Your mobile and home phone both ring. > You answer your mobile, your daughter answers the home phone. > I get to talk to both of you. >=20 > Of course, that's not such a great outcome. I can hear both of you, > but you can't hear each other unless I have really bad echo > cancellation. >=20 > I tend to think of this as solving a really interesting signaling > problem that doesn't really have any practical application. If you > want to talk to both people, then you should signal the creation of a > conference call. >=20 > --Martin That an good use cases, except the people need to be able to hear each othe= r. It gets called lots of things but some PBXs call it bridged line appeara= nce. Variation of it have been discussed in bliss and draft-ietf-bliss-shar= ed-appearances. It really comes down to where you think the conferencing sh= ould happen. If it does not happened on the the callers phone, seems like e= xisting jsep idea should be able to do this. (given the callee is the phon= e that is most likely out of administrative control of the other two phones= that set up bridged line a appearance, assuming that phone can and is will= ing to do the conferencing seems like a bad architecture for this problem).= Again lot of systems do this today in SIP and seem to do it without needin= g forcing the callers phones to deal with multiple simultaneous calls signa= led in some way I don't even know how to signal in SIP.=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From neils@vipadia.com Fri May 11 08:04:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9D21F84B6 for ; Fri, 11 May 2012 08:04:37 -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=[AWL=0.001, 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 X5PnEUykAESB for ; Fri, 11 May 2012 08:04:36 -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 98A8921F84B2 for ; Fri, 11 May 2012 08:04:36 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so1496070wib.13 for ; Fri, 11 May 2012 08:04:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JgPo6piXXnp3hUTihnNaJRlL++2b3uUrXNM8E5DeqMQ=; b=WXKTuHUCIFPN1JdzAVBxP505VUnRSprgrmI6pdQG/GDNSA2BnVtxRsOoyrkAL1LYq4 nGcrs/ike1egK/Yld+GoiEOWRZnEvpVpogiqxpp8IunZd+HRpQT91jARI4gIDhULuOmL h+bxCGHHPfw9dqsZgsFkjKKmJkaE146AKIXd49uP4RRx+lIG2N8HTYeb/RUtr2XSluLB ZGAINxE3ONcx7y4IgkKHIfCKxNsZt7/IDwZs0ezHsxMXZY6uAtHiMxXyn/rVXBZbVBpD T/FlqodOLRIGMXHrKtfPFC/aFyA8+q2Gt39SXQews+dQw8eqFm0v02mSh8MXSX0uZ0A8 2Exw== Received: by 10.180.82.136 with SMTP id i8mr8482650wiy.19.1336748675608; Fri, 11 May 2012 08:04:35 -0700 (PDT) Received: from [192.168.0.117] ([82.152.81.57]) by mx.google.com with ESMTPS id gd4sm17933064wib.6.2012.05.11.08.04.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 08:04:34 -0700 (PDT) Sender: Neil Stratford Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Neil Stratford In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Fri, 11 May 2012 16:04:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF70DE5-5C59-4B64-BAFC-394E7BBF9442@belltower.co.uk> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> To: "Ejzak, Richard P (Richard)" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmyzigAdXvszDOq2tX8gHO4hqe6RhZM4E4HA00Os546i2LB1DRzT7dLJzvG85aRbXNeSZWs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:04:37 -0000 On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote: > But things are different with ICE and DTLS, particularly if you want = to avoid media intermediaries. Significant clipping is a real = possibility if we have to restart ICE/DTLS after the "winner" responds = with 200 OK. >=20 > This is not a separate use case, but a given aspect of interworking = with SIP. The whole problem of clipping audio due to the delay between the 200OK = and the media actually flowing raises a flag that we are triggering = upper layers of the stack on the wrong event.=20 Why is anyone sending media before the media channel is fully = established? Why tell the user (or IVR etc) that the call is answered = before we have a working media channel? Neil From goran.ap.eriksson@ericsson.com Fri May 11 08:55:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733621F8611 for ; Fri, 11 May 2012 08:55:05 -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 Q25Nw2J8iNUJ for ; Fri, 11 May 2012 08:55:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F309321F860B for ; Fri, 11 May 2012 08:55:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7bc5ae00000796a-3e-4fad3656be26 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 04.AF.31082.6563DAF4; Fri, 11 May 2012 17:55:02 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.194]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 11 May 2012 17:55:02 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Justin Uberti Date: Fri, 11 May 2012 17:54:56 +0200 Thread-Topic: [rtcweb] New use-case proposed Thread-Index: Ac0vjmx/cxRxMTw4QsKZ1WK8SoN0tQ== Message-ID: <6D61C99C-B236-4B9B-AF59-5C6A074059F0@ericsson.com> References: <4FAD0D8C.7020701@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:55:05 -0000 DQoNCjExIG1haiAyMDEyIGtsLiAxNjoyNCBza3JldiAiSnVzdGluIFViZXJ0aSIgPGp1YmVydGlA Z29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj46DQoNClNSVFAgZW5jcnlwdGlv biBpcyBjaGVhcCwgcHJhY3RpY2FsbHkgZnJlZSBvbiB0b2RheSdzIENQVXMuIEkgYWdyZWUgd2l0 aCB0aGUgZ2VuZXJhbCB1c2UgY2FzZSBidXQgSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBjb25jbHVz aW9uIHRoYXQgd2UgbmVlZCB0byByZXF1aXJlIHRoYXQgdGhlIG1pZGRsZWJveCBkb2VzIG5vdCBy ZXdyaXRlIHBhY2tldHMgb3IgcGVyZm9ybSBjcnlwdG8sIG1haW5seSBzaW5jZSBpdCB3aWxsIGlu Y3JlYXNlIHN5c3RlbSBjb21wbGV4aXR5IChhbmQgdGhlIHN5c3RlbSBpcyBhbHJlYWR5IHF1aXRl IGNvbXBsZXgpLg0KDQoNCkp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCBZb3VyIHBvaW50 LSB3aGljaCBzeXN0ZW0gYXJlIFUgcmVmZXJyaW5nIHRvOiB0aGUgYnJvd3NlciBVQTsgdGhlIG1l ZGlhIHByb2Nlc3Npbmcgc3VwcG9ydCBub2RlIG9yIHRoZSB3aG9sZSBsb3Q/DQoNClJlZ2FyZHMN CkfDtnJhbg0KDQoNCg0KT24gRnJpLCBNYXkgMTEsIDIwMTIgYXQgOTowMSBBTSwgU3RlZmFuIEhh a2Fuc3NvbiBMSyA8c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOnN0ZWZh bi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpJJ3ZlIGJlZW4gc2tldGNoaW5n IG9uIGEgbmV3IHVzZS1jYXNlLiBUaGUgdXNlLWNhc2UgaXMgaW50ZW5kZWQgdG8NCmRlcml2ZSBy ZXF1aXJlbWVudHMgdGhhdCBlbmFibGUgbG93IGNvbXBsZXggY2VudHJhbCBub2RlcyBmb3IgbXVs dGkNCnBhcnR5IHNlc3Npb25zLCB3aGljaCBpbiB0dXJuIGxlYWRzIHRvIHJlcXVpcmVtZW50cyBy ZWdhcmRpbmcNCihlc3NlbnRpYWxseSkga2V5aW5nIHNvbHV0aW9uIGZvciBTUlRQIGFuZCB0aGUg cG9zc2liaWxpdHkgZm9yIHRoZSBhcHANCnRvIGNvbnRyb2wvc2V0IHRoaW5ncyBpbiB0aGUgbWVk aWEgY29uZmlndXJhdGlvbiAoaW4gb3RoZXIgd29yZHMsIGZvciBKU0VQKToNCg0KDQpNdWx0aS1w YXJ0eSB3aXRoIGxvdyBjb21wbGV4aXR5IGNlbnRyYWwgbm9kZQ0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpBIGdlb2dyYXBoaWNhbGx5IHNwcmVhZCAo Y2hhcml0eSwgbm9uLXByb2ZpdCwgc2Nob29sKSBvcmdhbml6YXRpb24NCm9mZmVycyBpdHMgbWVt YmVycyBtdWx0aS1wYXJ0eSB2aWRlbyBjb21tdW5pY2F0aW9uIHZpYSBhIHNoYXJlZCB2aXJ0dWFs DQpyb29tIHRoYXQgcGFydGljaXBhbnRzIGNhbiBlbnRlciBhbmQgbGVhdmUgYXQgYW55IHRpbWUu IEF0IHRpbWVzIHRoZXJlDQphcmUgbWFueSBwZXJzb25zIGluIHRoZSB2aXJ0dWFsIHJvb20gKDIw KyksIGF0IG90aGVyIHRpbWVzIHZlcnkgZmV3DQooMy01LCBvciBldmVuIDAtMSkuDQoNClRoZSBh cHBsaWNhdGlvbiB3aWxsIGNvbnRyb2wgaWYgZmV3IHBhcnRpY2lwYW50cyAoYSBzdWJzZXQpIGFy ZSBzaG93biBhdA0KYSBoaWdoZXIgZmlkZWxpdHkgb3IgaWYgbWFueSAoYWxsKSBhcmUgc2hvd24g YXQgYSBsb3dlciBmaWRlbGl0eSBvciBhDQptaXggb2Ygc29tZSBmZXcgYXQgaGlnaCBmaWRlbGl0 eSBhbmQgdGhlIHJlc3QgYXQgbXVjaCBsb3dlciBmaWRlbGl0eQ0KZ2l2ZW4gdGhlIGV4aXN0aW5n IGJhbmR3aWR0aCBsaW1pdGF0aW9ucyBiZXR3ZWVuIHBhcnRpY2lwYW50cy4NCg0KU2luY2UgdGhl cmUgYXJlIGF0IHRpbWVzIG1hbnkgcGVyc29ucyBpbiB0aGUgdmlydHVhbCByb29tLCBpdCBpcyBu b3QNCmZlYXNpYmxlIHRvIHNldCB1cCBhIG1lc2guIFRoZSBiYW5kd2lkdGggbmVlZGVkIGJ5IGEg cGFydGljaXBhbnQgZXhjZWVkcw0Kd2hhdCBtYW55IG1lbWJlcnMgaGF2ZSBhY2Nlc3MgdG8sIGVz cGVjaWFsbHkgaW4gdGhlaXIgdXBsaW5rcywgc28NCmluc3RlYWQgYSBjZW50cmFsIG1lZGlhIG5v ZGUgaXMgZGVwbG95ZWQuIEluIGFkZGl0aW9uLCB0aGUgb3JnYW5pemF0aW9uDQpkb2VzIG5vdCBo YXZlIGFjY2VzcyB0byBtdWNoIGZ1bmRzLCBidXQgaGFzIHRvIHJlbHkgb24gY2hlYXAgaGFyZHdh cmUNCihvZnRlbiBkb25hdGVkKSBvcGVyYXRlZCBieSB2b2x1bnRlZXJzLg0KDQogRnJvbSB0aGlz IHVzZS1jYXNlIGEgaGlnaCBsZXZlbCByZXF1aXJlbWVudCBzYXlpbmcgc29tZXRoaW5nIGxpa2UN Cg0KIkl0IG11c3QgYmUgcG9zc2libGUgdG8gc2V0IHVwIG1lZGlhIHN0cmVhbXMgYW5kIGVuY3J5 cHRpb24gaW4gc3VjaA0KYSB3YXkgdGhhdCBwcm9jZXNzaW5nIGluIGEgY2VudHJhbCBub2RlIGlz IG1pbmltaXplZCAobm8gdHJhbnNjb2RpbmcNCnJlcXVpcmVkLCBubyBSVFAgcGFja2V0IHJld3Jp dGluZywgbm8gZGVjcnlwdGlvbi9yZS1lbmNyeXB0aW9uIGZvciBldmVyeQ0Kb3V0Z29pbmcgZmxv dyAtIGp1c3Qgc2ltcGxlIGZvcndhcmRpbmcpLiINCg0KY2FuIGJlIGRlcml2ZWQuIFRoaXMgY2Fu IGluIHR1cm4gYmUgYnJva2VuIGRvd24gaW50byBtb3JlIGRldGFpbGVkDQpyZXF1aXJlbWVudHMg c3VjaCBhczoNCg0KLSBUaGUga2V5aW5nIHNvbHV0aW9uIG11c3QgYWxsb3cgZWFjaCBwYXJ0aWNp cGFudHMgdG8gZW5jcnlwdCB0bw0KbXVsdGlwbGUgcmVjZWl2ZXJzIHdpdGhvdXQgYW55IGRlY3J5 cHRpb24rZW5jcnlwdGlvbiBpbiB0aGUgbWlkZGxlIG5vZGUNCg0KLSBSVFAgc2Vzc2lvbnMgdGhh dCBoYXZlIFNTUkNzIGZyb20gbXVsdGlwbGUgUGVlckNvbm5lY3Rpb25zIGJlaW5nDQppbnRlcmNv bm5ldGVkIG11c3QgYmUgc3VwcG9ydGVkLiBGcm9tIGEgZ2l2ZW4gZW5kLXBvaW50IGFsbCBTU1JD cyB3aWxsDQpjb21lIG92ZXIgb25lIFBDLCBidXQgdGhlIGZ1bGwgcGF0aCB3aWxsIGJlIGRpZmZl cmVudCB0b3dhcmRzIGRpZmZlcmVudA0Kc2V0cyBvZiBTU1JDcy4NCg0KLSBTaWduYWxsaW5nIG11 c3QgYmUgY2FwYWJsZSBvZiBlc3RhYmxpc2hpbmcgYSBjb21tb24gc2V0IG9mIHJlY2VpdmVyDQpj b25maWd1cmF0aW9ucyBvdmVyIGFsbCBwYXJ0aWNpcGFudHMuDQoNCi0gVGhlIEFQSSBtdXN0IGFs bG93IGZvciB0aGUgYWJvdmUsIGkuZS46DQotLSBUaGUgYXBwIG11c3QgYmUgYWJsZSB0byBjaG9z ZSBhIGtleWluZyBzb2x1dGlvbiB0aGF0IGVuYWJsZXMNCmVuY3J5cHRpb24gdG8gbXVsdGlwbGUg cmVjZWl2ZXJzIChpZiB0aGUgYXBwIGNhbiBoYXZlIGFueSBjb250cm9sIG92ZXINCmtleWluZyBt ZXRob2QgdXNlZCkNCi0tIFRoZSBhcHAgbXVzdCBiZSBhYmxlIHRvIGNvbnRyb2wgU1NSQ3MgdG8g dXNlIGZvciBvdXRnb2luZyBzdHJlYW1zDQotLSBUaGUgYXBwIG11c3QgYmUgYWJsZSB0byBjb250 cm9sIHRoZSByZWNlaXZlciBjb25maWd1cmF0aW9uIHRoZQ0KYnJvd3NlciB1c2VzDQoNCklzIHRo aXMgc29tZXRoaW5nIHdlIHNob3VsZCBjb25zaWRlciBhZGRpbmcgdG8gdGhlIHVzZS1jYXNlIGRv Y3VtZW50Pw0KDQpCciwNClN0ZWZhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From harald@alvestrand.no Fri May 11 09:21:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E321F85A8 for ; Fri, 11 May 2012 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 LvvOZYaTiNdv for ; Fri, 11 May 2012 09:21:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1181F21F859A for ; Fri, 11 May 2012 09:21:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27DAF39E132; Fri, 11 May 2012 18:21:22 +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 rYN158wB4e3F; Fri, 11 May 2012 18:21:21 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7681139E062; Fri, 11 May 2012 18:21:21 +0200 (CEST) Message-ID: <4FAD3C87.8080908@alvestrand.no> Date: Fri, 11 May 2012 18:21:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stefan Hakansson LK References: <4FAD0D8C.7020701@ericsson.com> In-Reply-To: <4FAD0D8C.7020701@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 16:21:24 -0000 I propose to reject this use case because it requires yet another security redesign. The clue is here: > > - The keying solution must allow each participants to encrypt to > multiple receivers without any decryption+encryption in the middle node > This means that each participant must use the same encryption keys to all other participants; this in turn means that when someone leaves the group, all participants must change their encryption keys; it also means that as long as shared keys are used for authentication, all participants can impersonate all other participants. In fact, this solution has most of the issues (except for the network layer deployment issue) that leads me to strongly advocate leaving multicast out of scope for this effort. Harald From roman@telurix.com Fri May 11 09:26:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254F21F86BA for ; Fri, 11 May 2012 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.757, 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 1l4UaLYc8W7Z for ; Fri, 11 May 2012 09:26:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55FE921F86B8 for ; Fri, 11 May 2012 09:26:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3656124pbc.31 for ; Fri, 11 May 2012 09:26: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Vxz0QkiwQf+TpRNOSIG35qknbUK2L2o13wyiwyOgNK4=; b=RyO/73y6o3Cz7Hbn/l+bY3eeSSrtg9/cDih61LjMYKEu1DVXWK4fX+R9TioFH4054o uYmUhAyI90CXmBk2uekK+q8bJcnMGPvayLJVGzaFLkP2BcGPdCc8mKan3YQkp1XgwZpP VX7azwaf81CEjlRjwRnYItmBweYDUD01oXLdV9zQnqEkYcBFN3ZRZ2ucE0kxGZEj0ghC RFMmrrVeAMpgVrTADWR5xMV24iOa1CRzdwapJNTMaeRCaf4JmDTHT8oHQM8hzWUI0dc9 CkZ3EgJhBBDPNcMa/E4nDScU9v2OZ5ihJ9hKS8e7cEdp6TQGAPQrawWbxnNeInlWuYmJ RnAg== Received: by 10.68.132.103 with SMTP id ot7mr12422933pbb.59.1336753585985; Fri, 11 May 2012 09:26:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id u5sm13211108pbu.76.2012.05.11.09.26.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 09:26:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3656082pbc.31 for ; Fri, 11 May 2012 09:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.99 with SMTP id rr3mr33012137pbc.48.1336753584460; Fri, 11 May 2012 09:26:24 -0700 (PDT) Received: by 10.68.129.161 with HTTP; Fri, 11 May 2012 09:26:24 -0700 (PDT) In-Reply-To: <4FAD3C87.8080908@alvestrand.no> References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> Date: Fri, 11 May 2012 12:26:24 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8ff2445b8dd38104bfc5329b X-Gm-Message-State: ALoCoQm/fL79n0WCGHvycR8hAr5AoPX7pFSCtnJbXzN33IulIahj4fKSBoCr4rCewUvXVOIrPiD5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 16:26:26 -0000 --e89a8ff2445b8dd38104bfc5329b Content-Type: text/plain; charset=ISO-8859-1 +1 I have provided the CPU requirements for doing SRTP re-encryption before. Bottom line, on the real conferencing service encryption adds about 10% extra CPU load. There is no benefit in compromising security to avoid re-encrypting. _____________ Roman Shpount On Fri, May 11, 2012 at 12:21 PM, Harald Alvestrand wrote: > I propose to reject this use case because it requires yet another security > redesign. > The clue is here: > > >> - The keying solution must allow each participants to encrypt to >> multiple receivers without any decryption+encryption in the middle node >> >> > This means that each participant must use the same encryption keys to all > other participants; this in turn means that when someone leaves the group, > all participants must change their encryption keys; it also means that as > long as shared keys are used for authentication, all participants can > impersonate all other participants. > > In fact, this solution has most of the issues (except for the network > layer deployment issue) that leads me to strongly advocate leaving > multicast out of scope for this effort. > > Harald > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8ff2445b8dd38104bfc5329b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

I have provided the CPU requirements for doing SRTP re-encryption= before. Bottom line, on the real conferencing service encryption adds abou= t 10% extra CPU load. There is no benefit in compromising security to avoid= re-encrypting.
_____________
Roman Shpount


On Fri, May 11, 2012 at 12:21 PM, Harald= Alvestrand <harald@alvestrand.no> wrote:
I propose to reject this use case because it requires yet another security = redesign.
The clue is here:


- The keying solution must allow each participants to encrypt to
multiple receivers without any decryption+encryption in the middle node


This means that each participant must use the same encryption keys to all o= ther participants; this in turn means that when someone leaves the group, a= ll participants must change their encryption keys; it also means that as lo= ng as shared keys are used for authentication, all participants can imperso= nate all other participants.

In fact, this solution has most of the issues (except for the network layer= deployment issue) that leads me to strongly advocate leaving multicast out= of scope for this effort.

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


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

--e89a8ff2445b8dd38104bfc5329b-- From goran.ap.eriksson@ericsson.com Fri May 11 09:38:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73721F867F for ; Fri, 11 May 2012 09:38:39 -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 DzAdwT7AtWi7 for ; Fri, 11 May 2012 09:38:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C69B321F867E for ; Fri, 11 May 2012 09:38:38 -0700 (PDT) X-AuditID: c1b4fb25-b7b48ae0000025b3-b8-4fad408df003 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 26.53.09651.D804DAF4; Fri, 11 May 2012 18:38:37 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.194]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 11 May 2012 18:38:37 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Harald Alvestrand Date: Fri, 11 May 2012 18:38:35 +0200 Thread-Topic: [rtcweb] New use-case proposed Thread-Index: Ac0vlINfol5UUhs7QYSA0X5ahZS7KA== Message-ID: <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> In-Reply-To: <4FAD3C87.8080908@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 16:38:39 -0000 DQoNCjExIG1haiAyMDEyIGtsLiAxODoyMSBza3JldiAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJh bGRAYWx2ZXN0cmFuZC5ubz46DQoNCj4gSSBwcm9wb3NlIHRvIHJlamVjdCB0aGlzIHVzZSBjYXNl IGJlY2F1c2UgaXQgcmVxdWlyZXMgeWV0IGFub3RoZXIgDQo+IHNlY3VyaXR5IHJlZGVzaWduLg0K PiBUaGUgY2x1ZSBpcyBoZXJlOg0KPiANCj4+IA0KPj4gLSBUaGUga2V5aW5nIHNvbHV0aW9uIG11 c3QgYWxsb3cgZWFjaCBwYXJ0aWNpcGFudHMgdG8gZW5jcnlwdCB0bw0KPj4gbXVsdGlwbGUgcmVj ZWl2ZXJzIHdpdGhvdXQgYW55IGRlY3J5cHRpb24rZW5jcnlwdGlvbiBpbiB0aGUgbWlkZGxlIG5v ZGUNCj4+IA0KPiANCj4gVGhpcyBtZWFucyB0aGF0IGVhY2ggcGFydGljaXBhbnQgbXVzdCB1c2Ug dGhlIHNhbWUgZW5jcnlwdGlvbiBrZXlzIHRvIA0KPiBhbGwgb3RoZXIgcGFydGljaXBhbnRzOyB0 aGlzIGluIHR1cm4gbWVhbnMgdGhhdCB3aGVuIHNvbWVvbmUgbGVhdmVzIHRoZSANCj4gZ3JvdXAs IGFsbCBwYXJ0aWNpcGFudHMgbXVzdCBjaGFuZ2UgdGhlaXIgZW5jcnlwdGlvbiBrZXlzOyBpdCBh bHNvIG1lYW5zIA0KPiB0aGF0IGFzIGxvbmcgYXMgc2hhcmVkIGtleXMgYXJlIHVzZWQgZm9yIGF1 dGhlbnRpY2F0aW9uLCBhbGwgDQo+IHBhcnRpY2lwYW50cyBjYW4gaW1wZXJzb25hdGUgYWxsIG90 aGVyIHBhcnRpY2lwYW50cy4NCj4gDQo+IEluIGZhY3QsIHRoaXMgc29sdXRpb24gaGFzIG1vc3Qg b2YgdGhlIGlzc3VlcyAoZXhjZXB0IGZvciB0aGUgbmV0d29yayANCj4gbGF5ZXIgZGVwbG95bWVu dCBpc3N1ZSkgdGhhdCBsZWFkcyBtZSB0byBzdHJvbmdseSBhZHZvY2F0ZSBsZWF2aW5nIA0KPiBt dWx0aWNhc3Qgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGVmZm9ydC4NCg0KWW91IG1lYW4gZm9yIHRo aXMgcGhhc2Ugb2Ygd2VicnRjIHN0ZCBlZmZvcnRzIG9yIGZvciBldmVyPw0KDQpSZWdhcmRzDQpH w7ZyYW4NCg0KDQo+IA0KPiAgICAgICAgICAgICAgICBIYXJhbGQNCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGlu ZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYg0K From randell-ietf@jesup.org Fri May 11 09:42:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1E721F85FD for ; Fri, 11 May 2012 09:42:50 -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.206, 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 OmS-McycUCaD for ; Fri, 11 May 2012 09:42:49 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CE6FD21F8517 for ; Fri, 11 May 2012 09:42:48 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SSsvY-0007TM-2C for rtcweb@ietf.org; Fri, 11 May 2012 11:42:48 -0500 Message-ID: <4FAD413A.30200@jesup.org> Date: Fri, 11 May 2012 12:41:30 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> In-Reply-To: <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 16:42:50 -0000 On 5/10/2012 6:47 PM, Cullen Jennings wrote: > On May 10, 2012, at 3:07 PM, Martin Thomson wrote: > >> On 10 May 2012 13:56, Cullen Jennings wrote: >>> I was looking more for the actually sort of end user use case where this might happen. >> I ring you. >> Your mobile and home phone both ring. >> You answer your mobile, your daughter answers the home phone. >> I get to talk to both of you. >> >> Of course, that's not such a great outcome. I can hear both of you, >> but you can't hear each other unless I have really bad echo >> cancellation. >> >> I tend to think of this as solving a really interesting signaling >> problem that doesn't really have any practical application. If you >> want to talk to both people, then you should signal the creation of a >> conference call. >> >> --Martin > That an good use cases, except the people need to be able to hear each other. It gets called lots of things but some PBXs call it bridged line appearance. Variation of it have been discussed in bliss and draft-ietf-bliss-shared-appearances. It really comes down to where you think the conferencing should happen. If it does not happened on the the callers phone, seems like existing jsep idea should be able to do this. (given the callee is the phone that is most likely out of administrative control of the other two phones that set up bridged line a appearance, assuming that phone can and is willing to do the conferencing seems like a bad architecture for this problem). Again lot of systems do this today in SIP and seem to do it without needing forcing the callers phones to deal with multiple simultaneous calls signaled in some way I don't even know how to signal in SIP. I'll note I've built systems that simply handle in-phone conferencing; while there are some annoyances it's most certainly doable. If the caller acts as the MCU you get OWD1+jitter+etc+encode+OWD2 (OWD=one-way-delay) between the two leaf nodes (though this is no different than a normal conference). Or your app, after the initial second answer tells the second answerer to invite the first into a mesh conference, if that works - and it may not, so you need to mix or forward if you want a conference. (Forwarding the RTP traffic works at the cost of bandwidth and complexity, but simpler media processing and less leaf-to-leaf delay.) If this *is* already a mesh conference you've joined (different usecase than above), no mixing or forwarding is needed - you render all the streams, and you send media to all the answerers. This is exactly what you want. However, if two people answer, you do not have to have a conference. First of all, the devices rtcweb is intended for generally have enough UI available that the user can manage multiple sessions reasonably, unlike POTS-type phones. You can handle it much like a call-waiting scenario, though the second answerer might be confused unless you send some sort of hold/please-wait message (which, this not being POTS devices, you can). In other cases/applications, the answers may be automated, and the channels may not be used immediately - think the VR example, where your OFFER is forwarded to any person who comes in "hearing" range, enters the room, whatever. This may be a form of partial-mesh conference managed by the server. These channels may be opened before they're actually needed in order to hide setup delay. My point is to show that the possible uses of parallel forking exist, and don't always map to SIP or to classic telephony. If cloning is supported, then these scenarios work. I'm open to alternative proposals that cover this class of use-cases, if they make either "standard" apps simpler to a worthwhile degree, or if they make the implementation of webrtc itself noticably simpler, while still making these uses possible. Alternatives may have downsides in some cases, in extra call setup delay/clipping or requiring re-invites or requiring special application protocols to request a offerer send a new invite, and added complexity to apps that wish to handle this. -- Randell Jesup randell-ietf@jesup.org From Henry.Lum@genesyslab.com Fri May 11 10:26:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0C21F86BD for ; Fri, 11 May 2012 10:26:58 -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.433, 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 dHvlsuLcIBTo for ; Fri, 11 May 2012 10:26:57 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 786C321F86A0 for ; Fri, 11 May 2012 10:26:57 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q4BHQpj6009895; Fri, 11 May 2012 10:26:51 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 10:26:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2F9B.409B1582" Date: Fri, 11 May 2012 10:26:30 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74087F7090@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] New use-case proposed Thread-Index: Ac0vktJlEshr9v/oTQmFzvYLBTcEywAB5w9A References: <4FAD0D8C.7020701@ericsson.com><4FAD3C87.8080908@alvestrand.no> From: "Henry Lum" To: "Roman Shpount" , "Harald Alvestrand" X-OriginalArrivalTime: 11 May 2012 17:26:51.0813 (UTC) FILETIME=[40DACD50:01CD2F9B] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:26:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2F9B.409B1582 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree as well since based on our testing for a simple media bridge that SRTP re-encryption adds a similar amount of CPU load (around 10%).=20 =20 Henry =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: May-11-12 12:26 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed =20 +1 I have provided the CPU requirements for doing SRTP re-encryption before. Bottom line, on the real conferencing service encryption adds about 10% extra CPU load. There is no benefit in compromising security to avoid re-encrypting. _____________ Roman Shpount On Fri, May 11, 2012 at 12:21 PM, Harald Alvestrand wrote: I propose to reject this use case because it requires yet another security redesign. The clue is here: - The keying solution must allow each participants to encrypt to multiple receivers without any decryption+encryption in the middle node This means that each participant must use the same encryption keys to all other participants; this in turn means that when someone leaves the group, all participants must change their encryption keys; it also means that as long as shared keys are used for authentication, all participants can impersonate all other participants. In fact, this solution has most of the issues (except for the network layer deployment issue) that leads me to strongly advocate leaving multicast out of scope for this effort. Harald _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CD2F9B.409B1582 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree as well since based on our testing for a simple = media bridge that SRTP re-encryption adds a similar amount of CPU load (around = 10%).

 

Henry

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: May-11-12 12:26 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New use-case proposed

 

+1

I have provided the CPU requirements for doing SRTP re-encryption = before. Bottom line, on the real conferencing service encryption adds about 10% = extra CPU load. There is no benefit in compromising security to avoid = re-encrypting.
_____________
Roman Shpount

On Fri, May 11, 2012 at 12:21 PM, Harald Alvestrand = <harald@alvestrand.no> wrote:

I propose to reject = this use case because it requires yet another security redesign.
The clue is here:


- The keying solution must allow each participants to encrypt to
multiple receivers without any decryption+encryption in the middle = node


This means that each participant must use the same encryption keys to = all other participants; this in turn means that when someone leaves the group, all participants must change their encryption keys; it also means that as = long as shared keys are used for authentication, all participants can = impersonate all other participants.

In fact, this solution has most of the issues (except for the network = layer deployment issue) that leads me to strongly advocate leaving multicast = out of scope for this effort.

              Harald


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

 

------_=_NextPart_001_01CD2F9B.409B1582-- From vsemanic@yahoo.com Fri May 11 13:00:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6821F8735 for ; Fri, 11 May 2012 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 IqcY84deCpvP for ; Fri, 11 May 2012 13:00:33 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfa.amsl.com (Postfix) with SMTP id 410B121F872E for ; Fri, 11 May 2012 13:00:33 -0700 (PDT) Received: from [98.139.91.64] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 11 May 2012 20:00:29 -0000 Received: from [98.139.91.57] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 11 May 2012 20:00:29 -0000 Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 11 May 2012 20:00:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 820427.36158.bm@omp1057.mail.sp2.yahoo.com Received: (qmail 73852 invoked by uid 60001); 11 May 2012 20:00:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1336766429; bh=utPpb0hMm5ZlREDVqlH9vsopzoEK/JTMqb8QLs502cc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=CpsIgx6iOyX2BktpWLTvDKODq0yJu2wVdnNyNklyP6ZwK1IjGEbS/am9vYGW2KxjlOuet+0TYC0CN/XZFeZa7qiVNHMblXjr0H1iObzJpnjhwZhSP3oWWeyfqF+4ym5m6CQ38r57FJwkpsWBeaB8Lnc+homIoOtKJ7zeSWVJ4Io= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=y6JhtzVnA4a0thOhB4pSHUHlqt5fGxwkVZCbtLKRv1V54WzWMQLLYwcvwxUCSYp+2QJnMK5gD3ifHntTt2VzMkFKl96RmnikCppZTQpBNLi5XLpgHETpqC+Fb7kEToh1dyZkqPYtInmCHFvwX+k10h31xL2zBccP0DFw3usywEI=; X-YMail-OSG: 4vwxNEEVM1lrqMbiPCWkc8ShNOBwENt69x5B4xm8hL5zxhX rYhOnvK5_SGF8QKIypw4yNdgGfociwt_wJp5oouuMd5vjxxFXy2OkDF.1VLg _FjaYq5oSfgew.jvKvPJdribwm0QUV27gPDfJ97e063wAXIApve3KK9Aevcz utsjFnAFxPiUxKLnSY.PSvCiT1RdI.TnfxTz9iNkolDvFVEdKzjuirlo8drm 1pULBQvT7Kx8m8JaU82EHZmyJL6PXr5j4ujS2Yh2zKQBwx6Vr61SKnPv7sJx K8ZhM7PMX9sVKjJUU5knryMYhQjYPC76ReCBrzCJgiXFSsPIQj_M3XBbJ_fs 65hTlTBEXg5MSiWbytbheSx.A0ifQ6Hy6GfCNNiUx.Q3Wl7vU15NK Received: from [135.245.10.6] by web45005.mail.sp1.yahoo.com via HTTP; Fri, 11 May 2012 13:00:28 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1336766428.73026.YahooMailClassic@web45005.mail.sp1.yahoo.com> Date: Fri, 11 May 2012 13:00:28 -0700 (PDT) From: Victor Semanic To: fluffy@iii.ca MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:00:34 -0000 >> Let's say a standard SIP proxy (call it opensips for specificity) >> placing a forked call to two ICE enabled IP phones. Both phones answer >> with 200 OK. > With a standard SIP proxy, only one of the 200 would be sent back to the > web browser. No, I do not think that is the case. RFC 6026 modified parts of RFC 3261, but the part that says that a proxy MUST sent multiple 2xx responses to INVITE was kept as-is. Specifically, RFC 6026 does not modify the behaviour of RFC 3261, Section 16.7, Step 5 that says: After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request If I am misreading the specification, please let me know. From richard.ejzak@alcatel-lucent.com Fri May 11 13:19:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4590D21F8739 for ; Fri, 11 May 2012 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 DC4mPY1eLMDU for ; Fri, 11 May 2012 13:19:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B002B21F8716 for ; Fri, 11 May 2012 13:19:27 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4BKJQlE028270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 May 2012 15:19:27 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BKJQIK027691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 11 May 2012 15:19:26 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 11 May 2012 15:19:26 -0500 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Date: Fri, 11 May 2012 15:19:25 -0500 Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0vh2JWI2I2SnrgQPiDqAUzhcRMHQAKXZnQ Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1136D546AFC@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4400! 1 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6BF70DE5-5C59-4B64-BAFC-394E7BBF9442@belltower.co.uk> In-Reply-To: <6BF70DE5-5C59-4B64-BAFC-394E7BBF9442@belltower.co.uk> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:19:28 -0000 Neil, That's the point. This discussion is with reference to parallel forking. = To avoid clipping, you need to establish the media channels with the regist= ered targets before they are alerted because you don't know which one will = answer. This requires MediaConnection cloning so you can properly support = parallel forking and do ICE and DTLS with each target in parallel before 20= 0 OK from one of the targets. Delaying delivery of answer indication to th= e caller (as you seem to imply) does not help. Richard -----Original Message----- From: Neil Stratford [mailto:neils@vipadia.com] On Behalf Of Neil Stratford Sent: Friday, May 11, 2012 10:05 AM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote: > But things are different with ICE and DTLS, particularly if you want to a= void media intermediaries. Significant clipping is a real possibility if w= e have to restart ICE/DTLS after the "winner" responds with 200 OK. >=20 > This is not a separate use case, but a given aspect of interworking with = SIP. The whole problem of clipping audio due to the delay between the 200OK and = the media actually flowing raises a flag that we are triggering upper layer= s of the stack on the wrong event.=20 Why is anyone sending media before the media channel is fully established? = Why tell the user (or IVR etc) that the call is answered before we have a w= orking media channel? Neil From harald@alvestrand.no Fri May 11 13:52:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F389921F84D9 for ; Fri, 11 May 2012 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 a0zcf5q1JR0r for ; Fri, 11 May 2012 13:52:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65AC121F84CE for ; Fri, 11 May 2012 13:52:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE51639E0F0; Fri, 11 May 2012 22:52:18 +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 ACHCGkG0hdKu; Fri, 11 May 2012 22:52:18 +0200 (CEST) Received: from [172.28.90.185] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 94E6E39E062; Fri, 11 May 2012 22:52:17 +0200 (CEST) Message-ID: <4FAD7BFE.10905@alvestrand.no> Date: Fri, 11 May 2012 22:52:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> In-Reply-To: <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:52:20 -0000 On 05/11/2012 06:38 PM, Göran Eriksson AP wrote: > > 11 maj 2012 kl. 18:21 skrev "Harald Alvestrand": > >> I propose to reject this use case because it requires yet another >> security redesign. >> The clue is here: >> >>> - The keying solution must allow each participants to encrypt to >>> multiple receivers without any decryption+encryption in the middle node >>> >> This means that each participant must use the same encryption keys to >> all other participants; this in turn means that when someone leaves the >> group, all participants must change their encryption keys; it also means >> that as long as shared keys are used for authentication, all >> participants can impersonate all other participants. >> >> In fact, this solution has most of the issues (except for the network >> layer deployment issue) that leads me to strongly advocate leaving >> multicast out of scope for this effort. > You mean for this phase of webrtc std efforts or for ever? Until we've got an usage scenario with a deployment story that I find credible. The point I'm pretty vehement on - that lack of multicast support should not be a blocker for finalizing the specs we are working on. Harald From goran.ap.eriksson@ericsson.com Fri May 11 14:31:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B336321F86EE for ; Fri, 11 May 2012 14:31:27 -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 37agggA1Rn-E for ; Fri, 11 May 2012 14:31:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EAA5F21F86CB for ; Fri, 11 May 2012 14:31:26 -0700 (PDT) X-AuditID: c1b4fb30-b7c05ae000003df9-db-4fad852ddf48 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B9.B6.15865.D258DAF4; Fri, 11 May 2012 23:31:25 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.194]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 11 May 2012 23:31:25 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Harald Alvestrand Date: Fri, 11 May 2012 23:31:22 +0200 Thread-Topic: [rtcweb] New use-case proposed Thread-Index: Ac0vvWr2RMlfyETUSsq4H1UYYNfseQ== Message-ID: <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> In-Reply-To: <4FAD7BFE.10905@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:31:27 -0000 DQoNCjExIG1haiAyMDEyIGtsLiAyMjo1MiBza3JldiAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJh bGRAYWx2ZXN0cmFuZC5ubz46DQoNCj4gT24gMDUvMTEvMjAxMiAwNjozOCBQTSwgR8O2cmFuIEVy aWtzc29uIEFQIHdyb3RlOg0KPj4gDQo+PiAxMSBtYWogMjAxMiBrbC4gMTg6MjEgc2tyZXYgIkhh cmFsZCBBbHZlc3RyYW5kIjxoYXJhbGRAYWx2ZXN0cmFuZC5ubz46DQo+PiANCj4+PiBJIHByb3Bv c2UgdG8gcmVqZWN0IHRoaXMgdXNlIGNhc2UgYmVjYXVzZSBpdCByZXF1aXJlcyB5ZXQgYW5vdGhl cg0KPj4+IHNlY3VyaXR5IHJlZGVzaWduLg0KPj4+IFRoZSBjbHVlIGlzIGhlcmU6DQo+Pj4gDQo+ Pj4+IC0gVGhlIGtleWluZyBzb2x1dGlvbiBtdXN0IGFsbG93IGVhY2ggcGFydGljaXBhbnRzIHRv IGVuY3J5cHQgdG8NCj4+Pj4gbXVsdGlwbGUgcmVjZWl2ZXJzIHdpdGhvdXQgYW55IGRlY3J5cHRp b24rZW5jcnlwdGlvbiBpbiB0aGUgbWlkZGxlIG5vZGUNCj4+Pj4gDQo+Pj4gVGhpcyBtZWFucyB0 aGF0IGVhY2ggcGFydGljaXBhbnQgbXVzdCB1c2UgdGhlIHNhbWUgZW5jcnlwdGlvbiBrZXlzIHRv DQo+Pj4gYWxsIG90aGVyIHBhcnRpY2lwYW50czsgdGhpcyBpbiB0dXJuIG1lYW5zIHRoYXQgd2hl biBzb21lb25lIGxlYXZlcyB0aGUNCj4+PiBncm91cCwgYWxsIHBhcnRpY2lwYW50cyBtdXN0IGNo YW5nZSB0aGVpciBlbmNyeXB0aW9uIGtleXM7IGl0IGFsc28gbWVhbnMNCj4+PiB0aGF0IGFzIGxv bmcgYXMgc2hhcmVkIGtleXMgYXJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uLCBhbGwNCj4+PiBw YXJ0aWNpcGFudHMgY2FuIGltcGVyc29uYXRlIGFsbCBvdGhlciBwYXJ0aWNpcGFudHMuDQo+Pj4g DQo+Pj4gSW4gZmFjdCwgdGhpcyBzb2x1dGlvbiBoYXMgbW9zdCBvZiB0aGUgaXNzdWVzIChleGNl cHQgZm9yIHRoZSBuZXR3b3JrDQo+Pj4gbGF5ZXIgZGVwbG95bWVudCBpc3N1ZSkgdGhhdCBsZWFk cyBtZSB0byBzdHJvbmdseSBhZHZvY2F0ZSBsZWF2aW5nDQo+Pj4gbXVsdGljYXN0IG91dCBvZiBz Y29wZSBmb3IgdGhpcyBlZmZvcnQuDQo+PiBZb3UgbWVhbiBmb3IgdGhpcyBwaGFzZSBvZiB3ZWJy dGMgc3RkIGVmZm9ydHMgb3IgZm9yIGV2ZXI/DQo+IFVudGlsIHdlJ3ZlIGdvdCBhbiB1c2FnZSBz Y2VuYXJpbyB3aXRoIGEgZGVwbG95bWVudCBzdG9yeSB0aGF0IEkgZmluZCANCj4gY3JlZGlibGUu DQo+IA0KPiBUaGUgcG9pbnQgSSdtIHByZXR0eSB2ZWhlbWVudCBvbiAtIHRoYXQgbGFjayBvZiBt dWx0aWNhc3Qgc3VwcG9ydCBzaG91bGQgDQo+IG5vdCBiZSBhIGJsb2NrZXIgZm9yIGZpbmFsaXpp bmcgdGhlIHNwZWNzIHdlIGFyZSB3b3JraW5nIG9uLg0KPiANCg0KSSBhbSBwcmV0dHkgc2Vuc2l0 aXZlIHRvIHN1Y2ggY29uc2VxdWVuY2UgYXMgd2VsbCEgSGF2aW5nIHNhaWQgdGhhdCwgZW5hYmxp bmcgaW5ub3ZhdGlvbiBpbiB0aGlzIGtpbmQgb2YgYXBwbGljYXRpb24gY2F0ZWdvcnkgaXMgaW1w b3J0YW50ICBmb3IgdGhlIGxvbmcgdGVybSBldm9sdXRpb24gb2YgdGhlIHdlYiBwbGF0Zm9ybS4N Cg0KUGVyc29uYWxseSwgSSB3b3VsZCBsaWtlIHRvIHVzIHRvIGVuc3VyZSB3ZSBoYXZlIGF0IGxl YXN0IGhhdmUgYSBnb29kIGZvdW5kYXRpb24gZm9yIG11bHRpY2FzdCBsYXRlci4NCg0KDQoNCj4g ICAgICAgICAgICAgICBIYXJhbGQNCj4gDQo= From dwing@cisco.com Fri May 11 15:24:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB6921F86B0 for ; Fri, 11 May 2012 15:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.245 X-Spam-Level: X-Spam-Status: No, score=-110.245 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 r9w3-Uw2tIw5 for ; Fri, 11 May 2012 15:24:57 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D736421F85AE for ; Fri, 11 May 2012 15:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=276; q=dns/txt; s=iport; t=1336775097; x=1337984697; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Y9LeI0ue6gOBNh8zyce5tfx+6gvFtqp4ATsj3ScMwxo=; b=IjIKOZpJUOMlEwKbsaWGjMTTbG8AUaO53SX0pM77lIAwskOmGfh88dWQ WgMTpDgGI85T2D0Ge2CXVsF7X/9QECeNj59ZHGCEPNh+RRiuSc42leTDy +eXfx15z6NPfNtJNOnZo2wF6DnxscKjk89DhMjxG4g2CGcTZwkqgUMNJX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYJAFmRrU+rRDoI/2dsb2JhbABEhXmdPo8RBASBG4EHghUBAQEDAQgKARAHTwUIAwIJDwsCJgICGSMbAQEEAR0Xh2cEmy6NFpJXgS+ObYEYBIhkhRaWWoFpgwk X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41365609" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 11 May 2012 22:24:57 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4BMOvcP016425; Fri, 11 May 2012 22:24:57 GMT From: "Dan Wing" To: "=?UTF-8?Q?'G=C3=B6ran_Eriksson_AP'?=" , "'Harald Alvestrand'" References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> In-Reply-To: <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> Date: Fri, 11 May 2012 15:24:57 -0700 Message-ID: <103f01cd2fc4$e5c80980$b1581c80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0vvWr2RMlfyETUSsq4H1UYYNfseQAB0igQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:24:58 -0000 > Personally, I would like to us to ensure we have at least have a good > foundation for multicast later. EKT, draft-ietf-avt-srtp-ekt, does that, and works with the initial keying being Security Descriptions (should we allow that in RTCWEB) and with DTLS-SRTP. -d From marshall.eubanks@gmail.com Fri May 11 18:11:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6019D21F8664 for ; Fri, 11 May 2012 18:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.633 X-Spam-Level: X-Spam-Status: No, score=-103.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, 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 RWYhlHYTfL2O for ; Fri, 11 May 2012 18:11:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3121F865A for ; Fri, 11 May 2012 18:11:40 -0700 (PDT) Received: by lagv3 with SMTP id v3so1160093lag.31 for ; Fri, 11 May 2012 18:11:39 -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=hEodZIF8LgX39rIapXis2dlIPVgIiWrRS4jIleyH7jw=; b=sqeI7axlSfOPxe/ivlTojsjD+Mtmuhmst/8n8qNpHBcDe+mYut4Wz5UYa5SkW/KKEq fBu06jzfevFrdTpDFq6CE0F9W4wqYXyqsQYLKZybATf7RrPm4zlmzwLRrhufxnYw8hLN t4Uj+7xnpGTOMtsl5y9NwuSfP70xYINLcqYBT8ZXjKuR+0x1kWQiTl/zoOypFxXNnxiV YexbuwXYeX4j8vbIcy+wBb6ObAy7z9Wcfx0DAcXObw84btOCgHtgi4nAkeCC5gOYHLzR MSWcJerTWKOkb0go3Rqh8F0F08ME46JZtTSu293wG1EndmOBKrfxt4G1JRbK6C7Dr2zY 4/qA== MIME-Version: 1.0 Received: by 10.112.82.197 with SMTP id k5mr57931lby.98.1336785099630; Fri, 11 May 2012 18:11:39 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Fri, 11 May 2012 18:11:39 -0700 (PDT) In-Reply-To: <103f01cd2fc4$e5c80980$b1581c80$@com> References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> <103f01cd2fc4$e5c80980$b1581c80$@com> Date: Fri, 11 May 2012 21:11:39 -0400 Message-ID: From: Marshall Eubanks To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 01:11:41 -0000 On Fri, May 11, 2012 at 6:24 PM, Dan Wing wrote: >> Personally, I would like to us to ensure we have at least have a good >> foundation for multicast later. > > EKT, draft-ietf-avt-srtp-ekt, does that, and works with the initial > keying being Security Descriptions (should we allow that in RTCWEB) > and with DTLS-SRTP. Note : This draft expired last week. I presume that is not truly indicative of its status. Regards Marshall > > -d > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dwing@cisco.com Fri May 11 18:41:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1921F8627 for ; Fri, 11 May 2012 18:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.397 X-Spam-Level: X-Spam-Status: No, score=-110.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 uxJnLcGXVtjg for ; Fri, 11 May 2012 18:41:15 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDB21F8624 for ; Fri, 11 May 2012 18:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2158; q=dns/txt; s=iport; t=1336786874; x=1337996474; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=tzeK4gP2QKzJFhEU3AX5wI8mm5WStvAg2nTHnJD781A=; b=Loecv5lWhm6P/8gjCgwmR3v4TknfQOEVq50jA1GoKLDoojNG7iqmo+YP vQ7p0ezUcfwKq7Fxf96Yq+MikLmhnOpAW1mUugFKpRwPSsHNZkkHUdVU5 cEoqg1qs35GVKR1QDPTD542FFusuw6/q0kx0yWaQ8dApABlZz3qbs5TgK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFADS/rU+rRDoI/2dsb2JhbAA7CaM8kDSBB4IVAQEBAgEBAQEBBQoBF0QLBQcBAwIJDwIEAQEBJwcZCAYVCgkIAQEEEwkCF4deAwYEDJshlgENiVOKKW4QCYVvBIgwNIUWk0CDGoFpgwmBPw X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="41384919" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 May 2012 01:41:14 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4C1fEpx030078; Sat, 12 May 2012 01:41:14 GMT From: "Dan Wing" To: "'Marshall Eubanks'" References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> <103f01cd2fc4$e5c80980$b1581c80$@com> In-Reply-To: Date: Fri, 11 May 2012 18:41:13 -0700 Message-ID: <10c501cd2fe0$5108bf80$f31a3e80$@com> 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: Ac0v3DCzU9ZyfVwAQ3aNijNYyKtCcQAAyCPg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 01:41:18 -0000 > -----Original Message----- > From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > Sent: Friday, May 11, 2012 6:12 PM > To: Dan Wing > Cc: G=F6ran Eriksson AP; Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] New use-case proposed >=20 > On Fri, May 11, 2012 at 6:24 PM, Dan Wing wrote: > >> Personally, I would like to us to ensure we have at least have a > good > >> foundation for multicast later. > > > > EKT, draft-ietf-avt-srtp-ekt, does that, and works with the initial > > keying being Security Descriptions (should we allow that in RTCWEB) > > and with DTLS-SRTP. >=20 > Note : This draft expired last week. I presume that is not truly > indicative of its status. We are integrating the changes described in=20 http://www.ietf.org/mail-archive/web/avt/current/msg15232.html, which I summarized in my RTCWEB presentation, starting on slide 28 of = http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf In that deck, slide 28 shows the problem of interworking DTLS-SRTP with Security Descriptions -- namely, that something needs to=20 decrypt and re-encrypt SRTP packets in one direction. This is shown with flames coming out of that box. (Its CPU is on fire.) Slide 31 explains how EKT helps that interoperation. Slide 33 shows how the interoperation, where the box no longer has to decrypt/re-encrypt SRTP packets. It was asked if we can do that interworking, between Security Descriptions and DTLS-SRTP-EKT, without the media flowing through a box. Yes, we can -- except for EKT key changes (that is, key changes from the WEBRTC side). I have a design that will=20 handle that. But folks still need to digest the interop model and decide if allowing SDESC on the WEBRTC side is worth the permanent interoperation burden (on all WEBRTC endpoints) and worth the permanent reduction of identity and of media=20 encryption security. -d > Regards > Marshall >=20 > > > > -d > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From michawe@ifi.uio.no Sat May 12 01:58:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3E521F861C for ; Sat, 12 May 2012 01:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Fy94R5qr8dVM for ; Sat, 12 May 2012 01:58:31 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3421F85F9 for ; Sat, 12 May 2012 01:58:30 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1ST89l-0006UC-1w; Sat, 12 May 2012 10:58:29 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1ST89k-0005s4-Gp; Sat, 12 May 2012 10:58:29 +0200 Message-Id: <18737607-DD2E-44E4-AF48-3DCFB42D3A77@ifi.uio.no> From: Michael Welzl To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= In-Reply-To: <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 12 May 2012 10:58:05 +0200 References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 20037 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 242EC96719B90E5BC98CF80885245EE3BF004B3C X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 568 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 08:58:32 -0000 On May 11, 2012, at 11:31 PM, G=F6ran Eriksson AP wrote: > > > 11 maj 2012 kl. 22:52 skrev "Harald Alvestrand" =20 > : > >> On 05/11/2012 06:38 PM, G=F6ran Eriksson AP wrote: >>> >>> 11 maj 2012 kl. 18:21 skrev "Harald =20 >>> Alvestrand": >>> >>>> I propose to reject this use case because it requires yet another >>>> security redesign. >>>> The clue is here: >>>> >>>>> - The keying solution must allow each participants to encrypt to >>>>> multiple receivers without any decryption+encryption in the =20 >>>>> middle node >>>>> >>>> This means that each participant must use the same encryption =20 >>>> keys to >>>> all other participants; this in turn means that when someone =20 >>>> leaves the >>>> group, all participants must change their encryption keys; it =20 >>>> also means >>>> that as long as shared keys are used for authentication, all >>>> participants can impersonate all other participants. >>>> >>>> In fact, this solution has most of the issues (except for the =20 >>>> network >>>> layer deployment issue) that leads me to strongly advocate leaving >>>> multicast out of scope for this effort. >>> You mean for this phase of webrtc std efforts or for ever? >> Until we've got an usage scenario with a deployment story that I find >> credible. >> >> The point I'm pretty vehement on - that lack of multicast support =20 >> should >> not be a blocker for finalizing the specs we are working on. >> > > I am pretty sensitive to such consequence as well! Having said that, =20= > enabling innovation in this kind of application category is =20 > important for the long term evolution of the web platform. > > Personally, I would like to us to ensure we have at least have a =20 > good foundation for multicast later. +1 (to both parts of this) Cheers Michael From bossiel@yahoo.fr Sun May 13 22:14:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91221F8584 for ; Sun, 13 May 2012 22:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.584 X-Spam-Level: **** X-Spam-Status: No, score=4.584 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTYrgDWCSr4T for ; Sun, 13 May 2012 22:14:42 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ird.yahoo.com (nm1-vm0.bullet.mail.ird.yahoo.com [77.238.189.95]) by ietfa.amsl.com (Postfix) with SMTP id 0F5C821F857D for ; Sun, 13 May 2012 22:14:41 -0700 (PDT) Received: from [77.238.189.53] by nm1.bullet.mail.ird.yahoo.com with NNFMP; 14 May 2012 05:14:38 -0000 Received: from [212.82.108.114] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 14 May 2012 05:14:38 -0000 Received: from [127.0.0.1] by omp1023.mail.ird.yahoo.com with NNFMP; 14 May 2012 05:14:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 521241.13570.bm@omp1023.mail.ird.yahoo.com Received: (qmail 24664 invoked by uid 60001); 14 May 2012 05:14:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1336972478; bh=kXe/LMCsSolE1XCZ9RyZjjzAqW/Dil+dJkC9Y+kS1hs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YP4wRYdna6kVhu+eA5uexiEdJKMhD7UGlAFNTgRU4nxHN6Oroh1ov9hKRK7MEkr5fQ9YnWSAGYbhauMfaLi4pLsrkac1qSU9lkMd9FUlSLIJM5sexf44Fq1VJ0uZDNQeQ8q8PN0Sn0wwL2B4fgaUQ6oxDhyQPAjwV6G32LZYkNw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=OXYy4KkjOiVbcKCMcNIZvzYQUbpJBM10iqRh4VfZlqm6opHH9YBzGow46T8zu8jNW+Rv4dIQE2Kb9Dgd35BX2+G5iREKjivpF7GE75aqXflJ4gpXyBjA0QZ43ZtxeX0LU/r2wu5csR60IsDovPJzMCbBOe09YQS5q448s3ykvBg=; X-YMail-OSG: HPDlWNgVM1mskicBvlC5tgCeeX3NJBsl1RR47p4RnGjBjHu 1YvILgN6o8mRWqfihlwpovn_zw9veUiOShATTEgXhcr_5nlDNCpMwlNkWboD H0PHdVRO8nf9XM5V5eLGolN_tvjuyRhT0o2Jg8hUtox..4Zhy4gWTZPxU9sN rsdwvmewTC66oo_XcX2knCFBNnMAxNKUdKlBRRVyq0OQuZxvSkH4WR1GZ9cl .ArmC8WV02CI6XEcv5ge2JGr8UB7n8Ta_Kej4BBV80usmueSCjoE8RgnwJqC 4GM.7MPWU0VTpIBrrw27u2kIh8u6zjufVrRtDcnEZRtIH658KxwPq6b9U3AC zqe.gpE09MzD._Q4J9nwMs0650NztgdcgHzYYVhU4t1TNwUwZq0KTzre0pCQ dJSSl7esRoNNvHpsedaj3OL7g44vK6wumZkDotup_8e4Icp37r9dkeUW.OIb JFEBBQw2Boe802TCmvDfdPhu.3Zs9BHm.Xoq_gJDp39jqZjLGE982i8aDMKc SQHpeRthxyvHY9auuImCQ8f_F6cHU.Q_jm7_utozDJmE- Received: from [88.179.39.5] by web29602.mail.ird.yahoo.com via HTTP; Mon, 14 May 2012 06:14:38 BST X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1336972478.22604.YahooMailNeo@web29602.mail.ird.yahoo.com> Date: Mon, 14 May 2012 06:14:38 +0100 (BST) From: Bossiel thioriguel To: "rtcweb@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-888064777-1348475897-1336972478=:22604" Subject: [rtcweb] open source html5 sip client X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 05:14:43 -0000 ---888064777-1348475897-1336972478=:22604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,=0A=0AWe were working on WebRTC since 3 months and we'd like to shar= e with you our open source HTML5 SIP client (codename: sipml5).=0AFor more = information: http://www.sipml5.org=0ACode source: http://code.google.com/p/= sipml5/=0AI hop it could help other developers.=0A=0ARegards,=0A ---888064777-1348475897-1336972478=:22604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

W= e were working on WebRTC since 3 months and we'd like to share with you our= open source HTML5 SIP client (codename: sipml5).
For more information: = http://www.sipml5.org
Code source: http://code.google.com/p/sipml5/
I= hop it could help other developers.

Regards,
---888064777-1348475897-1336972478=:22604-- From magnus.westerlund@ericsson.com Mon May 14 01:35:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D921F85BD for ; Mon, 14 May 2012 01:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.146 X-Spam-Level: X-Spam-Status: No, score=-106.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6dkyyDyWu9B for ; Mon, 14 May 2012 01:35:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73021F85A0 for ; Mon, 14 May 2012 01:35:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7bc5ae00000796a-75-4fb0b91f41e4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.11.31082.F19B0BF4; Mon, 14 May 2012 09:49:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 09:49:50 +0200 Message-ID: <4FB0B91E.30507@ericsson.com> Date: Mon, 14 May 2012 09:49:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> In-Reply-To: <4FAD3C87.8080908@alvestrand.no> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:35:53 -0000 On 2012-05-11 18:21, Harald Alvestrand wrote: > I propose to reject this use case because it requires yet another > security redesign. > The clue is here: > >> >> - The keying solution must allow each participants to encrypt to >> multiple receivers without any decryption+encryption in the middle node >> > > This means that each participant must use the same encryption keys to > all other participants; this in turn means that when someone leaves the > group, all participants must change their encryption keys; it also means > that as long as shared keys are used for authentication, all > participants can impersonate all other participants. Actually EKT solves this in a very reasonable way. Each participant announces his key using EKT. When a participant leaves all the other participants uses EKT to provide a new key for the media they send. Thus no need for synchronized key roll over anything. When it comes to the security aspect this I would say it is part of the model. SRTP uses symmetric keys, thus anyone can spoof anyone that are inside the session and having access to the crypt context. In centralized conferencing it is the central node that enforces the relation between each other. That can be done both using independent crypto contexts and having shared one. And the arguments around the complexity is not that it on a per stream individual basis is horrible expensive. It is the argument about needing to have the functionality doing decryption and N-1 encryptions for each packet being forwarded to all the others in a N number of participants conference. The argument is to have no need for any media flow encryption and decryption only be part of the key-management. > > In fact, this solution has most of the issues (except for the network > layer deployment issue) that leads me to strongly advocate leaving > multicast out of scope for this effort. > I am not arguing for including IP multicast support. The issue this use case brings up is that one of RTP support for multi-party sessions. This use case makes it clear that a particular level of RTP functionality support is needed. I think almost the same is needed for centralized RTP mixer topologies where the middle node uses its own SSRCs to forward other participants media streams and transfer RTCP feedback messages when not possible to handle in the mixer. Another aspect that we need to bring up here is if there is going to be any support for a WebRTC browser to receive a media stream from A and be capable of forwarding it to B. Without the same features as needed for this use case we must mandate that a browser doing this supports media transcoding. Otherwise congestion control and media control aspects will not be supported enabling media to be delivered. Transcoding obviously gives a significant hit on quality unless the media bit-rate is significantly higher than without transcoding. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pravindran@sonusnet.com Mon May 14 01:39:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B6821F859E for ; Mon, 14 May 2012 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 KkbANJuUmbOD for ; Mon, 14 May 2012 01:39:26 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14721F84CE for ; Mon, 14 May 2012 01:39:26 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKT7DEvQPO0qJhSWHvewuH7yn6aYpnAT9B@postini.com; Mon, 14 May 2012 01:39:26 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 May 2012 04:39:39 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 14 May 2012 14:09:21 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewALSsOAABK1rwAAF0kPAAAxgqEAAARcP4AAAHvUAAAArGiAAAB9ngAAAAq7AAAIW/WAAAB4jQAAAR30gAASfQ4AABLNEwAAA128gAAErXWAAAIxoAAAASAKgAAAF7EAAAAvPYAAAIyrgAAAaVoAAACEBgAA7qbDAAArq6qQAEEmgYAAvjwBsA== Date: Mon, 14 May 2012 08:39:20 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603455B@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericss on.se> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> In-Reply-To: <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:39:28 -0000 Cullen, PRANSWER ISSUE: In case PRANSWER is designed for interop with SIP forking with ICE handling= ,=20 then PRANSWER is not required because SIP (RFC 3261) never allows multiple answer within the same dialog. In case of each forked response (18x/200 wit= h=20 new To-Tag), SIP UA creates new dialog and those dialog has to be handled=20 separately. How grouping of those SIP dialogs works together is a implement= ation issue in SIP. So, there is no need of new O/A state (PRANSWER) just to make= =20 SIP interop happen. Please let me know any other usecase which compels=20 PRANSWER state in JSEP. FORKING ISSUE: I agree with you that most of the deployed SIP end-point products does not= =20 Support parallel forking and its next hop B2BUA (PBX, SBC, GW) takes care of the handling. Having said that, some of the well deployed SIP entity in= =20 service provider (SP) network is based on SIP forking which compels to=20 support forking in actual End-point or B2BUA. I know that it is possible to design JSEP without forking support and interop with SIP is possible whi= ch=20 will be equivalent to H.323 to SIP gateway development wherein H.323 never supports forking. Now the question is whether JSEP API supports forking=20 or not. I'm lean towards forking because the same peerconnection cloning AP= I=20 may extend for browser media mixing later stage. If you explain about my=20 mixing API idea is wrong, then I'll agree with you that cloning of peer=20 connection is not required. Thanks Partha =20 >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@iii.ca] >Sent: Friday, May 11, 2012 12:36 AM >To: Ravindran, Parthasarathi >Cc: Justin Uberti; Christer Holmberg; Randell Jesup; rtcweb@ietf.org >Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in >JSEP > > >I'm a very confused on what type of forking (with ICE) use case people >want to satisfy. > >I agree with you that PRANSWER does make things more complicated but I >presented at several of the meetings about how things just don't work >without it or something like it so I don't see how to avoid it. > > >On May 9, 2012, at 12:34 AM, Ravindran, Parthasarathi wrote: > >> Hi Justin, >> >> Sorry for the delay in reply. There are two issues associated with >this scenario: >> >> Issue 1) SIP Forking : This is solved by peerconnection cloning >> >> Issue 2) UPDATE support within SIP early dialog in the non-forking >scenario. Here, the cloning will not solve issue as the answerer >originated the new offer during SDP_PRANSWER state . Issue 2 is the >title of this mail thread. >> >> IMO, SDP_PRANSWER will complicate the offer/answer state machine. >> >> Thanks >> Partha >> >> >> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Justin Uberti >> Sent: Tuesday, May 08, 2012 8:40 PM >> To: Christer Holmberg >> Cc: Randell Jesup; rtcweb@ietf.org >> Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in >> JSEP >> >> The conclusion on this thread seems to be that the right way to >address this problem is via PeerConnection cloning, and that no changes >are needed to the JSEP state machine. I'll work with Richard to figure >out how we should extend JSEP to support cloning. >> >> On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg > wrote: >> Hi, >> >> >>>>You could also choose not to alert the remote user until the ICE >procedures have finished - more or less using ICE with preconditions. >> >>>> >> >>>> Of course, that is going to trigger actions in STUN/TURN servers, >> >>>> even if the called party won't accept the call, but at least from >a user experience perspective that is still better than lifting the >hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish >seconds before one can start to talk. >> >>> >> >>> This also has a downside of disclosing user's IP to the caller >without the user confirmation. For a lot of applications this can be >serious security flaw. >> >> >> >> The client can still log when ICE procedures occur. >> >> >> >> Because, even if I wait until your phone starts to ring, most >likely I would still get your IP address without user confirmation >(speaking in SIP terms, phones normally don't ask for user permission >before they send 18x with SDP), eventhough you would easier be made >aware of that it happens. >> > >> > Another alternative is of course to do ICE with an SBC, and/or >> > having an SBC doing ICE on behalf of you :) >> > >> > >> > This is true for SIP but was as far as I know was specifically >> > designed around in WebRTC. WebRTC signaling server acts as B2BUA so >any type of ringing notification goes through the web server and does >not need to carry any type of client address information. The client >address information is only provided when SDP answer is sent or ICE >negotiation is started. >> >> Assuming you are only going to make user confirmation (read: accept >calls) in cases where you absolutely sure that the caller isn't someone >trying to get your IP address. >> >> But, never the less, having a solution where I first have to give user >confirmation, and then wait until I can start to talk, is probably >something most people want to avoid. Depending upon, of course, how long >the waiting time is. >> >> Regards, >> >> Christer >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon May 14 01:48:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F121F85D1 for ; Mon, 14 May 2012 01:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpwQ+2ORt0bE for ; Mon, 14 May 2012 01:48:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9D21F85D0 for ; Mon, 14 May 2012 01:48:32 -0700 (PDT) X-AuditID: c1b4fb30-b7c05ae000003df9-45-4fb0c6dfa1a4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 77.3E.15865.FD6C0BF4; Mon, 14 May 2012 10:48:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:48:30 +0200 Message-ID: <4FB0C6DD.6080405@ericsson.com> Date: Mon, 14 May 2012 10:48:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Magnus Westerlund References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <4FB0B91E.30507@ericsson.com> In-Reply-To: <4FB0B91E.30507@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:48:33 -0000 On 2012-05-14 09:49, Magnus Westerlund wrote: > On 2012-05-11 18:21, Harald Alvestrand wrote: >> I propose to reject this use case because it requires yet another >> security redesign. >> The clue is here: >> >>> >>> - The keying solution must allow each participants to encrypt to >>> multiple receivers without any decryption+encryption in the middle node >>> >> >> This means that each participant must use the same encryption keys to >> all other participants; this in turn means that when someone leaves the >> group, all participants must change their encryption keys; it also means >> that as long as shared keys are used for authentication, all >> participants can impersonate all other participants. > > Actually EKT solves this in a very reasonable way. Each participant > announces his key using EKT. When a participant leaves all the other > participants uses EKT to provide a new key for the media they send. Thus > no need for synchronized key roll over anything. To make it clear, there are two levels of security here. A first one of each participant changing keys after a participant has left and no longer gets the traffic. If that is done without changing the EKT key then that participant could decrypt the key, but then the attacker must get to the media which no longer is being forwarded to it. The second level which is recommend is to have the central node change the EKT key by triggering DTLS based rekeying of the EKT. Then it is impossible for the participant that left to eavesdrop on the conference. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tim@phonefromhere.com Mon May 14 02:25:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4221F85FB for ; Mon, 14 May 2012 02:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 1DOSjEmeg+6U for ; Mon, 14 May 2012 02:25:52 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E921F85F7 for ; Mon, 14 May 2012 02:25:51 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id C8EA937A905; Mon, 14 May 2012 10:34:51 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 14 May 2012 10:25:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> To: "Ejzak, Richard P (Richard)" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:25:52 -0000 On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote: > Support for multiple registered contacts and (parallel) forking are = pretty fundamental to SIP. This has little to do with conferencing. = Some systems (not all) may support only serial forking or may serialize = media interactions associated with parallel forking, but forking remains = widely deployed and useful. I have a feeling that it is mostly useful because SIP is managing both = the signalling and the identity.=20 In most WebRTC cases, the real identity of the user will be established = with a web protocol (perhaps OAuth). The identity used in any browser based legacy signalling (e.g. SIP) will = be a second-order derived or temporary identity. In that case there is no need for SIP to use the same temporary = identity for both my phones, which (I think) renders the forking case significantly less useful. Tim. =20= From roman@telurix.com Mon May 14 11:45:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1147B21F88A3 for ; Mon, 14 May 2012 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 pjJXd5s3PtuT for ; Mon, 14 May 2012 11:45:30 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43F21F88A7 for ; Mon, 14 May 2012 11:45:30 -0700 (PDT) Received: by dacx6 with SMTP id x6so6481041dac.31 for ; Mon, 14 May 2012 11:45:30 -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=NJaDgNUJBddL/nwIkzno7SJ6Qs2jtk2LdJlKtVYN5uQ=; b=Vc/KzUOqNJcXRf6q9TZtIVot4nn03cm8+vvU3iTDd6HNCa79RKNqjyQ1ZxjOHQPWU6 +FBT1rUzhtqMqt3Zg6QTfccJr00HAL7z7Y2UO0ak7ivFn+ObtcG5rxEfKG4Q7hfrq/B5 N5o9zPUbfD5ISiL3WN1YnKgixnPq5Ix2gxk0knQFz+BqsIskV9sdt/WdZeulOn62ghEN wHcfTHAupfuU7DOmlGC1OwKV0h/Fqy1TWtIgWGgVkwZJj6bf1lnVevUlfn+iwPI71RR6 9q3/7mgLuC2R90h668QM6qLW6/pE69vMQuYU1SnIF4nN5f9+dmWTQbl+Rlym3ia1uk1Q PWLQ== Received: by 10.68.132.34 with SMTP id or2mr25647737pbb.118.1337021130271; Mon, 14 May 2012 11:45:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id jv6sm15314383pbc.40.2012.05.14.11.45.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 11:45:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6675577pbc.31 for ; Mon, 14 May 2012 11:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.227.33 with SMTP id rx1mr25192796pbc.102.1337021125392; Mon, 14 May 2012 11:45:25 -0700 (PDT) Received: by 10.68.74.133 with HTTP; Mon, 14 May 2012 11:45:25 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 14 May 2012 14:45:25 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=047d7b1631bf3c779c04c0037d32 X-Gm-Message-State: ALoCoQnXiNfy9C2LvjlYtWRvqSKZMpmcupQ74rq/yuBZ+K05EhUtQvuYf0UTy1vXpc+fGNQBQbj8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:45:31 -0000 --047d7b1631bf3c779c04c0037d32 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 14, 2012 at 5:25 AM, Tim Panton wrote: > > On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote: > > > Support for multiple registered contacts and (parallel) forking are > pretty fundamental to SIP. This has little to do with conferencing. Some > systems (not all) may support only serial forking or may serialize media > interactions associated with parallel forking, but forking remains widely > deployed and useful. > > > I have a feeling that it is mostly useful because SIP is managing both the > signalling and the identity. > In most WebRTC cases, the real identity of the user will be established > with a web protocol (perhaps OAuth). > The identity used in any browser based legacy signalling (e.g. SIP) will > be a second-order derived or temporary identity. > > In that case there is no need for SIP to use the same temporary identity > for both my phones, which (I think) > renders the forking case significantly less useful. > > I strongly disagree with this. I can still be calling somebody via, let's say, their email address and end up talking to two people using two different devices. I think there is always going to be the situation where one identity (email address, support link on the web site) will map to multiple physical end points. It is possible to resolve this identity to end point mapping using some sort of HTTP signaling before media connection is setup and then to generate offers for each end point, but this would make signaling more complex, and would slow down the call connect process by at least half the round trip time. _____________ Roman Shpount --047d7b1631bf3c779c04c0037d32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 14, 2012 at 5:25 A= M, Tim Panton <tim@phonefromhere.com> wrote:

On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote:

> Support for multiple registered contacts and (parallel) forking are pr= etty fundamental to SIP. =A0This has little to do with conferencing. =A0Som= e systems (not all) may support only serial forking or may serialize media = interactions associated with parallel forking, but forking remains widely d= eployed and useful.


I have a feeling that it is mostly useful because SIP is managing bot= h the signalling and the identity.
In most WebRTC cases, the real identity of the user will be established wit= h a web protocol (perhaps OAuth).
The identity used in any browser based legacy signalling (e.g. SIP) will be= a second-order derived or temporary identity.

In that case there is no need for SIP to use the same =A0temporary identity= for both my phones, which (I think)
renders the forking case significantly less useful.


I strongly disagree with this. I can still be calling somebody = via, let's say, their email address and end up talking to two people us= ing two different devices. I think there is always going to be the situatio= n where one identity (email address, support link on the web site) will map= to multiple physical end points. It is possible to resolve this identity t= o end point mapping using some sort of HTTP signaling before media connecti= on is setup and then to generate offers for each end point, but this would = make signaling more complex, and would slow down the call connect process b= y at least half the round trip time.
_____________
Roman Shpount
--047d7b1631bf3c779c04c0037d32-- From martin.thomson@gmail.com Mon May 14 13:31:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DD221F88CE for ; Mon, 14 May 2012 13:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.731 X-Spam-Level: X-Spam-Status: No, score=-3.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 384nJDDl-iNL for ; Mon, 14 May 2012 13:31:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6027221F88BF for ; Mon, 14 May 2012 13:31:27 -0700 (PDT) Received: by bkty8 with SMTP id y8so4908055bkt.31 for ; Mon, 14 May 2012 13:31: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=KTkM2HWExgvwUYIQbpEFkHorbZWkG85e71Wtw5K8Wvw=; b=DKEoQmC4pkLAUVXbTTRh5Uveb99q+kOb1HtF+6CxGaBGF2aJZqmtOuNhxpIA/Cawwh MWcCiCWuW6KGI3weCbZx7zJqHjZKxjxOPbaBnsmaHyXebeeOc8dFBRCawc8ihwK3IJ7v 2Z9jZBZ4lfk6QWyQwzG1IFPtDRuEn1WOzUGZyaNlJ318pww96ehwXBYgkrHWVWeWn88g VeyN4HRSpVDq2UuR3yh4SC3JM41L5NMdNsnBQutsvigZ2skusL+NSqaaEWgvveFePPZH Zi/q/uqpsWDX2a5iH+ljWHIbkxy3WfS7VJcaUKsS4PWjsXgx8Vvpqvjz1qlR9z2b5rqc iPlw== MIME-Version: 1.0 Received: by 10.204.152.13 with SMTP id e13mr3786980bkw.46.1337027486307; Mon, 14 May 2012 13:31:26 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 14 May 2012 13:31:26 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 14 May 2012 13:31:26 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:31:28 -0000 On 14 May 2012 11:45, Roman Shpount wrote: > It is possible to resolve this identity to end > point mapping using some sort of HTTP signaling I think that this was the point. Your application has some concept of identity that maps to one or more registered endpoints. It can work out the signaling such that all devices get notified of a session request without the need for this complex cloning mess. From roman@telurix.com Mon May 14 13:40:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B14921F88C1 for ; Mon, 14 May 2012 13:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 XPPdjwfHnT3i for ; Mon, 14 May 2012 13:40:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7221F88BF for ; Mon, 14 May 2012 13:40:47 -0700 (PDT) Received: by dacx6 with SMTP id x6so6607104dac.31 for ; Mon, 14 May 2012 13:40:47 -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=0eWoHnz3QV7+pyDX6Rv4ViHgBWyNSnPzgM3mnTqu9Lw=; b=HoX/WlzsEadv/UKt4Y5IZyRjdyhKSd/Q59tFPY7HYcEmCJYI1elD9HG1dO70Ffm2Ky Uz1b9ymnqtNZKTbkttX5XmzUkWNHe0/iGQ6uXD99qwn/D9EC80AXeCoPlZ1q66NSJSVc i0if6OCR3KiELH3LEASXvsd3UIVgtv63MskaNkdjLhzIctMQ9DQbC82l5hOaOR6z7LnD EsEJwOI+ztjnLdjeqF4jDsC+mjn1LKv8fELxU8lyGBv55ZGBTxjESemqLq82U1HkYUNe 55aU45nv6TDHupQ8ACeUgWUMUsBQmk9AUkXJQCieFoEyfuEAetBFh00TqdZLXUYNHt+I cZpA== Received: by 10.68.193.233 with SMTP id hr9mr26077756pbc.99.1337028046984; Mon, 14 May 2012 13:40:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id jv6sm15555709pbc.40.2012.05.14.13.40.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 13:40:46 -0700 (PDT) Received: by dacx6 with SMTP id x6so6607079dac.31 for ; Mon, 14 May 2012 13:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.131.38 with SMTP id oj6mr4033850pbb.39.1337028045251; Mon, 14 May 2012 13:40:45 -0700 (PDT) Received: by 10.68.74.133 with HTTP; Mon, 14 May 2012 13:40:45 -0700 (PDT) In-Reply-To: References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> Date: Mon, 14 May 2012 16:40:45 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b15b017b124f704c00519e0 X-Gm-Message-State: ALoCoQnYVy89gyItuu5AKcBmrrZW5250deVcffUBWqIsCDWxobLAM3Jj5AS5RfHhSCu7e33/TfTd Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:40:48 -0000 --047d7b15b017b124f704c00519e0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 14, 2012 at 4:31 PM, Martin Thomson wrote: > On 14 May 2012 11:45, Roman Shpount wrote: > > It is possible to resolve this identity to end > > point mapping using some sort of HTTP signaling > > I think that this was the point. Your application has some concept of > identity that maps to one or more registered endpoints. It can work > out the signaling such that all devices get notified of a session > request without the need for this complex cloning mess. > I am not sure the cloning is a "complex mess". If ICE is the requirement (so you know remote IP/port of each party) you can map each remote party to the source IP/port. Then all you need to do is reference counting for local sockets/TURN allocations, and you are done implementing it. PRANSWER would probably require as much coding but would not solve all the problems that cloning will. _____________ Roman Shpount --047d7b15b017b124f704c00519e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 14, 2012 at 4:31 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 14 May 2012 11:45, Roman Shpount <roman@telurix.com> wrote:
> It is possible to resolve this identity to end
> point mapping using some sort of HTTP signaling

I think that this was the point. =A0Your application has some concept= of
identity that maps to one or more registered endpoints. =A0It can work
out the signaling such that all devices get notified of a session
request without the need for this complex cloning mess.

I am not sure the cloning is a "complex mess&qu= ot;. If ICE is the requirement (so you know remote IP/port of each party) y= ou can map each remote party to the source IP/port. Then all you need to do= is reference counting for local sockets/TURN allocations, and you are done= implementing it. PRANSWER would probably require as much coding but would = not solve all the problems that cloning will.
_____________
Roman Shpount

--047d7b15b017b124f704c00519e0-- From randell-ietf@jesup.org Mon May 14 21:42:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCF9E8016 for ; Mon, 14 May 2012 21:42:14 -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 HJoOuk5Z2po0 for ; Mon, 14 May 2012 21:42:13 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAE9E8006 for ; Mon, 14 May 2012 21:42:12 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SU9aN-0004WQ-Ca for rtcweb@ietf.org; Mon, 14 May 2012 23:42:11 -0500 Message-ID: <4FB1DE4F.5010701@jesup.org> Date: Tue, 15 May 2012 00:40:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 04:42:15 -0000 On 5/14/2012 4:31 PM, Martin Thomson wrote: > On 14 May 2012 11:45, Roman Shpount wrote: >> It is possible to resolve this identity to end >> point mapping using some sort of HTTP signaling > > I think that this was the point. Your application has some concept of > identity that maps to one or more registered endpoints. It can work > out the signaling such that all devices get notified of a session > request without the need for this complex cloning mess. That isn't the point of cloning (getting notified). It's the server in this case that knows about the multiple endpoints. (For that matter, one could be a WebRTC client, and another could be a WebRTC gateway to PSTN, and a third could be a network-based answering service where a pickup from an actual endpoint would abort the playback/recording - another case of a forked ANSWER after a final ANSWER where cloning is useful.) -- Randell Jesup randell-ietf@jesup.org From oscar.ohlsson@ericsson.com Tue May 15 11:27:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BBE21F86EB for ; Tue, 15 May 2012 11:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 02ERFFbbBvm6 for ; Tue, 15 May 2012 11:27:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7DECE21F86E5 for ; Tue, 15 May 2012 11:27:29 -0700 (PDT) X-AuditID: c1b4fb30-b7be1ae0000059fc-32-4fb2a0100d87 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.CA.23036.010A2BF4; Tue, 15 May 2012 20:27:29 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 15 May 2012 20:27:28 +0200 From: Oscar Ohlsson To: "rtcweb@ietf.org" Date: Tue, 15 May 2012 20:27:27 +0200 Thread-Topic: [rtcweb] New use-case proposed Thread-Index: Ac0vdiHw0ZhBhnYyQ+KJTcwm3f2z+ADTmebQ Message-ID: References: <4FAD0D8C.7020701@ericsson.com> In-Reply-To: <4FAD0D8C.7020701@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] New use-case proposed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:27:31 -0000 Hi, An interesting variant of Stefan's use case is when the central media=20 node is provided by an untrusted 3rd-party. The application provider and=20 the users trust the 3rd party to deliver the media as expected, but they=20 do not necessarily trust it with cleartext media, be that audio, video=20 or data. The benefit is that the application provider can be less picky when=20 selecting the 3rd-party provider(s). Having a large pool to choose from=20 makes it easier to switch provider or select the cheapest or=20 geographically closest one. +---+ +------------+ +---+ | A |<---->| |<---->| B | +---+ | Translator | +---+ +---+ |(untrusted) | +---+ | C |<---->| |<---->| D | +---+ +------------+ +---+ A requirement for this to work is that group keys are supported. This=20 allows the central media node to simply forward the media without=20 decrypting and re-encrypting it for each recipient. The fact that the=20 central media node becomes less complex and can achieve higher=20 throughput is of course beneficial, but it's not the main purpose. Another requirement is that the group key can be distributed by the=20 application provider (or some other trusted party) without the central=20 media node learning its value. This can easily be achieved in=20 DTLS-SRTP + EKT by using the a=3Ddtls-srtp-host attribute. The host=20 specified in the attribute performs an initial DTLS-SRTP handshake with=20 each party and transmits the shared EKT key (i.e. the group key). +------------+=20 | Key Server | |-----EKTkey---- | (trusted) | ----EKTkey-----| | | | | | +------------+ | | | | +---+ +------------+ +---+ | |---> | A |<---->| |<---->| B | <---| | +---+ | Translator | +---+ | | +---+ |(untrusted) | +---+ | |---> | C |<---->| |<---->| D | <---| +---+ +------------+ +---+ Is the above something that this group would like to support or=20 investigate further? Best regards, Oscar Ohlsson > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Friday, May 11, 2012 3:01 PM > To: rtcweb@ietf.org > Subject: [rtcweb] New use-case proposed >=20 > I've been sketching on a new use-case. The use-case is=20 > intended to derive requirements that enable low complex=20 > central nodes for multi party sessions, which in turn leads=20 > to requirements regarding > (essentially) keying solution for SRTP and the possibility=20 > for the app to control/set things in the media configuration=20 > (in other words, for JSEP): >=20 >=20 > Multi-party with low complexity central node=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A geographically spread (charity, non-profit, school)=20 > organization offers its members multi-party video=20 > communication via a shared virtual room that participants can=20 > enter and leave at any time. At times there are many persons=20 > in the virtual room (20+), at other times very few (3-5, or even 0-1). >=20 > The application will control if few participants (a subset)=20 > are shown at a higher fidelity or if many (all) are shown at=20 > a lower fidelity or a mix of some few at high fidelity and=20 > the rest at much lower fidelity given the existing bandwidth=20 > limitations between participants. >=20 > Since there are at times many persons in the virtual room, it=20 > is not feasible to set up a mesh. The bandwidth needed by a=20 > participant exceeds what many members have access to,=20 > especially in their uplinks, so instead a central media node=20 > is deployed. In addition, the organization does not have=20 > access to much funds, but has to rely on cheap hardware=20 > (often donated) operated by volunteers. >=20 > From this use-case a high level requirement saying something like >=20 > "It must be possible to set up media streams and encryption=20 > in such a way that processing in a central node is minimized=20 > (no transcoding required, no RTP packet rewriting, no=20 > decryption/re-encryption for every outgoing flow - just=20 > simple forwarding)." >=20 > can be derived. This can in turn be broken down into more=20 > detailed requirements such as: >=20 > - The keying solution must allow each participants to encrypt=20 > to multiple receivers without any decryption+encryption in=20 > the middle node >=20 > - RTP sessions that have SSRCs from multiple PeerConnections=20 > being interconneted must be supported. From a given end-point=20 > all SSRCs will come over one PC, but the full path will be=20 > different towards different sets of SSRCs. >=20 > - Signalling must be capable of establishing a common set of=20 > receiver configurations over all participants. >=20 > - The API must allow for the above, i.e.: > -- The app must be able to chose a keying solution that=20 > enables encryption to multiple receivers (if the app can have=20 > any control over keying method used) > -- The app must be able to control SSRCs to use for outgoing streams > -- The app must be able to control the receiver configuration=20 > the browser uses >=20 > Is this something we should consider adding to the use-case document? >=20 > Br, > Stefan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From Milan.Young@nuance.com Tue May 15 16:22:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770B911E80B3 for ; Tue, 15 May 2012 16:22: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 IAmZKQMGZGeF for ; Tue, 15 May 2012 16:22:12 -0700 (PDT) Received: from som-mx-a.nuance.com (som-mx-a.nuance.com [198.71.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id D984D11E80A1 for ; Tue, 15 May 2012 16:22:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABjksk8KHBQY/2dsb2JhbABEtQyCFwU6JSwBFRUUQiYBBBvDE5ARYwScFI0S Received: from unknown (HELO SOM-CAS01.nuance.com) ([10.28.20.24]) by som-mx-a.nuance.com with ESMTP/TLS/AES128-SHA; 15 May 2012 19:06:47 -0400 Received: from SOM-EXCH04.nuance.com ([fe80::b1be:1c21:d7f8:543c]) by SOM-CAS01.nuance.com ([::1]) with mapi id 14.02.0283.003; Tue, 15 May 2012 19:22:10 -0400 From: "Young, Milan" To: "rtcweb@ietf.org" Thread-Topic: TCP vs UDP for media Thread-Index: Ac0y8YFlKfCoI+0LRZ2tsFbI0SJeNw== Date: Tue, 15 May 2012 23:22:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.16.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 23:22:12 -0000 Most of the use cases within WebRTC center around human to human communicat= ion, and for such cases RTP transport makes sense. But there are at least = a few use cases where one of the endpoints could be a machine. Since machi= nes have the ability to buffer and take a quick nap on the job, the "realti= me" requirement isn't as critical. Often, in such cases, the more importan= t consideration is whether all of the media was transmitted. I'm relatively new to WebRTC, so I apologize if I'm rehashing settled issue= s. But I'm wondering if any thought has been given to TCP as a media trans= port. If framing and timeouts could be worked out, would other folks besid= es myself find this useful? =20 Thanks From giles@thaumas.net Tue May 15 16:38:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3111E80CB for ; Tue, 15 May 2012 16:38:35 -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 Ms7xqk6fdxbo for ; Tue, 15 May 2012 16:38:34 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 870B011E80A1 for ; Tue, 15 May 2012 16:38:34 -0700 (PDT) Received: by yhgm50 with SMTP id m50so267579yhg.27 for ; Tue, 15 May 2012 16:38: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:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=s5AsNUDZ6X1BhTGGi2k2iQsUk+q6npDSxN05qxpNwOQ=; b=L7+Ac/+W8xfs3uIVXNQYXfOvnzkCOqA/NQ/p4gFHm2nm3b5YVB892wQALYIdnHpqiT Cc5zHn26N7Z5M1bLTtDM8JxEsCmnYD6Xi2y0lTLA6QmcDPdRcHkKsNjEQOI+SVzTCq1t dhU21r9UMooPipxwjhpqP/RMShGUB7Kh6Dqk+AF4zCK7l65YEjK7e8nJJm+Z30+bPqD5 zouggBxuczHM7TyHmMAs1ipNcs52wnPIRCm1SgE2OFEXdXGFr9spm1xzTUDgS9uNZrUA d1EkIVjqzzwpBEdyzJklNVpFiaXKiCtO8SLdLWboj3gtFJMS2DTn/AsT5QlEs5S15rLq 3URA== Received: by 10.50.197.233 with SMTP id ix9mr519813igc.26.1337125113823; Tue, 15 May 2012 16:38:33 -0700 (PDT) Received: from glaucomys.lan (s66-183-19-247.bc.hsia.telus.net. [66.183.19.247]) by mx.google.com with ESMTPS id yg9sm14130640igb.15.2012.05.15.16.38.32 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 16:38:33 -0700 (PDT) Message-ID: <4FB2E8FC.40404@thaumas.net> Date: Tue, 15 May 2012 16:38:36 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Young, Milan" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQngzQWT09AVuUFAFJSbZ0OEx7I1C3/pDxD/UKV/+ZubEKWawcYBbM9jUrw4/TnCqNdJU9BS Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 23:38:35 -0000 On 12-05-15 4:22 PM, Young, Milan wrote: > I'm wondering if any thought has been given to TCP as a media transport. Where low latency transmission isn't an issue, one can generally fall back to established TCP-based protocols, like HTTP streaming and websockets, so we haven't really worried about that angle in the context of webrtc. Recording the stream is a requirement, so probably something could be built using that, merging recordings from each endpoint to fix up any dropped packets. -r From ekr@rtfm.com Tue May 15 16:47:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914B11E80A1 for ; Tue, 15 May 2012 16:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 byI7dx5qsyYL for ; Tue, 15 May 2012 16:47:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6A1D11E8099 for ; Tue, 15 May 2012 16:47:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so180135vbb.31 for ; Tue, 15 May 2012 16:47:29 -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=hBxK6VmMYj6EjCqOFg5oTUoZzgfDyObP/LZq46Fb2e8=; b=N+XeR8G66TJagiLaaGLgq9SPeaMqNAQ7YvToxPwrl0oM60dAO10MGuwf2ZjYP93UMc RRgJkxkL4wctMQO24+91BxSUNeoePi7cllnC6gfPdU5g5x9OL/Ceq5tzJa3RRTN08UX3 eGe/C84/4/n46CYDnNDNzouBXUkPBBiidjbpw48IMv5pvybOV/EMz/oRu7ey0Er9ncjr L6lnZDfNBhsDD+KQvurZ0KXzMnuRAWAGGCLgEK/uT2Gx8Gdbw3Z63EhZ/b4jhsYD9LQW MHS9I5s85lK8oP6HHSDdSe2L0m3n77RIguMPev/rUtAET325AB3Sr5vhBW+xn/NC52zx 5fOA== Received: by 10.52.100.229 with SMTP id fb5mr463154vdb.102.1337125649361; Tue, 15 May 2012 16:47:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 16:46:49 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <4FB2E8FC.40404@thaumas.net> References: <4FB2E8FC.40404@thaumas.net> From: Eric Rescorla Date: Tue, 15 May 2012 16:46:49 -0700 Message-ID: To: Ralph Giles Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkHI0vyB5AC6PbKYbjnZwk6aPnE33/p7GkEIzXm++MoqC0j/MTXCEiqEvs1OSmhXc7h/1xu Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 23:47:30 -0000 On Tue, May 15, 2012 at 4:38 PM, Ralph Giles wrote: > On 12-05-15 4:22 PM, Young, Milan wrote: > >> I'm wondering if any thought has been given to TCP as a media transport. > > Where low latency transmission isn't an issue, one can generally fall > back to established TCP-based protocols, like HTTP streaming and > websockets, so we haven't really worried about that angle in the context > of webrtc. > > Recording the stream is a requirement, so probably something could be > built using that, merging recordings from each endpoint to fix up any > dropped packets. Agreed. This seems like something that could be done using just getUserMedia() plus existing Web technologies. -Ekr From fluffy@cisco.com Tue May 15 18:31:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98A11E8095 for ; Tue, 15 May 2012 18:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.327 X-Spam-Level: X-Spam-Status: No, score=-110.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 eIbpjZw0Co1C for ; Tue, 15 May 2012 18:31:19 -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 5DA1911E8099 for ; Tue, 15 May 2012 18:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2624; q=dns/txt; s=iport; t=1337131879; x=1338341479; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=i9KEg6u2+XYynqyV4s8uULr6PuomLtGaKOZB7/soEOc=; b=jeOnOt0laPPq5okRRA9AA6g2OZZmxzsugsOl90TPv3X1dut5TFgc9wqe 9YRZ5aNHVbjlEKPpvzlWRomI8c5SjnVVYH0WLKz1Z/tJqEQKeJ4pUnZl3 /N/Z0sYqrF/rJ9ZQvNGUSpFSdKbM5S5LZfkhskXpra2uijPTZ4lXIaF6G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFACwCs0+rRDoI/2dsb2JhbABEgx2wZoEHgi4BFBOCMoVwgXuZb4EooBWNToJDYwSIZI0ZhXWIYoFpgwiBQA X-IronPort-AV: E=Sophos;i="4.75,599,1330905600"; d="scan'208";a="42377395" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 May 2012 01:31:19 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4G1VIvL005217 for ; Wed, 16 May 2012 01:31:18 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 19:31:18 -0600 Message-Id: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 01:31:20 -0000 Cone and symmetric nat are probably not what exactly what we mean here - = perhaps just refer to it as the various types of NATs described in RFC = 4787.=20 Might want to add to some use case that when A calls B, and B does not = reveal their IP address to A. Like to add Alice calls Bob with an encrypted media. Bob can tell the = that the encrypted media is from Alice and not from an MITM Like to add ability to make a call in a situation where even small = sounds from microphone should be sent to the other side and not filtered = out. Emergency calls are examples of this as are some games and "jam = session" Like to add case where application has one two video streams but one is = far more important than the other. Should be a way to make sure that = preferential treatment is given the the important stream over the less = important streams.=20 In F22, "the IVR" -> "an DTMF based IVR" I have a hard time deciding what level the requirements should be at. It = seems likely that given the level they are currently at, the = requirements are somewhat incomplete. As long as we treat these as = partial set of requirements derived from the use cases, I'm fine with = that.=20 New use case: Imagine a service like webex that facilitates collaboration between two = companies called A and B. Webex has no need to see the content of the = communication from A to B. So webex might run the web server that helps = set up a RTCWeb session between A and B, but webex needs to be able to = write it's code such that it does not get the keying material used to = encrypt the media from A to B and the companies need to be able to = verify that webex did not get the keys. Webex has no need to see the = media from A to B and if it can provide this sort of promise that it = does not get the media, it makes it much easier for a customer (say = Juniper) to use webex and know the contents of their calls are not being = sold or used by a competitor. Given how much WebRTC will be used by = cloud services, this is an important feature. When installing the = "webex" application in the browser and granting permissions to the = application, it would be good to have one of the permissions be if the = JS got access to the media or keying material for it to enforce this = promise.=20 Note this use case is not phrase to say this is the only way it can = work. This is not mutually exclusive with they type of use cases = described by Skype folks where there is an explicitly desire to make = sure the calling service does have the keys to decrypt the media.=20 From Milan.Young@nuance.com Tue May 15 18:37:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1E11E809A for ; Tue, 15 May 2012 18:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klBCQQflV0hZ for ; Tue, 15 May 2012 18:37:57 -0700 (PDT) Received: from som-mx-a.nuance.com (som-mx-a.nuance.com [198.71.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7511E8095 for ; Tue, 15 May 2012 18:37:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0EAIUDs08KHBQZ/2dsb2JhbABEsWODJ4IVAQEBBDolGgwEAgEIDQEDBAEBAQoUCQcyFAkIAQEEAQ0FCIYKvSOLHIR1YwScFI0SgV8 Received: from unknown (HELO SOM-CAS02.nuance.com) ([10.28.20.25]) by som-mx-a.nuance.com with ESMTP/TLS/AES128-SHA; 15 May 2012 21:22:31 -0400 Received: from SOM-CAS03.nuance.com (10.28.20.26) by SOM-CAS02.nuance.com (10.28.20.25) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 15 May 2012 21:37:55 -0400 Received: from SOM-EXCH04.nuance.com ([fe80::b1be:1c21:d7f8:543c]) by SOM-CAS03.nuance.com ([::1]) with mapi id 14.02.0283.003; Tue, 15 May 2012 21:37:55 -0400 From: "Young, Milan" To: Eric Rescorla , Ralph Giles Thread-Topic: [rtcweb] TCP vs UDP for media Thread-Index: Ac0y8YFlKfCoI+0LRZ2tsFbI0SJeNwAI96AAAABJd4AABPKcoA== Date: Wed, 16 May 2012 01:37:54 +0000 Message-ID: References: <4FB2E8FC.40404@thaumas.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.16.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 01:37:58 -0000 Yes, existing web technologies for transport would work fine. In fact I wr= ote a demo based on WebSockets, the AudioAPI, and getUserMedia. But it's a= bit cludgy and only transmits PCM audio. Would my use case for live access to an encoded media stream be a good fit = for a revised MediaStreamRecorder? Would this group the right place to hos= t such an effort? Thanks -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Tuesday, May 15, 2012 4:47 PM To: Ralph Giles Cc: Young, Milan; rtcweb@ietf.org Subject: Re: [rtcweb] TCP vs UDP for media On Tue, May 15, 2012 at 4:38 PM, Ralph Giles wrote: > On 12-05-15 4:22 PM, Young, Milan wrote: > >> I'm wondering if any thought has been given to TCP as a media transport. > > Where low latency transmission isn't an issue, one can generally fall=20 > back to established TCP-based protocols, like HTTP streaming and=20 > websockets, so we haven't really worried about that angle in the=20 > context of webrtc. > > Recording the stream is a requirement, so probably something could be=20 > built using that, merging recordings from each endpoint to fix up any=20 > dropped packets. Agreed. This seems like something that could be done using just getUserMedia() plus existing Web technologies. -Ekr From magnus.westerlund@ericsson.com Tue May 15 23:44:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA9021F867E for ; Tue, 15 May 2012 23:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRfiJgu9W1t6 for ; Tue, 15 May 2012 23:44:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE821F86EF for ; Tue, 15 May 2012 23:44:00 -0700 (PDT) X-AuditID: c1b4fb25-b7c5aae000007a47-3e-4fb34cae5776 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3B.1A.31303.EAC43BF4; Wed, 16 May 2012 08:43:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 16 May 2012 08:43:58 +0200 Message-ID: <4FB34CAD.80103@ericsson.com> Date: Wed, 16 May 2012 08:43:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Young, Milan" References: <4FB2E8FC.40404@thaumas.net> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 06:44:01 -0000 On 2012-05-16 03:37, Young, Milan wrote: > Yes, existing web technologies for transport would work fine. In > fact I wrote a demo based on WebSockets, the AudioAPI, and > getUserMedia. But it's a bit cludgy and only transmits PCM audio. > > Would my use case for live access to an encoded media stream be a > good fit for a revised MediaStreamRecorder? Would this group the > right place to host such an effort? I think this is something you should take to the W3C. As it appear to be primarily an API question. Getting access to the content in the JS application or request the browser to record to a local file which later can be uploaded it would not be in this WG. Cheers Magnus Westerlund WG chair > > Thanks > > -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Tuesday, May 15, 2012 4:47 PM To: Ralph Giles Cc: Young, > Milan; rtcweb@ietf.org Subject: Re: [rtcweb] TCP vs UDP for media > > On Tue, May 15, 2012 at 4:38 PM, Ralph Giles > wrote: >> On 12-05-15 4:22 PM, Young, Milan wrote: >> >>> I'm wondering if any thought has been given to TCP as a media >>> transport. >> >> Where low latency transmission isn't an issue, one can generally >> fall back to established TCP-based protocols, like HTTP streaming >> and websockets, so we haven't really worried about that angle in >> the context of webrtc. >> >> Recording the stream is a requirement, so probably something could >> be built using that, merging recordings from each endpoint to fix >> up any dropped packets. > > Agreed. This seems like something that could be done using just > getUserMedia() plus existing Web technologies. > > -Ekr _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed May 16 07:10:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5B21F8622 for ; Wed, 16 May 2012 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.153 X-Spam-Level: X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIUgC4vSJ3Qy for ; Wed, 16 May 2012 07:10:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 360C321F85CF for ; Wed, 16 May 2012 07:10:42 -0700 (PDT) X-AuditID: c1b4fb30-b7be1ae0000059fc-88-4fb3b560f936 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A5.8B.23036.065B3BF4; Wed, 16 May 2012 16:10:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 16 May 2012 16:10:40 +0200 Message-ID: <4FB3B55F.3080607@ericsson.com> Date: Wed, 16 May 2012 16:10:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> In-Reply-To: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------080101040300000800030606" X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:10:43 -0000 --------------080101040300000800030606 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, This is an individual contribution on how to do codec control in WebRTC. Ericsson has an current IPR statment on the referenced Codec Operation Points RTCP extension. This statement will be updated, hopefully next week, with new terms making it a non-asssert statement for implementation in webbrowsers and FRAND for other usages. I will send a pointer when the official statement is available. Cheers Magnus --------------080101040300000800030606 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-rtcweb-codec-control-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="I-D Action: draft-westerlund-rtcweb-codec-control-00_txt.eml" X-Mozilla-Keys: Received: from sessmg11.ericsson.net (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.86) with Microsoft SMTP Server id 8.3.213.0; Wed, 16 May 2012 16:02:40 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 78.E2.22539.083B3BF4; Wed, 16 May 2012 16:02:40 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3A821F8470; Wed, 16 May 2012 07:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83421F854C for ; Wed, 16 May 2012 07:02:29 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtBp14BU5eH2 for ; Wed, 16 May 2012 07:02:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CC621F8470 for ; Wed, 16 May 2012 07:02:28 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Wed, 16 May 2012 16:02:28 +0200 Subject: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt Thread-Topic: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt Thread-Index: Ac0zbI7GnVhZ55DQRQC9OLvpbj2DrQ== Message-ID: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0191.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3d-b7f286d00000580b-7b-4fb3b37fdbdc x-brightmail-tracker: H4sIAAAAAAAAA1VSa0hTYRj2O+ds5zR27HNavloZTSTtYopBp1JbRSVC6J/6IUTNOrnhNmVn iv0IvFSQYXSheUHnpBtel26l1Y9yQWQFmXazzNRMbKVFkVgWds6Odvn3vDzP+zzPCy9DajqU 4QxfYOOtFr1Jq1RR6oUbIlYXut1pcR/bo7ni1x6aK+p/S3BFxQLX+G4r1+MaILhR+08l98rR T3MV1d9prvxoEjd1s0mhU6X8+PZUmY4yVIkHeJMxn7euSd6nMpy8doLIdbEFv2qHiEL0WVWK 5jGA18KD7n4k44XQPeBSliIVo8EdCN54780O5Qh6n/XR0kDhXyR8qG+h5JUVcPn+c0LCFI6B mbvHFPKGB8GtquukLIqGivpuMYMR8Xxo9kbOxVWfbVbKOBAej00RMs6FijOdtOzzEsEzd9Gs qRtB61eXQlKxOAi6Kkf8LZQ4Ahp9dv8RITgMqh7W0BIOxpvhqvPEbIkQmHg6RM4ldzqnkeyj g6b6UUoqR+Eo6GpfKUu0MHPsLC3jMCgtG/FjjDE4Llz3F9WIGru9z2+jxlugZmKAkHqqcQmC 4iqHQvJUix2OTO+WNTHQ98gxq0+GhnIPfQpFVf1zjYRJvAqcN78oZbwU2serSSciG9ACgRcE c1Z8fCxvNe4XhBxLrIW3tSHxXTo900kd6F7LOi8KYwjtAvaIy52mCczMOXDIoBcMe615Jl7w okUMpQ1lk44fTtPgLL2Nz+b5XN46xy5mGC2wl1rFzSArn8UXHDSabH9pgpnnRcCotSHsE0nD Crl6s2DMkvn7aFl4KOuVCCwRhjzLn925h+5BS8KDWRQQEKBRi7lmo+1/3odCGaQNZmslF7XR Yvvj7hODCTE439wmBdv0f6nwQlRm0lRmflJsGu5dnzASd/mcIuP9u8CZfNPAbd2Vlh2p2XsW x5vvvGr1jXsiQsyjZ6ht9pSU7T/6hicneybnnx+srNu560Xo6TLy6oXN3a1jkXUl9qnEJS7d 4I1K3bSPv5hQkzHEPjQ6IrsKeqPpuOMThSVN6RW9yze2p94YdhYNTWgpwaCPX0FaBf1vXqqO tssDAAA= dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337176951; bh=JrWkmO6N9TkgHIL0LYesh+uCDKvH4DiUVeVNnFfr77o=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=u6doaZi+3UmdtLEADao6NDYfPfdRi07nj5poGSKFoFH1v6RsK+YeVuyeWAZW40DSH Rrqo+iccMFEDXJurI8nAxqyp9IPdKVq2hSLYbE+A3zajPbp3AvX9Jv4lJ7BkTVEBDz VwRaNYwl39BD+2600kTMpSMgyBPn36uCKzUWn/Ag= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Internet Draft Announcements only x-beenthere: i-d-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.599 x-spam-flag: NO delivered-to: i-d-announce@ietfa.amsl.com x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Codec Control for WebRTC Author(s) : Magnus Westerlund Bo Burman Filename : draft-westerlund-rtcweb-codec-control-00.txt Pages : 18 Date : 2012-05-16 This document proposes how WebRTC should handle media codec control between peers. With media codec control we mean such parameters as video resolution and frame-rate. This includes both initial establishment of capabilities using the SDP based JSEP signalling and during ongoing real-time interactive sessions in response to user and application events. The solution uses SDP for initial boundary establishment that are rarely, if ever changed. During the session the RTCP based Codec Operations Point (COP) signaling solution is used for dynamic control of parameters enabling timely and responsive controls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-rtcweb-codec-control-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-westerlund-rtcweb-codec-control-00= .txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-westerlund-rtcweb-codec-control/ _______________________________________________ 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 --------------080101040300000800030606-- From martin.thomson@gmail.com Wed May 16 11:56:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B713C21F8620 for ; Wed, 16 May 2012 11:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 6aSXJvcIZbRj for ; Wed, 16 May 2012 11:56:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46121F85FB for ; Wed, 16 May 2012 11:56:16 -0700 (PDT) Received: by bkty8 with SMTP id y8so1067318bkt.31 for ; Wed, 16 May 2012 11:56:15 -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=CuBzwE66wdSAXD3HIrEGQ/4MwNoTJZv0h43WB9OOUrk=; b=afF4SMNORr/4w5t6NGGtHPdL+izlvPAdZzXpTvGokoBYkLNYKqX7/hWVSXvwV/khkU b0HTKtUfP01lV4Qor62Qxeh9p4nRvf5kx2Kr0ub6XanoWRhrMX04LlatEP+aBv98VnC0 20uaCelWMQhyZDjxZzgj6kzR7ipUnoCfXPNcAfFss1Y2/pjnGntSBlnaEnSfHSHdit8G K+5fOk8U0ManPKrvcUnBb6xTuEGlZ4D/uVuhMz7dY0jcopc/nQO+FOJ4u5c68hY7aUCK uUMo9C2HQezEhzVRj92j3s9vyNMVrzoED3ayJoVHhbuJfv0+eC9whMPf2AAp9Wys6WSZ M+2A== MIME-Version: 1.0 Received: by 10.204.152.13 with SMTP id e13mr1692524bkw.46.1337194575539; Wed, 16 May 2012 11:56:15 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Wed, 16 May 2012 11:56:15 -0700 (PDT) Date: Wed, 16 May 2012 11:56:15 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Relaying for privacy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:56:17 -0000 On 15 May 2012 18:31, Cullen Jennings wrote: > Might want to add to some use case that when A calls B, and B does not reveal their IP address to A. I agree, but it's questionable whether this is something we (ietf/w3c...browsers) need to solve the problem or whether we can rely on sites respecting privacy appropriately. Obviously, it's quite simple to allocate a relay for all new sessions in the browser. The hard part is knowing when it is OK to reveal host/reflexive candidates so that the call can proceed without relaying. - Is it when the user grants permission for the site to use microphone/camera? This seems wrong. An individual desire for privacy is often based on who is asking, which in this case is A, not the site. It's plausible that the site can be given permission to access mic/camera prior to the call arriving. - Is it when the user indicates acceptance of the call? I don't think that the plan is to signal acceptance through chrome, so this would have to rely on cues from the site, such as calling createAnswer. At that point, if the site wants the media off the relay, they now have an incentive to fake acceptance. The same applies to relying on any other cues from the site, including faking the _initiation_ of the call, which can be done from both A and B. - Is there special chrome that enables this? Adding more chrome doesn't sound like a great idea to me, but maybe this behaviour could be tied to the various "private/incognito mode" options in the browser. I did have another related thought, but distractions erased it. From juberti@google.com Wed May 16 14:54:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36569E8020 for ; Wed, 16 May 2012 14:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyS8sMRWjk4e for ; Wed, 16 May 2012 14:54:42 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4521F8773 for ; Wed, 16 May 2012 14:54:42 -0700 (PDT) Received: by qabj40 with SMTP id j40so1306535qab.15 for ; Wed, 16 May 2012 14:54:38 -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:x-system-of-record; bh=M4fkmGLe10eeXOBG08Dpys+0VGzAZt7koJHQYngI9VA=; b=V4xBpEdqK5jcxs1j8hleLT5uB9mBj4VVCEwZs4yJgpKEtmSAXJ1zUdWigQaCm6Utd3 KdwVo8AyhJ1q3JhQryC9BD6iKxQihwbf+pH/AYTJRT9UZkqIGl468nMntaXOoPDVxd7D SitXgv4i8jPqNTaMXwDIVbRBDW/D9lmpKT3XFAGWW1SqgUytr71BOL4xaXKnGsTtHtw9 swwoHGPF2QLvFgFRJ1X2rCGd5jrE7qxjLT1lYBc7m4b1qJmVY4dxtHOjdQ1Wb8KERlKR 0MXJXnkGFDcbAnDefTb+/BH5Yj3Vju2eeI3R/m0LUrzs/03NjSzOxZy8EZopuUR5eReD j7jA== 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-system-of-record:x-gm-message-state; bh=M4fkmGLe10eeXOBG08Dpys+0VGzAZt7koJHQYngI9VA=; b=SxHS6w/8SAy+QEFWtWRJgbpBgmFhpTDMw2sRI4ixptLDoTprApjgSmy6pEUN5/xrKi RixOp+r5O6+D6QzXZYDgoBu1sOgAKeqaRljh2nfDCVTkb18cyYGfD91aNMxqkW9YEoCf LVD0YLJOtXsng2kAYi/ur9cmYsUH0g2rvinBiKMTWlfgZtJcSixbwfkfB3XXxdWsQw7v PsYo7kwEguVo3Kqo9hNPp9e/GZvY+3mxZ7abr7O7zXJXya8PPVjpguS88g60DqH7RHaM mO2t34GYyPlj4UjAsVccEOoATjI4yTjh6dhU9l1BKFhUCOVK7kaI14Q7lneLEBnKkJh9 P6LA== Received: by 10.224.191.3 with SMTP id dk3mr12580998qab.99.1337205278294; Wed, 16 May 2012 14:54:38 -0700 (PDT) Received: by 10.224.191.3 with SMTP id dk3mr12580971qab.99.1337205278004; Wed, 16 May 2012 14:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.102.154 with HTTP; Wed, 16 May 2012 14:54:17 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 16 May 2012 17:54:17 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3005dcc896566a04c02e5df6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn3XVUaOaEELTkrQOXRzgaGfN/aiKD1Gsn3EA4CePNa9gELpNFYvNotvkvfEjIhdLx9ekUpXYUl0eFX5YGQA2UPMup8Akw8TymjNEuvEE9ozT3v9azTBBLFa+xbvd2boqkTrh1P Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaying for privacy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:54:46 -0000 --20cf3005dcc896566a04c02e5df6 Content-Type: text/plain; charset=UTF-8 My view was that we need to make it _possible_ for sites to respect privacy (via the API), and provide documentation that encourages sites to do so. As you point out, I think it's difficult for the browser to automatically figure out what to do here, and when to do it. The identity of the "called" user may not be a factor in certain applications (e.g. some p2p game), making it unclear as to whether forcing use of relay is even the right thing to do. On Wed, May 16, 2012 at 2:56 PM, Martin Thomson wrote: > On 15 May 2012 18:31, Cullen Jennings wrote: > > Might want to add to some use case that when A calls B, and B does not > reveal their IP address to A. > > I agree, but it's questionable whether this is something we > (ietf/w3c...browsers) need to solve the problem or whether we can rely > on sites respecting privacy appropriately. > Obviously, it's quite simple to allocate a relay for all new sessions > in the browser. The hard part is knowing when it is OK to reveal > host/reflexive candidates so that the call can proceed without > relaying. > > - Is it when the user grants permission for the site to use > microphone/camera? This seems wrong. An individual desire for > privacy is often based on who is asking, which in this case is A, not > the site. It's plausible that the site can be given permission to > access mic/camera prior to the call arriving. > > - Is it when the user indicates acceptance of the call? I don't > think that the plan is to signal acceptance through chrome, so this > would have to rely on cues from the site, such as calling > createAnswer. At that point, if the site wants the media off the > relay, they now have an incentive to fake acceptance. The same > applies to relying on any other cues from the site, including faking > the _initiation_ of the call, which can be done from both A and B. > > - Is there special chrome that enables this? Adding more chrome > doesn't sound like a great idea to me, but maybe this behaviour could > be tied to the various "private/incognito mode" options in the > browser. > > I did have another related thought, but distractions erased it. > --20cf3005dcc896566a04c02e5df6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My view was that we need to make it _possible_ for sites to respect privacy= (via the API), and provide documentation that encourages sites to do so. A= s you point out, I think it's difficult for the browser to automaticall= y figure out what to do here, and when to do it.

The identity of the "called" user may not be a fac= tor in certain applications (e.g. some p2p game), making it unclear as to w= hether forcing use of relay is even the right thing to do.

On Wed, May 16, 2012 at 2:56 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 15 May 2012 18:31, Cullen Jennings <fluffy@cisco.com> wrote:
> Might want to add to some use case that when A calls B, and B does not= reveal their IP address to A.

I agree, but it's questionable whether this is something we
(ietf/w3c...browsers) need to solve the problem or whether we can rely
on sites respecting privacy appropriately.

Obviously, it's quite simple to allocate a relay for all new sessions in the browser. =C2=A0The hard part is knowing when it is OK to reveal
host/reflexive candidates so that the call can proceed without
relaying.

=C2=A0- Is it when the user grants permission for the site to use
microphone/camera? =C2=A0This seems wrong. =C2=A0An individual desire for privacy is often based on who is asking, which in this case is A, not
the site. =C2=A0It's plausible that the site can be given permission to=
access mic/camera prior to the call arriving.

=C2=A0- Is it when the user indicates acceptance of the call? =C2=A0I don&#= 39;t
think that the plan is to signal acceptance through chrome, so this
would have to rely on cues from the site, such as calling
createAnswer. =C2=A0At that point, if the site wants the media off the
relay, they now have an incentive to fake acceptance. =C2=A0The same
applies to relying on any other cues from the site, including faking
the _initiation_ of the call, which can be done from both A and B.

=C2=A0- Is there special chrome that enables this? =C2=A0Adding more chrome=
doesn't sound like a great idea to me, but maybe this behaviour could be tied to the various "private/incognito mode" options in the browser.

I did have another related thought, but distractions erased it.
--20cf3005dcc896566a04c02e5df6-- From ekr@rtfm.com Wed May 16 15:10:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84F721F867F for ; Wed, 16 May 2012 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wl5Sb8cV1gVV for ; Wed, 16 May 2012 15:10:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3921F8670 for ; Wed, 16 May 2012 15:10:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1396163vbb.31 for ; Wed, 16 May 2012 15:10:23 -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=jEBod5UjqxdVqKyYbHn8PufBFdLMq4wvPQsMXRD+5c4=; b=YsXrjKn+eNTc+OxV9ZMkHKW5hDp2eXZ953Toa5zvOosHKJOR8HSbTcT82A7TmZe3NI HCEfyMfQzrTjJ0Ds/01/2vNdqhgK+wDa6yQnOC5+phseLEdZEG7yLXiL8ilQu8TljMPe HuSl+rOTUjAOYcYzJj4IYetmY9SSb3YeIJxO84/qU3V1j4Sf956W+oiPZITsS+YiDoi0 sQFSIKMZdvnDxIXJRA6Y8Xi+BzURtuQxrhGazZSeUPpcyc1TICuMSCN6ucKqPgN1+/lP dIhb7frF+UdudmuM9/XxRv/ffGD07oMOAUrNBWKSuzKlwWWTHoFJd5poUrIm+I0PwK62 LY+Q== Received: by 10.220.141.79 with SMTP id l15mr3555249vcu.48.1337206223490; Wed, 16 May 2012 15:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 15:09:43 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 16 May 2012 15:09:43 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqpYWdZYJ7od3HPaoomUGM0HdDs55nfkmuYHSUMwrueOo9VsDiyqk3JnArtRY4pIBi4fZe Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaying for privacy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:10:26 -0000 On Wed, May 16, 2012 at 2:54 PM, Justin Uberti wrote: > My view was that we need to make it _possible_ for sites to respect privacy > (via the API), and provide documentation that encourages sites to do so. As > you point out, I think it's difficult for the browser to automatically > figure out what to do here, and when to do it. > > The identity of the "called" user may not be a factor in certain > applications (e.g. some p2p game), making it unclear as to whether forcing > use of relay is even the right thing to do. I concur with all this. I think it's also important to reiterate that this is about the site cooperating to protect your privacy. If you want to protect the user's IP address from the site, then the user needs to use Torbutton or some such. And I would want Torbutton to arrange relay my RTCWEB traffic as well (though likely that can't go through Tor for performance reasons). -Ekr From ekr@rtfm.com Wed May 16 19:07:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1818911E80A0 for ; Wed, 16 May 2012 19:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 N5JCdOFxO4iU for ; Wed, 16 May 2012 19:07:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63BED11E809D for ; Wed, 16 May 2012 19:07:20 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1914285pbc.31 for ; Wed, 16 May 2012 19:07:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=fuj9JcBHdFNguKSrNlghc63/C24l6MVosm9BXh101CQ=; b=T04yTakVc+Ka5DlPWq6Lzq/fzcPP0PQJOVtS0rb15euZxCdIvqWGeZpY/GZgbt5odt kxhluMDdK6LmXTXqqYj7/MzRsJUdGUwwGm5gzETNBa8bItIobAIzNNiiUnMau35QeLmG Nx1iqlRRHtpEXg5l2wXex2svdgIwCoMdU+/rnHpsL53wMfWValwqFJFxXV+gBHlO78eJ jH+kuo0nM6h3nKbqWbwanfIbHmie5hoqhNDuwzer2iNfLJd82wSV2iBRCB+ei/y8oz9L 6hZRqJuwGab8aS0SEUIQXpTeQS1Kj1oRWKsJZFR+7AHzjuKatUX+jz3t4JgK4HNi3xU2 yXiw== Received: by 10.68.220.97 with SMTP id pv1mr22033942pbc.158.1337220440058; Wed, 16 May 2012 19:07:20 -0700 (PDT) Received: from [10.107.108.44] (mobile-166-205-138-181.mycingular.net. [166.205.138.181]) by mx.google.com with ESMTPS id rj4sm7382776pbc.30.2012.05.16.19.07.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 19:07:19 -0700 (PDT) References: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> In-Reply-To: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Eric Rescorla Date: Wed, 16 May 2012 19:07:15 -0700 To: =?utf-8?Q?=E9=82=93=E7=81=B5=E8=8E=89/denglingli?= X-Gm-Message-State: ALoCoQl0ZaquY/SIZPawbf44J+W5RRsYOYwyk7yVaydWLEMTF+XgsRq8aJKJL0xPm5kWzJdQpcCt Cc: "" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiAgUmVsYXlpbmcgZm9yIHByaXZhY3k=?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:07:21 -0000 Yes. Tor is too slow to do voice effectively. I would expect torbutton or a t= orbutton-like to route media through a turn server. This will provide worse p= rivacy than onion routing but better than just letting the server control th= e routing. Ekr On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: > Hi, Ekr >=20 > I agree with you about the Martin's comments.=20 > For the proposal of Torbutton, I have a concern about the employment of > union routing (encrypting and decrypting several times between the relayin= g > nodes along the way) in Tor would be not acceptable to the RTC requirement= s > of VoIP use-cases. > Would this be an issue? >=20 > BR > Lingli >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bounce= s@ietf.org] =E4=BB=A3=E8=A1=A8 Eric > Rescorla > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 6= :10 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti > =E6=8A=84=E9=80=81: rtcweb@ietf.org > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy >=20 > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti wrote:= >> My view was that we need to make it _possible_ for sites to respect=20 >> privacy (via the API), and provide documentation that encourages sites=20= >> to do so. As you point out, I think it's difficult for the browser to=20 >> automatically figure out what to do here, and when to do it. >>=20 >> The identity of the "called" user may not be a factor in certain=20 >> applications (e.g. some p2p game), making it unclear as to whether=20 >> forcing use of relay is even the right thing to do. >=20 > I concur with all this. >=20 > I think it's also important to reiterate that this is about the site > cooperating to protect your privacy. If you want to protect the user's IP > address from the site, then the user needs to use Torbutton or some such. > And I would want Torbutton to arrange relay my RTCWEB traffic as well > (though likely that can't go through Tor for performance reasons). >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > __________ Information from ESET NOD32 Antivirus, version of virus signatu= re > database 7138 (20120515) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 >=20 >=20 From denglingli@chinamobile.com Wed May 16 22:54:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B6511E8072 for ; Wed, 16 May 2012 22:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.474 X-Spam-Level: *** X-Spam-Status: No, score=3.474 tagged_above=-999 required=5 tests=[AWL=3.399, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2RiHw0qivtL for ; Wed, 16 May 2012 22:54:04 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E883411E8074 for ; Wed, 16 May 2012 22:54:03 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3C4AFE3E1; Thu, 17 May 2012 13:54:02 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 08F0BE418; Thu, 17 May 2012 13:54:02 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051713535820-9257 ; Thu, 17 May 2012 13:53:58 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Eric Rescorla'" References: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> In-Reply-To: Date: Thu, 17 May 2012 13:50:50 +0800 Message-ID: <007b01cd33f1$03ccc9e0$0b665da0$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 thread-index: AQOWUPS/+dPCoF+Z3hDd15zfqfrP3gGXCdiKAmtQQSMB6bN4BgJlA+BVkvi0qMA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 13:53:58, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 13:54:01, Serialize complete at 2012-05-17 13:54:01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18910.004 X-TM-AS-Result: No--33.961-7.0-31-10 X-imss-scan-details: No--33.961-7.0-31-10;No--33.961-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBSZWxheWluZyBmb3IgcHJp?= =?utf-8?q?vacy?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 05:54:05 -0000 It makes sense to me. However, considering the relaying burden would not be trivial, I'd = further prefer that the enable/disable button be dedicatedly set for the = RTCWEB instance in question, rather than the whole pack of connections = of the browsers.=20 In other words, it is better to be triggered at the time of page-loading = for the RTCWEB app for a global configuration (keeping current IP = privacy for all callers) or when called by for a specific configuration = (keeping privacy for the incoming caller).=20 In either cases, the setting can be done through getusermedia as Martin = said. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 = 10:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: Justin Uberti; =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for = privacy Yes. Tor is too slow to do voice effectively. I would expect torbutton = or a torbutton-like to route media through a turn server. This will = provide worse privacy than onion routing but better than just letting = the server control the routing. Ekr On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli = wrote: > Hi, Ekr >=20 > I agree with you about the Martin's comments.=20 > For the proposal of Torbutton, I have a concern about the employment=20 > of union routing (encrypting and decrypting several times between the=20 > relaying nodes along the way) in Tor would be not acceptable to the=20 > RTC requirements of VoIP use-cases. > Would this be an issue? >=20 > BR > Lingli >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric=20 > Rescorla > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 6:10 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti > =E6=8A=84=E9=80=81: rtcweb@ietf.org > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy >=20 > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti = wrote: >> My view was that we need to make it _possible_ for sites to respect=20 >> privacy (via the API), and provide documentation that encourages=20 >> sites to do so. As you point out, I think it's difficult for the=20 >> browser to automatically figure out what to do here, and when to do = it. >>=20 >> The identity of the "called" user may not be a factor in certain=20 >> applications (e.g. some p2p game), making it unclear as to whether=20 >> forcing use of relay is even the right thing to do. >=20 > I concur with all this. >=20 > I think it's also important to reiterate that this is about the site=20 > cooperating to protect your privacy. If you want to protect the user's = > IP address from the site, then the user needs to use Torbutton or some = such. > And I would want Torbutton to arrange relay my RTCWEB traffic as well=20 > (though likely that can't go through Tor for performance reasons). >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > __________ Information from ESET NOD32 Antivirus, version of virus=20 > signature database 7138 (20120515) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 >=20 >=20 __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From denglingli@chinamobile.com Wed May 16 22:59:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF3721F8652 for ; Wed, 16 May 2012 22:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.794 X-Spam-Level: ** X-Spam-Status: No, score=2.794 tagged_above=-999 required=5 tests=[AWL=2.720, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WrGbkFRvBd8 for ; Wed, 16 May 2012 22:59:49 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20C21F8644 for ; Wed, 16 May 2012 22:59:49 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A5B63F414; Thu, 17 May 2012 13:59:48 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 9A905F404; Thu, 17 May 2012 13:59:48 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051713594641-9420 ; Thu, 17 May 2012 13:59:46 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Eric Rescorla'" References: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> <007b01cd33f1$03ccc9e0$0b665da0$@chinamobile.com> In-Reply-To: <007b01cd33f1$03ccc9e0$0b665da0$@chinamobile.com> Date: Thu, 17 May 2012 13:56:38 +0800 Message-ID: <007c01cd33f1$d2dc4bc0$7894e340$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 thread-index: AQOWUPS/+dPCoF+Z3hDd15zfqfrP3gGXCdiKAmtQQSMB6bN4BgJlA+BVAYaREbuS7IQO8A== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 13:59:46, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 13:59:48, Serialize complete at 2012-05-17 13:59:48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18910.004 X-TM-AS-Result: No--36.703-7.0-31-10 X-imss-scan-details: No--36.703-7.0-31-10;No--36.703-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06ICBSZWxheWlu?= =?utf-8?q?g_for_privacy?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 05:59:50 -0000 Sorry, by " In either cases, the setting can be done through = getusermedia as Martin said." I mean " In either cases, the setting = could be done through getusermedia as Martin said." Since according to our experience with chrome so far, media relaying = through turn is not yet supported. Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 = =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 = 13:51 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' =E6=8A=84=E9=80=81: rtcweb@ietf.org =E4=B8=BB=E9=A2=98: [rtcweb] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: = Relaying for privacy It makes sense to me. However, considering the relaying burden would not be trivial, I'd = further prefer that the enable/disable button be dedicatedly set for the = RTCWEB instance in question, rather than the whole pack of connections = of the browsers.=20 In other words, it is better to be triggered at the time of page-loading = for the RTCWEB app for a global configuration (keeping current IP = privacy for all callers) or when called by for a specific configuration = (keeping privacy for the incoming caller).=20 In either cases, the setting can be done through getusermedia as Martin = said. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 = 10:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: Justin Uberti; =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for = privacy Yes. Tor is too slow to do voice effectively. I would expect torbutton = or a torbutton-like to route media through a turn server. This will = provide worse privacy than onion routing but better than just letting = the server control the routing. Ekr On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli = wrote: > Hi, Ekr >=20 > I agree with you about the Martin's comments.=20 > For the proposal of Torbutton, I have a concern about the employment=20 > of union routing (encrypting and decrypting several times between the=20 > relaying nodes along the way) in Tor would be not acceptable to the=20 > RTC requirements of VoIP use-cases. > Would this be an issue? >=20 > BR > Lingli >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric=20 > Rescorla > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 6:10 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti > =E6=8A=84=E9=80=81: rtcweb@ietf.org > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy >=20 > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti = wrote: >> My view was that we need to make it _possible_ for sites to respect=20 >> privacy (via the API), and provide documentation that encourages=20 >> sites to do so. As you point out, I think it's difficult for the=20 >> browser to automatically figure out what to do here, and when to do = it. >>=20 >> The identity of the "called" user may not be a factor in certain=20 >> applications (e.g. some p2p game), making it unclear as to whether=20 >> forcing use of relay is even the right thing to do. >=20 > I concur with all this. >=20 > I think it's also important to reiterate that this is about the site=20 > cooperating to protect your privacy. If you want to protect the user's = > IP address from the site, then the user needs to use Torbutton or some = such. > And I would want Torbutton to arrange relay my RTCWEB traffic as well=20 > (though likely that can't go through Tor for performance reasons). >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > __________ Information from ESET NOD32 Antivirus, version of virus=20 > signature database 7138 (20120515) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 >=20 >=20 __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu May 17 18:05:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250FB21F872D for ; Thu, 17 May 2012 18:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yfcPVLrmall for ; Thu, 17 May 2012 18:05:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8FA21F86E0 for ; Thu, 17 May 2012 18:05:24 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3894501obb.31 for ; Thu, 17 May 2012 18:05: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; bh=UctxcoeiAd3DdZ3cZVDxhxK9uldwrDoZU6gPbQpIWOY=; b=IhPwAOVlI3sZezDsAqDOW9ETV1JG1n/+JgDRAjk01JKVyzzkxrlnn7+E0t601VmcvB zyS3FszyuEaibXucGxAaUa1oJQ/t9SIAqvddyS401dpzZwqZ6/WcnqD2KY9j25iI01zg G4fhMcRuRmdgkglqRmXL8Lw3NlrfMhbaQIF64GN3gNxMiQhKF5I/7rOc1ikPLo89mXQ/ bsMCIVJRze13RDQyXyLb2BQD4N+Z2OxhhCAuvoSAKOXSjvsIp4Y/nRq3myPHkMj2PJoL PJBpQvZ3DJOxSc3Z72CmwHugUf49ZVMT3WSwgibV1KpacJrrt3bPOPLCjvWafRzDEcGM Mtkg== MIME-Version: 1.0 Received: by 10.182.167.101 with SMTP id zn5mr8710843obb.13.1337303123996; Thu, 17 May 2012 18:05:23 -0700 (PDT) Received: by 10.182.174.67 with HTTP; Thu, 17 May 2012 18:05:23 -0700 (PDT) Received: by 10.182.174.67 with HTTP; Thu, 17 May 2012 18:05:23 -0700 (PDT) In-Reply-To: <007c01cd33f1$d2dc4bc0$7894e340$@chinamobile.com> References: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> <007b01cd33f1$03ccc9e0$0b665da0$@chinamobile.com> <007c01cd33f1$d2dc4bc0$7894e340$@chinamobile.com> Date: Thu, 17 May 2012 18:05:23 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= Content-Type: multipart/alternative; boundary=e89a8f83a703a9b22004c04525ce Cc: rtcweb@ietf.org Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogUmVsYXlpbmcg?= =?utf-8?q?for_privacy?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 01:05:26 -0000 --e89a8f83a703a9b22004c04525ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do not think that any option other than what Eric described is truly feasible. That is, of the options provided, only the one where the site has to be trusted bit to reveal your IP is likely to succeed. getUserMedia provides a cue of a fundamentally different nature to that you are looking for in this use case. getUserMedia signals that the user is ok with the site gaining access to their camera/microphone. That is a contract between the user and the site, not the two users. If you don't trust the site, then you are in Torbutton land. That is, specific UI for this. I've concluded that we don't need this requirement. There is little that a browser can sensibly do beyond something like Torbutton. And I'm not convinced that trying to replicate, or require the replication of Torbutton, is a great idea either. Tor users understand the value it provides, most other users won't care for the added complication. On May 16, 2012 10:59 PM, "=E9=82=93=E7=81=B5=E8=8E=89/denglingli" wrote: > > Sorry, by " In either cases, the setting can be done through getusermedia as Martin said." I mean " In either cases, the setting could be done through getusermedia as Martin said." > Since according to our experience with chrome so far, media relaying through turn is not yet supported. > > Lingli > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bounc= es@ietf.org] =E4=BB=A3=E8=A1=A8 =E9=82=93=E7=81=B5=E8=8E=89/denglingli > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 = 13:51 > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' > =E6=8A=84=E9=80=81: rtcweb@ietf.org > =E4=B8=BB=E9=A2=98: [rtcweb] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: Rela= ying for privacy > > It makes sense to me. > However, considering the relaying burden would not be trivial, I'd further prefer that the enable/disable button be dedicatedly set for the RTCWEB instance in question, rather than the whole pack of connections of the browsers. > In other words, it is better to be triggered at the time of page-loading for the RTCWEB app for a global configuration (keeping current IP privacy for all callers) or when called by for a specific configuration (keeping privacy for the incoming caller). > In either cases, the setting can be done through getusermedia as Martin said. > > BR > Lingli > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 = 10:07 > =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli > =E6=8A=84=E9=80=81: Justin Uberti; > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for privacy > > Yes. Tor is too slow to do voice effectively. I would expect torbutton or a torbutton-like to route media through a turn server. This will provide worse privacy than onion routing but better than just letting the server control the routing. > > Ekr > > On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: > > > Hi, Ekr > > > > I agree with you about the Martin's comments. > > For the proposal of Torbutton, I have a concern about the employment > > of union routing (encrypting and decrypting several times between the > > relaying nodes along the way) in Tor would be not acceptable to the > > RTC requirements of VoIP use-cases. > > Would this be an issue? > > > > BR > > Lingli > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bou= nces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric > > Rescorla > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97= =A5 6:10 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti > > =E6=8A=84=E9=80=81: rtcweb@ietf.org > > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy > > > > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti wrote: > >> My view was that we need to make it _possible_ for sites to respect > >> privacy (via the API), and provide documentation that encourages > >> sites to do so. As you point out, I think it's difficult for the > >> browser to automatically figure out what to do here, and when to do it= . > >> > >> The identity of the "called" user may not be a factor in certain > >> applications (e.g. some p2p game), making it unclear as to whether > >> forcing use of relay is even the right thing to do. > > > > I concur with all this. > > > > I think it's also important to reiterate that this is about the site > > cooperating to protect your privacy. If you want to protect the user's > > IP address from the site, then the user needs to use Torbutton or some such. > > And I would want Torbutton to arrange relay my RTCWEB traffic as well > > (though likely that can't go through Tor for performance reasons). > > > > -Ekr > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 7138 (20120515) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7138 (20120515) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8f83a703a9b22004c04525ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I do not think that any option other than what Eric described is truly f= easible. That is, of the options provided, only the one where the site has = to be trusted bit to reveal your IP is likely to succeed.

getUserMedia provides a cue of a fundamentally different nature to that = you are looking for in this use case. getUserMedia signals that the user is= ok with the site gaining access to their camera/microphone.=C2=A0 That is = a contract between the user and the site, not the two users.

If you don't trust the site, then you are in Torbutton land. That is= , specific UI for this.

I've concluded that we don't need this requirement. There is lit= tle that a browser can sensibly do beyond something like Torbutton.

And I'm not convinced that trying to replicate, or require the repli= cation of Torbutton, is a great idea either. Tor users understand the value= it provides, most other users won't care for the added complication.

On May 16, 2012 10:59 PM, "=E9=82=93=E7=81=B5=E8=8E=89/denglingli&q= uot; <denglingli@chinamobi= le.com> wrote:
>
> Sorry, by " In either cases, the setting can be done through getu= sermedia as Martin said." I mean " In either cases, the setting c= ould be done through getusermedia as Martin said."
> Since according to our experience with chrome so far, media relaying t= hrough turn is not yet supported.
>
> Lingli
>
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 =E9=82=93=E7=81=B5=E8= =8E=89/denglingli
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97= =A5 13:51
> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla'
> =E6=8A=84=E9=80=81: rtcweb@ietf.org=
> =E4=B8=BB=E9=A2=98: [rtcweb] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: R= elaying for privacy
>
> It makes sense to me.
> However, considering the relaying burden would not be trivial, I'd= further prefer that the enable/disable button be dedicatedly set for the R= TCWEB instance in question, rather than the whole pack of connections of th= e browsers.
> In other words, it is better to be triggered at the time of page-loadi= ng for the RTCWEB app for a global configuration (keeping current IP privac= y for all callers) or when called by for a specific configuration (keeping = privacy for the incoming caller).
> In either cases, the setting can be done through getusermedia as Marti= n said.
>
> BR
> Lingli
>
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97= =A5 10:07
> =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli > =E6=8A=84=E9=80=81: Justin Uberti; <rtcweb@ietf.org>
> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for priv= acy
>
> Yes. Tor is too slow to do voice effectively. I would expect torbutton= or a torbutton-like to route media through a turn server. This will provid= e worse privacy than onion routing but better than just letting the server = control the routing.
>
> Ekr
>
> On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli <= denglingli@chinamobile.com> wrote:
>
> > Hi, Ekr
> >
> > I agree with you about the Martin's comments.
> > For the proposal of Torbutton, I have a concern about the employm= ent
> > of union routing (encrypting and decrypting several times between= the
> > relaying nodes along the way) in Tor would be not acceptable to t= he
> > RTC requirements of VoIP use-cases.
> > Would this be an issue?
> >
> > BR
> > Lingli
> >
> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric
> > Rescorla
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817= =E6=97=A5 6:10
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti
> > =E6=8A=84=E9=80=81: rtcweb@iet= f.org
> > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy
> >
> > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti <juberti@google.com> wrote:
> >> My view was that we need to make it _possible_ for sites to r= espect
> >> privacy (via the API), and provide documentation that encoura= ges
> >> sites to do so. As you point out, I think it's difficult = for the
> >> browser to automatically figure out what to do here, and when= to do it.
> >>
> >> The identity of the "called" user may not be a fact= or in certain
> >> applications (e.g. some p2p game), making it unclear as to wh= ether
> >> forcing use of relay is even the right thing to do.
> >
> > I concur with all this.
> >
> > I think it's also important to reiterate that this is about t= he site
> > cooperating to protect your privacy. If you want to protect the u= ser's
> > IP address from the site, then the user needs to use Torbutton or= some such.
> > And I would want Torbutton to arrange relay my RTCWEB traffic as = well
> > (though likely that can't go through Tor for performance reas= ons).
> >
> > -Ekr
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
> >
> > __________ Information from ESET NOD32 Antivirus, version of viru= s
> > signature database 7138 (20120515) __________
> >
> > The message was checked by ESET NOD32 Antivirus.
> >
> > http://www.eset.com
> >
> >
> >
>
> __________ Information from ESET NOD32 Antivirus, version of virus sig= nature database 7138 (20120515) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8f83a703a9b22004c04525ce-- From denglingli@chinamobile.com Thu May 17 18:20:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4C21F881A for ; Thu, 17 May 2012 18:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[AWL=2.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoNEC2oQ43cj for ; Thu, 17 May 2012 18:20:22 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F144B21F86C6 for ; Thu, 17 May 2012 18:20:21 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 7BD1FE4C1; Fri, 18 May 2012 09:20:20 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 523F0E422; Fri, 18 May 2012 09:20:20 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051809201818-1652 ; Fri, 18 May 2012 09:20:18 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Martin Thomson'" References: <003101cd33c9$593793b0$0ba6bb10$@chinamobile.com> <007b01cd33f1$03ccc9e0$0b665da0$@chinamobile.com> <007c01cd33f1$d2dc4bc0$7894e340$@chinamobile.com> In-Reply-To: Date: Fri, 18 May 2012 09:17:09 +0800 Message-ID: <004001cd3493$f2734590$d759d0b0$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQOWUPS/+dPCoF+Z3hDd15zfqfrP3gGXCdiKAmtQQSMB6bN4BgJlA+BVAYaREbsCCsHo1wJXPF0lksq36kA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-18 09:20:18, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-18 09:20:20, Serialize complete at 2012-05-18 09:20:20 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CD34D7.0098F690" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18912.003 X-TM-AS-Result: No--55.216-7.0-31-10 X-imss-scan-details: No--55.216-7.0-31-10;No--55.216-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06IOetlOWkjTog?= =?utf-8?q?Relaying_for_privacy?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 01:20:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01CD34D7.0098F690 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" My mistake. It should be at =E2=80=9Cpeerconnection=E2=80=9D rather than = =E2=80=9Cgetusermedia=E2=80=9D in order to get what we meant. =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Martin Thomson = [mailto:martin.thomson@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8818=E6=97=A5 = 9:05 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: rtcweb@ietf.org; Eric Rescorla =E4=B8=BB=E9=A2=98: Re: [rtcweb] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: = =E7=AD=94=E5=A4=8D: Relaying for privacy =20 I do not think that any option other than what Eric described is truly = feasible. That is, of the options provided, only the one where the site = has to be trusted bit to reveal your IP is likely to succeed. getUserMedia provides a cue of a fundamentally different nature to that = you are looking for in this use case. getUserMedia signals that the user = is ok with the site gaining access to their camera/microphone. That is = a contract between the user and the site, not the two users. If you don't trust the site, then you are in Torbutton land. That is, = specific UI for this. I've concluded that we don't need this requirement. There is little that = a browser can sensibly do beyond something like Torbutton. And I'm not convinced that trying to replicate, or require the = replication of Torbutton, is a great idea either. Tor users understand = the value it provides, most other users won't care for the added = complication. On May 16, 2012 10:59 PM, "=E9=82=93=E7=81=B5=E8=8E=89/denglingli" = wrote: > > Sorry, by " In either cases, the setting can be done through = getusermedia as Martin said." I mean " In either cases, the setting = could be done through getusermedia as Martin said." > Since according to our experience with chrome so far, media relaying = through turn is not yet supported. > > Lingli > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 = =E9=82=93=E7=81=B5=E8=8E=89/denglingli > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 13:51 > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric Rescorla' > =E6=8A=84=E9=80=81: rtcweb@ietf.org > =E4=B8=BB=E9=A2=98: [rtcweb] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: = Relaying for privacy > > It makes sense to me. > However, considering the relaying burden would not be trivial, I'd = further prefer that the enable/disable button be dedicatedly set for the = RTCWEB instance in question, rather than the whole pack of connections = of the browsers. > In other words, it is better to be triggered at the time of = page-loading for the RTCWEB app for a global configuration (keeping = current IP privacy for all callers) or when called by for a specific = configuration (keeping privacy for the incoming caller). > In either cases, the setting can be done through getusermedia as = Martin said. > > BR > Lingli > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 10:07 > =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli > =E6=8A=84=E9=80=81: Justin Uberti; > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for = privacy > > Yes. Tor is too slow to do voice effectively. I would expect torbutton = or a torbutton-like to route media through a turn server. This will = provide worse privacy than onion routing but better than just letting = the server control the routing. > > Ekr > > On May 16, 2012, at 18:06, =E9=82=93=E7=81=B5=E8=8E=89/denglingli = wrote: > > > Hi, Ekr > > > > I agree with you about the Martin's comments. > > For the proposal of Torbutton, I have a concern about the employment > > of union routing (encrypting and decrypting several times between = the > > relaying nodes along the way) in Tor would be not acceptable to the > > RTC requirements of VoIP use-cases. > > Would this be an issue? > > > > BR > > Lingli > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Eric > > Rescorla > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 6:10 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti > > =E6=8A=84=E9=80=81: rtcweb@ietf.org > > =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for privacy > > > > On Wed, May 16, 2012 at 2:54 PM, Justin Uberti = wrote: > >> My view was that we need to make it _possible_ for sites to respect > >> privacy (via the API), and provide documentation that encourages > >> sites to do so. As you point out, I think it's difficult for the > >> browser to automatically figure out what to do here, and when to do = it. > >> > >> The identity of the "called" user may not be a factor in certain > >> applications (e.g. some p2p game), making it unclear as to whether > >> forcing use of relay is even the right thing to do. > > > > I concur with all this. > > > > I think it's also important to reiterate that this is about the site > > cooperating to protect your privacy. If you want to protect the = user's > > IP address from the site, then the user needs to use Torbutton or = some such. > > And I would want Torbutton to arrange relay my RTCWEB traffic as = well > > (though likely that can't go through Tor for performance reasons). > > > > -Ekr > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 7138 (20120515) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_0041_01CD34D7.0098F690 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

My mistake. It should be at =E2=80=9Cpeerconnection=E2=80=9D rather = than =E2=80=9Cgetusermedia=E2=80=9D in order to get what we = meant.

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Martin Thomson = [mailto:martin.thomson@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8818=E6=97=A5 9:05
=E6=94=B6=E4=BB=B6=E4=BA=BA: = =E9=82=93=E7=81=B5=E8=8E=89/denglingli
=E6=8A=84=E9=80=81: rtcweb@ietf.org; Eric = Rescorla
=E4=B8=BB=E9=A2=98: Re: [rtcweb] = =E7=AD=94=E5=A4=8D: = =E7=AD=94=E5=A4=8D: = =E7=AD=94=E5=A4=8D: Relaying for = privacy

 

I do not = think that any option other than what Eric described is truly feasible. = That is, of the options provided, only the one where the site has to be = trusted bit to reveal your IP is likely to = succeed.

getUserMedia = provides a cue of a fundamentally different nature to that you are = looking for in this use case. getUserMedia signals that the user is ok = with the site gaining access to their camera/microphone.  That is a = contract between the user and the site, not the two = users.

If you don't trust the = site, then you are in Torbutton land. That is, specific UI for = this.

I've concluded that we = don't need this requirement. There is little that a browser can sensibly = do beyond something like Torbutton.

And I'm not convinced that trying to replicate, or require = the replication of Torbutton, is a great idea either. Tor users = understand the value it provides, most other users won't care for the = added complication.

On May = 16, 2012 10:59 PM, "=E9=82=93=E7=81=B5=E8=8E=89/denglingli" <denglingli@chinamobile.com= > wrote:
>
> Sorry, by " In either cases, the = setting can be done through getusermedia as Martin said." I mean = " In either cases, the setting could be done through getusermedia = as Martin said."
> Since according to our experience with = chrome so far, media relaying through turn is not yet = supported.
>
> Lingli
>
> = -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 =E9=82=93=E7=81=B5=E8=8E=89/denglingli
> = =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 13:51
> = =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Eric = Rescorla'
> =E6=8A=84=E9=80=81: rtcweb@ietf.org
> = =E4=B8=BB=E9=A2=98: [rtcweb] = =E7=AD=94=E5=A4=8D: = =E7=AD=94=E5=A4=8D: Relaying for = privacy
>
> It makes sense to me.
> However, = considering the relaying burden would not be trivial, I'd further prefer = that the enable/disable button be dedicatedly set for the RTCWEB = instance in question, rather than the whole pack of connections of the = browsers.
> In other words, it is better to be triggered at the = time of page-loading for the RTCWEB app for a global configuration = (keeping current IP privacy for all callers) or when called by for a = specific configuration (keeping privacy for the incoming = caller).
> In either cases, the setting can be done through = getusermedia as Martin said.
>
> BR
> = Lingli
>
> = -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla [mailto:ekr@rtfm.com]
> = =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 10:07
> = =E6=94=B6=E4=BB=B6=E4=BA=BA: = =E9=82=93=E7=81=B5=E8=8E=89/denglingli
> = =E6=8A=84=E9=80=81: Justin Uberti; <rtcweb@ietf.org>
> = =E4=B8=BB=E9=A2=98: Re: = =E7=AD=94=E5=A4=8D: [rtcweb] Relaying for = privacy
>
> Yes. Tor is too slow to do voice effectively. I = would expect torbutton or a torbutton-like to route media through a turn = server. This will provide worse privacy than onion routing but better = than just letting the server control the routing.
>
> = Ekr
>
> On May 16, 2012, at 18:06, = =E9=82=93=E7=81=B5=E8=8E=89/denglingli <denglingli@chinamobile.com= > wrote:
>
> > Hi, Ekr
> >
> > I = agree with you about the Martin's comments.
> > For the = proposal of Torbutton, I have a concern about the employment
> = > of union routing (encrypting and decrypting several times between = the
> > relaying nodes along the way) in Tor would be not = acceptable to the
> > RTC requirements of VoIP = use-cases.
> > Would this be an issue?
> >
> = > BR
> > Lingli
> >
> > = -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Eric
> > = Rescorla
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8817=E6=97=A5 6:10
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: Justin Uberti
> > =E6=8A=84=E9=80=81: rtcweb@ietf.org
> > = =E4=B8=BB=E9=A2=98: Re: [rtcweb] Relaying for = privacy
> >
> > On Wed, May 16, 2012 at 2:54 PM, = Justin Uberti <juberti@google.com> = wrote:
> >> My view was that we need to make it _possible_ = for sites to respect
> >> privacy (via the API), and provide = documentation that encourages
> >> sites to do so. As you = point out, I think it's difficult for the
> >> browser to = automatically figure out what to do here, and when to do it.
> = >>
> >> The identity of the "called" user = may not be a factor in certain
> >> applications (e.g. some = p2p game), making it unclear as to whether
> >> forcing use = of relay is even the right thing to do.
> >
> > I = concur with all this.
> >
> > I think it's also = important to reiterate that this is about the site
> > = cooperating to protect your privacy. If you want to protect the = user's
> > IP address from the site, then the user needs to use = Torbutton or some such.
> > And I would want Torbutton to = arrange relay my RTCWEB traffic as well
> > (though likely that = can't go through Tor for performance reasons).
> >
> > = -Ekr
> > = _______________________________________________
> > rtcweb = mailing list
> > rtcweb@ietf.org
> > https://www.ietf.or= g/mailman/listinfo/rtcweb
> >
> > __________ = Information from ESET NOD32 Antivirus, version of virus
> > = signature database 7138 (20120515) __________
> >
> > = The message was checked by ESET NOD32 Antivirus.
> >
> = > http://www.eset.com
> = >
> >
> >
>
> __________ Information = from ESET NOD32 Antivirus, version of virus signature database 7138 = (20120515) __________
>
> The message was checked by ESET = NOD32 Antivirus.
>
> http://www.eset.com
>
>
&= gt;
> _______________________________________________
> = rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.or= g/mailman/listinfo/rtcweb
>
> = _______________________________________________
> rtcweb mailing = list
> rtcweb@ietf.org
> https://www.ietf.or= g/mailman/listinfo/rtcweb

------=_NextPart_000_0041_01CD34D7.0098F690-- From stefan.lk.hakansson@ericsson.com Fri May 18 05:13:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B5721F85A4 for ; Fri, 18 May 2012 05:13:51 -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=[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 0jkW2rWGKbI3 for ; Fri, 18 May 2012 05:13:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DA9DA21F8582 for ; Fri, 18 May 2012 05:13:50 -0700 (PDT) X-AuditID: c1b4fb25-b7c5aae000007a47-83-4fb63cfdc957 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B4.DF.31303.DFC36BF4; Fri, 18 May 2012 14:13:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 May 2012 14:13:49 +0200 Message-ID: <4FB63CFC.9050606@ericsson.com> Date: Fri, 18 May 2012 14:13:48 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> In-Reply-To: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:13:51 -0000 On 05/16/2012 03:31 AM, Cullen Jennings wrote: ... > > New use case: > > Imagine a service like webex that facilitates collaboration between > two companies called A and B. Webex has no need to see the content of > the communication from A to B. So webex might run the web server that > helps set up a RTCWeb session between A and B, but webex needs to be > able to write it's code such that it does not get the keying material > used to encrypt the media from A to B and the companies need to be > able to verify that webex did not get the keys. Webex has no need to > see the media from A to B and if it can provide this sort of promise > that it does not get the media, it makes it much easier for a > customer (say Juniper) to use webex and know the contents of their > calls are not being sold or used by a competitor. Given how much > WebRTC will be used by cloud services, this is an important feature. At least on the surface, this seems to have a lot in common with what Oscar proposed the other day ([1]), at least if the WebEx session has more than one concurrent user. [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html > When installing the "webex" application in the browser and granting > permissions to the application, it would be good to have one of the > permissions be if the JS got access to the media or keying material > for it to enforce this promise. > > Note this use case is not phrase to say this is the only way it can > work. This is not mutually exclusive with they type of use cases > described by Skype folks where there is an explicitly desire to make > sure the calling service does have the keys to decrypt the media. > > > > > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sat May 19 06:46:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E245121F85C6 for ; Sat, 19 May 2012 06:46:42 -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 GVX-WQblIR4b for ; Sat, 19 May 2012 06:46:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5541D21F85B9 for ; Sat, 19 May 2012 06:46:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8BC539E0C0; Sat, 19 May 2012 15:46: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 sEAR62Lg1zrV; Sat, 19 May 2012 15:46:40 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5910E39E062; Sat, 19 May 2012 15:46:40 +0200 (CEST) Message-ID: <4FB7A43F.2080608@alvestrand.no> Date: Sat, 19 May 2012 15:46:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtp-congestion@alvestrand.no" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: [rtcweb] Hold the date: Trying to get a workshop on congestion control for real time interactive media together.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 13:46:43 -0000 FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work. This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF. The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement.... Harald From magnus.westerlund@ericsson.com Mon May 21 00:01:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAC321F846A for ; Mon, 21 May 2012 00:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.797 X-Spam-Level: X-Spam-Status: No, score=-105.797 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, SARE_SUB_ENC_UTF8=0.152, 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 lTRTbz6qVpQQ for ; Mon, 21 May 2012 00:01:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E93DB21F8468 for ; Mon, 21 May 2012 00:01:25 -0700 (PDT) X-AuditID: c1b4fb25-b7c5aae000007a47-73-4fb9e79cab82 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.59.31303.C97E9BF4; Mon, 21 May 2012 08:58:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 21 May 2012 08:58:36 +0200 Message-ID: <4FB9E79C.1050300@ericsson.com> Date: Mon, 21 May 2012 08:58:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> In-Reply-To: <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiAgRndkOiBJLUQgQWN0aW9uOiBkcmFmdC13?= =?utf-8?q?esterlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 07:01:27 -0000 On 2012-05-21 03:44, 邓灵莉/denglingli wrote: > Hi, Magnus > > It seems to me that there may be another security threat in multi-party > applications of COP, where an entity needs to combine multiple sets of > requested parameters, than the one discussed in the draft. > That the initial downgrading of the combined potential ceiling for collected > parameters for media quality (codec capabilities plus COP parameters as > stated in Section 5) through SDP transaction by a malicious participant. > Unlike the one stated in Section 8, the latter behavior only happens once > and could neither been distinguished afterwards as "actively harmful" nor to > be ignored in order to serve actually poorly-equipped users. > Would that be an issue? > Yes, this is clearly a security threat to the complete solution. Not that it is specific to codec control. It is a threat to all things expressed in the SDP, like which codecs being used, security mechanism is negotiated etc. In the WebRTC security architecture my undestanding is that it so far are a deliberate choice of allowing the JavaScript and the web browser to be allowed to modify the SDP if desired by them. Thus a security model based on hop by hop security for the JSEP/SDP messages has been selected. For example the usage of HTTPS / Websocket over TLS can provide the security to prevent third parties not directly addressed from seeing and affecting the JSEP/SDP messages. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 FÀrögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From denglingli@chinamobile.com Mon May 21 02:55:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FAA21F8592 for ; Mon, 21 May 2012 02:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.966 X-Spam-Level: **** X-Spam-Status: No, score=4.966 tagged_above=-999 required=5 tests=[AWL=4.891, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp90LGDt66q2 for ; Mon, 21 May 2012 02:55:12 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8421F8573 for ; Mon, 21 May 2012 02:55:12 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 13C61E5FD; Mon, 21 May 2012 17:55:10 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id E64D6E5EE; Mon, 21 May 2012 17:55:10 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052117400872-19054 ; Mon, 21 May 2012 17:40:08 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Magnus Westerlund'" References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> In-Reply-To: <4FB9E79C.1050300@ericsson.com> Date: Mon, 21 May 2012 17:37:01 +0800 Message-ID: <00da01cd3735$467b6a20$d3723e60$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHJe2ybuQ X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-21 17:40:08, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-21 17:55:10, Serialize complete at 2012-05-21 17:55:10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18918.006 X-TM-AS-Result: No--29.301-7.0-31-10 X-imss-scan-details: No--29.301-7.0-31-10;No--29.301-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBGd2Q6IEktRCBBY3Rpb246?= =?utf-8?q?_draft-westerlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:55:13 -0000 Agreed. -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Westerlund = [mailto:magnus.westerlund@ericsson.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8821=E6=97=A5 = 14:59 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] Fwd: I-D Action: = draft-westerlund-rtcweb-codec-control-00.txt On 2012-05-21 03:44, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: > Hi, Magnus >=20 > It seems to me that there may be another security threat in=20 > multi-party applications of COP, where an entity needs to combine=20 > multiple sets of requested parameters, than the one discussed in the = draft. > That the initial downgrading of the combined potential ceiling for=20 > collected parameters for media quality (codec capabilities plus COP=20 > parameters as stated in Section 5) through SDP transaction by a = malicious participant. > Unlike the one stated in Section 8, the latter behavior only happens=20 > once and could neither been distinguished afterwards as "actively=20 > harmful" nor to be ignored in order to serve actually poorly-equipped = users. > Would that be an issue? >=20 Yes, this is clearly a security threat to the complete solution. Not = that it is specific to codec control. It is a threat to all things = expressed in the SDP, like which codecs being used, security mechanism = is negotiated etc. In the WebRTC security architecture my undestanding is that it so far = are a deliberate choice of allowing the JavaScript and the web browser = to be allowed to modify the SDP if desired by them. Thus a security = model based on hop by hop security for the JSEP/SDP messages has been = selected. For example the usage of HTTPS / Websocket over TLS can = provide the security to prevent third parties not directly addressed = from seeing and affecting the JSEP/SDP messages. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From magnus.westerlund@ericsson.com Mon May 21 06:31:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1728021F854B for ; Mon, 21 May 2012 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.023 X-Spam-Level: X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CBbbqdPTlDt for ; Mon, 21 May 2012 06:31:08 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C89A621F84D0 for ; Mon, 21 May 2012 06:31:07 -0700 (PDT) X-AuditID: c1b4fb30-b7b55ae000002887-5b-4fba439a4886 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BE.74.10375.A934ABF4; Mon, 21 May 2012 15:31:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Mon, 21 May 2012 15:31:05 +0200 Message-ID: <4FBA4399.4050909@ericsson.com> Date: Mon, 21 May 2012 15:31:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 13:31:09 -0000 Hi, I would like to have a firm understanding of how many that really will show up for either day of the interim meeting. The main purpose is to ensure that break snacks and lunch are provided in the right amount. So please fill in this doodle to register your participation for each of the days that you will be present. http://www.doodle.com/x3z6uhsy4q4s6fc4 Thanks Magnus Westerlund Interim meeting host ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From martin.thomson@gmail.com Mon May 21 08:42:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6521F85B8 for ; Mon, 21 May 2012 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GJswdmuFXXj for ; Mon, 21 May 2012 08:42:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16CD321F853F for ; Mon, 21 May 2012 08:42:50 -0700 (PDT) Received: by bkty8 with SMTP id y8so4956915bkt.31 for ; Mon, 21 May 2012 08:42: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=9e3INVZDywj+bk2fd3gh2KbOof/EGn9ZMlx1bXn/jds=; b=YMUGf3KB9LBlecXyA+oGB8/xGI9KeYq0tz5YvpRWZOzMt+hgtFEV+0inVrYkz8KWSi iMlsFVg/ECGt2ZWIt4BsokJueyYMoM0xz5gybNZU7OxI+wljxL/dT+OOV8JPtv8cuipq epA8yfnh+YKmbrOmSAP4Olkm6SRAySbbHd0ttuhEbBNu00B39jXJOKPApxsF/mvG07PX Vytw8ZjXE3UGhyrJWRuRO4tmQsbHxPPQ6MwsPL/SOAg53YFFDEnHxULf1s+EdpKDuwT3 l4sHoLfai66zzhzgy+/chYxqRaqau45uFuhYdC6XXymWjCRDPgtd7F3OVnyBsm++mIv1 NRnw== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr7934668bkv.26.1337614962931; Mon, 21 May 2012 08:42:42 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 21 May 2012 08:42:42 -0700 (PDT) In-Reply-To: <4FB9E79C.1050300@ericsson.com> References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> Date: Mon, 21 May 2012 08:42:42 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXdl?= =?utf-8?q?sterlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 15:42:51 -0000 > On 2012-05-21 03:44, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: >> That the initial downgrading of the combined potential ceiling for colle= cted >> parameters for media quality (codec capabilities plus COP parameters as >> stated in Section 5) through SDP transaction by a malicious participant. As Magnus pointed out, this is true of anything that can be signaled. The application can do anything up to (and including) a complete denial of service. The fact that the application is effectively the victim of this attack means that we probably shouldn't concern ourselves overmuch. From denglingli@chinamobile.com Mon May 21 18:29:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D721F8569 for ; Mon, 21 May 2012 18:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.728 X-Spam-Level: *** X-Spam-Status: No, score=3.728 tagged_above=-999 required=5 tests=[AWL=1.239, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTEeSZjecd2v for ; Mon, 21 May 2012 18:29:17 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3321F8562 for ; Mon, 21 May 2012 18:29:13 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 31502E423; Tue, 22 May 2012 09:29:10 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 29A67E41B; Tue, 22 May 2012 09:29:10 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052209290741-4722 ; Tue, 22 May 2012 09:29:07 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Martin Thomson'" , "'Magnus Westerlund'" References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> In-Reply-To: Date: Tue, 22 May 2012 09:25:56 +0800 Message-ID: <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHAHH0ykgl6maOnA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 09:29:07, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 09:29:10, Serialize complete at 2012-05-22 09:29:10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18920.001 X-TM-AS-Result: No--22.034-7.0-31-10 X-imss-scan-details: No--22.034-7.0-31-10;No--22.034-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiAg562U5aSNOiBGd2Q6IEktRCBBY3Rpb246?= =?utf-8?q?_draft-westerlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 01:29:18 -0000 Hi, Martin You are right. According to the current discussion, I would suggest two = options about the security threat statement:=20 1, remove the item c from Section 8; or 2, add a few words to notify what is left out and may be of concern in = the field and people would know what to expect in reality. Would you agree? BR=20 Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Martin Thomson = [mailto:martin.thomson@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8821=E6=97=A5 = 23:43 =E6=94=B6=E4=BB=B6=E4=BA=BA: Magnus Westerlund =E6=8A=84=E9=80=81: =E9=82=93=E7=81=B5=E8=8E=89/denglingli; = rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: [rtcweb] =E7=AD=94=E5=A4=8D: Fwd: I-D Action: = draft-westerlund-rtcweb-codec-control-00.txt > On 2012-05-21 03:44, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: >> That the initial downgrading of the combined potential ceiling for=20 >> collected parameters for media quality (codec capabilities plus COP=20 >> parameters as stated in Section 5) through SDP transaction by a = malicious participant. As Magnus pointed out, this is true of anything that can be signaled. The application can do anything up to (and including) a complete denial = of service. The fact that the application is effectively the victim of = this attack means that we probably shouldn't concern ourselves overmuch. __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From martin.thomson@gmail.com Mon May 21 19:51:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63F921F85C9 for ; Mon, 21 May 2012 19:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxuVW6bUXbOb for ; Mon, 21 May 2012 19:51:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13DBA21F85AE for ; Mon, 21 May 2012 19:51:09 -0700 (PDT) Received: by bkty8 with SMTP id y8so5444955bkt.31 for ; Mon, 21 May 2012 19:51:09 -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=/7zWSTNjWofyqa0Rxmrq1INjnh8OraUgYH/WXzg6/jA=; b=BlT4MkGxwxg8aXIvzZ13aNC7ZJCK7V7I7Ak+ZnvmyHRw6+MaVPM35TY1XWbCyf75b/ hsWHemn2ibNwLF6AEl+b3jPhGanO7CMcEJTU62FpRduGAN2UEQT0EWzDCxf0+8GPmCKi mQIIDcG7EFpSo9zjFghFTKqnEgC2qPLwHuoVPZE6BwAewsHSbZEYT60XnE0+IY2mxiCH v9G0WEs3Sin6JW8UoVmfjQ6HDSbN3eWJNIin45rgTOUKW7pZ0Cm1nQijX7snjEopyfqP 2U/eKkHlHVuhvBgblbGOf6Rmp0IjFIaAIV6FOjaKX7Zu8Wmf1eQaAakPqjvhkpytznVN M2KA== MIME-Version: 1.0 Received: by 10.205.33.136 with SMTP id so8mr8432727bkb.1.1337655069047; Mon, 21 May 2012 19:51:09 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 21 May 2012 19:51:09 -0700 (PDT) In-Reply-To: <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> Date: Mon, 21 May 2012 19:51:09 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiAg562U5aSNOiBGd2Q6IEktRCBBY3Rpb246?= =?utf-8?q?_draft-westerlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 02:51:11 -0000 On 21 May 2012 18:25, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: > [...] I would suggest two options about the security threat statement: > 1, remove the item c from Section 8; or > 2, add a few words to notify what is left out and may be of concern in th= e field and people would know what to expect in reality. > Would you agree? I'm not sure about the full implications of these sorts of mechanisms yet. I was speaking more generally about rtcweb. In general however, it is true that a site (or any entity on the signaling path) can degrade the experience. Adding a mechanism like what Magnus proposes lets any participant in a call perform the same sorts of degradations. As a site operator, I want to ensure that this doesn't happen, so that my users always get the best experience from my site. So that's not necessarily an exposure that I like. Of course, I haven't really analyzed the upside of this particular trade-off yet... --Martin p.s. it might be possible for a mechanism like this to "fix" downgrades chosen by the site, though that wouldn't be advisable. The proposal indicates otherwise: that the constraints set during negotiation are firm. From denglingli@chinamobile.com Mon May 21 20:25:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD721F84FA for ; Mon, 21 May 2012 20:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.852 X-Spam-Level: ** X-Spam-Status: No, score=2.852 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id datdCVNXHCRH for ; Mon, 21 May 2012 20:25:56 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA121F851A for ; Mon, 21 May 2012 20:25:56 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 22405E660; Tue, 22 May 2012 11:25:55 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id F3197E632; Tue, 22 May 2012 11:25:54 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052211255259-8943 ; Tue, 22 May 2012 11:25:52 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Martin Thomson'" References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> In-Reply-To: Date: Tue, 22 May 2012 11:22:43 +0800 Message-ID: <005a01cd37ca$267bc720$73735560$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHAHH0ykgAhJR97QBep3omZeNUNRQ X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 11:25:52, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 11:25:54, Serialize complete at 2012-05-22 11:25:54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18920.001 X-TM-AS-Result: No--28.697-7.0-31-10 X-imss-scan-details: No--28.697-7.0-31-10;No--28.697-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IEZ3ZDogSS1E?= =?utf-8?q?_Action=3A_draft-westerlund-rtcweb-codec-control-00=2Etx?= =?utf-8?q?t?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 03:25:57 -0000 I don't think it is a good idea to loosen the firm constraints that the = site/a third party would set to the media negotiation. Looking at the other side, the browser may not know everything about the = session as well as the other side of communication (as JSEP suggested). Besides, there may be policies that a service provider would like to = configure in order to regulate media behaviors of its users, especially = when it comes to interworking with legacy networks. Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Martin Thomson = [mailto:martin.thomson@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8822=E6=97=A5 = 10:51 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: Magnus Westerlund; rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] =E7=AD=94=E5=A4=8D: = Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt On 21 May 2012 18:25, =E9=82=93=E7=81=B5=E8=8E=89/denglingli = wrote: > [...] I would suggest two options about the security threat statement: > 1, remove the item c from Section 8; or 2, add a few words to notify=20 > what is left out and may be of concern in the field and people would = know what to expect in reality. > Would you agree? I'm not sure about the full implications of these sorts of mechanisms = yet. I was speaking more generally about rtcweb. In general however, = it is true that a site (or any entity on the signaling path) can degrade = the experience. Adding a mechanism like what Magnus proposes lets any participant in a = call perform the same sorts of degradations. As a site operator, I want = to ensure that this doesn't happen, so that my users always get the best = experience from my site. So that's not necessarily an exposure that I = like. Of course, I haven't really analyzed the upside of this = particular trade-off yet... --Martin p.s. it might be possible for a mechanism like this to "fix" downgrades chosen by the site, though that wouldn't be advisable. The = proposal indicates otherwise: that the constraints set during = negotiation are firm. __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From magnus.westerlund@ericsson.com Mon May 21 23:43:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74B9E8015 for ; Mon, 21 May 2012 23:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.91 X-Spam-Level: X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 PWO2fdkOnGnw for ; Mon, 21 May 2012 23:43:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A44FF9E8013 for ; Mon, 21 May 2012 23:43:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-92-4fbb3587b8ba Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B4.F1.11913.7853BBF4; Tue, 22 May 2012 08:43:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 22 May 2012 08:43:18 +0200 Message-ID: <4FBB3586.4050902@ericsson.com> Date: Tue, 22 May 2012 08:43:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> In-Reply-To: <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+JvrW676W5/g6OXJCwenn/CbHHtzD9G i7X/2tkdmD3mXVjI5rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZdxaYlTwjKfi9fQ1bA2M 27m6GDk5JARMJA4daGKCsMUkLtxbz9bFyMUhJHCKUeL8hu2sEM5yRomfe+YxdjFycPAKaEvs mOwN0sAioCqxcOY+VhCbTcBC4uaPRjYQW1QgWOLFnitgcV4BQYmTM5+wgNgiAp4Si7ZPZASx mQXCJY58amcBmS8ssJ5R4uGifYwQy1YySbx6txBsEqeAncTNC+vYIM6TlDj47xo7RLemROv2 31C2vETz1tnMILYQ0HENTR2sExiFZiFZPgtJyywkLQsYmVcxCucmZuaklxvqpRZlJhcX5+fp FaduYgQG9sEtv3V3MJ46J3KIUZqDRUmcd7PBLn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jMVrmf8teCrlL9l5Ty/OU8Lx+fOs266fbIXO8ziEqPF0M1ZnzzP58NNwSodj1M7uMLdrOSvL pl6Z0X9iwdWwy84L8zUWab0506hYZcrB+2HNEwfdnKeSE/hvGf9b/P3O9RNqvpefpB3cf2BR 2pJJTEtSl3RJzPnhcMPIuPnSjgxT/bYvvhP8vJVYijMSDbWYi4oTAdAmWYI6AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiAg562U5aSNOiBGd2Q6IEktRCBBY3Rpb246?= =?utf-8?q?_draft-westerlund-rtcweb-codec-control-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:43:21 -0000 On 2012-05-22 03:25, 邓灵莉/denglingli wrote: > Hi, Martin > > You are right. According to the current discussion, I would suggest two options about the security threat statement: > 1, remove the item c from Section 8; or I don't think this is an appropriate choice. The reason is that it applies to multi-party cases where an given end-point targets the other participants. Mitigation in the media plane central node for this attack is something the implementation should have. > 2, add a few words to notify what is left out and may be of concern in the field and people would know what to expect in reality. > Would you agree? I would like to make it clear that this documents security consideration is a short summary of the most important attacks. The COP drafts security consideration is not existing and that will be addressed in the next version. That will clearly discuss the SDP angle and at least point out the need for protection between the nodes. But also that in multi-party there exist a potential for down-grading the general constraints. I will consider adding the SDP based downgrade into this document also. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 FÀrögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From denglingli@chinamobile.com Tue May 22 00:27:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED71121F84A6 for ; Tue, 22 May 2012 00:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.786 X-Spam-Level: * X-Spam-Status: No, score=1.786 tagged_above=-999 required=5 tests=[AWL=1.711, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp006GKf5wzt for ; Tue, 22 May 2012 00:27:23 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92221F84A2 for ; Tue, 22 May 2012 00:27:22 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id DFDC5E66C; Tue, 22 May 2012 15:27:20 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id D30EEE434; Tue, 22 May 2012 15:27:20 +0800 (CST) Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052215271487-33144 ; Tue, 22 May 2012 15:27:14 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Magnus Westerlund'" References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> <4FBB3586.4050902@ericsson.com> In-Reply-To: <4FBB3586.4050902@ericsson.com> Date: Tue, 22 May 2012 15:24:05 +0800 Message-ID: <009c01cd37eb$de642640$9b2c72c0$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHAHH0ykgAhJR97QC5/lQZ5eCLEow X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 15:27:14, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 15:27:20, Serialize complete at 2012-05-22 15:27:20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18920.004 X-TM-AS-Result: No--29.598-7.0-31-10 X-imss-scan-details: No--29.598-7.0-31-10;No--29.598-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: rtcweb@ietf.org Subject: [rtcweb] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IEZ3ZDogSS1E?= =?utf-8?q?_Action=3A_draft-westerlund-rtcweb-codec-control-00=2Etx?= =?utf-8?q?t?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 07:27:25 -0000 Agreed.=20 Thanks, Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Magnus Westerlund = [mailto:magnus.westerlund@ericsson.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B45=E6=9C=8822=E6=97=A5 = 14:43 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: 'Martin Thomson'; rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [rtcweb] =E7=AD=94=E5=A4=8D: = Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt On 2012-05-22 03:25, =E9=82=93=E7=81=B5=E8=8E=89/denglingli wrote: > Hi, Martin >=20 > You are right. According to the current discussion, I would suggest = two options about the security threat statement:=20 > 1, remove the item c from Section 8; or I don't think this is an appropriate choice. The reason is that it = applies to multi-party cases where an given end-point targets the other = participants. Mitigation in the media plane central node for this attack = is something the implementation should have. > 2, add a few words to notify what is left out and may be of concern in = the field and people would know what to expect in reality. > Would you agree? I would like to make it clear that this documents security consideration = is a short summary of the most important attacks. The COP drafts = security consideration is not existing and that will be addressed in the = next version. That will clearly discuss the SDP angle and at least point = out the need for protection between the nodes. But also that in = multi-party there exist a potential for down-grading the general = constraints. I will consider adding the SDP based downgrade into this document also. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- __________ Information from ESET NOD32 Antivirus, version of virus = signature database 7138 (20120515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From dromasca@avaya.com Tue May 22 04:18:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6421F85D4 for ; Tue, 22 May 2012 04:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=-0.625, 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 CMMjjvEpMqLQ for ; Tue, 22 May 2012 04:18:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B083521F85D2 for ; Tue, 22 May 2012 04:18:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOZ0u0+HCzI1/2dsb2JhbABEtBKBB4IVAQEBAQMBAQEJBh4+FwICAgEIDQQEAQELBgwLAQYBGgwfCQgBAQQBEggah2wLoHmdHQSLBIRaYgOID5J9iX+Caw X-IronPort-AV: E=Sophos;i="4.75,638,1330923600"; d="scan'208";a="10420873" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 May 2012 07:16:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2012 07:00:26 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 13:18:08 +0200 Message-ID: In-Reply-To: <4FBA4399.4050909@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Interim participation registration Thread-Index: Ac03Vf0hZq32i/1xQsizca6HyLlzdQAtlDBQ References: <4FBA4399.4050909@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Magnus Westerlund" , Subject: Re: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:18:12 -0000 Do you need a count only for people who plan to attend on-site?=20 Dan > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Monday, May 21, 2012 4:31 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Interim participation registration >=20 > Hi, >=20 > I would like to have a firm understanding of how many that really will > show up for either day of the interim meeting. The main purpose is to > ensure that break snacks and lunch are provided in the right amount. >=20 > So please fill in this doodle to register your participation for each > of > the days that you will be present. >=20 > http://www.doodle.com/x3z6uhsy4q4s6fc4 >=20 > Thanks >=20 > Magnus Westerlund > Interim meeting host >=20 >=20 >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Tue May 22 05:07:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF221F85FC for ; Tue, 22 May 2012 05:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb2971wknT8n for ; Tue, 22 May 2012 05:07:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1B421F85EF for ; Tue, 22 May 2012 05:07:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7fac6d000002e89-60-4fbb81704abc Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BC.EA.11913.0718BBF4; Tue, 22 May 2012 14:07:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 22 May 2012 14:07:11 +0200 Message-ID: <4FBB816F.7040900@ericsson.com> Date: Tue, 22 May 2012 14:07:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FBA4399.4050909@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW5B425/g94OMYuvP3+wWqz9187u wORxcOUcdo8lS34yBTBFcdmkpOZklqUW6dslcGXMPbyDvWCiYEXb+m9MDYxfebsYOTkkBEwk Wj69Y4awxSQu3FvP1sXIxSEkcIpRYu+FnewQznJGiakPP7N2MXJw8ApoS+zYwQLSwCKgKvHj 4mE2EJtNwELi5o9GMFtUIFjixZ4rrCA2r4CgxMmZT8DqRQT0JT7OWAO2jFlAXeLO4nPsICOF gXp/TRcECQsJFEss+L0ArIRTIERiyfmN7BC3SUoc/HeNHaJVT2LK1RZGCFteonnrbGaIXm2J hqYO1gmMQrOQbJ6FpGUWkpYFjMyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECA/jglt+6OxhP nRM5xCjNwaIkzrvZYJe/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbWvG2K99pmT2WJiDhn N++f+eGHHBIbXjw7fXpRTcANw1+9M55OfVLRvsl8+rIc1m2msxKF/iY5fZY9I/qfl8dhTe73 F5x/3d6e95ec0vhC7Isrw95nXtq69X9+LFBXfpqouEuj78X990eWqEyWDTp+6N+NMCch4X37 eVL/GFnsnfF5cnU5i8UMJZbijERDLeai4kQAYyX8OC4CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 12:07:14 -0000 On 2012-05-22 13:18, Romascanu, Dan (Dan) wrote: > Do you need a count only for people who plan to attend on-site? Good question. Yes, the this was for physical participation. We know that we will have some number of remote participation. I don't know how important it is to get a head count for them. Cheers Magnus > > Dan > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Magnus Westerlund >> Sent: Monday, May 21, 2012 4:31 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Interim participation registration >> >> Hi, >> >> I would like to have a firm understanding of how many that really will >> show up for either day of the interim meeting. The main purpose is to >> ensure that break snacks and lunch are provided in the right amount. >> >> So please fill in this doodle to register your participation for each >> of >> the days that you will be present. >> >> http://www.doodle.com/x3z6uhsy4q4s6fc4 >> >> Thanks >> >> Magnus Westerlund >> Interim meeting host >> >> >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dromasca@avaya.com Tue May 22 05:09:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A321F8493 for ; Tue, 22 May 2012 05:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 Hy3zYuaB1gQS for ; Tue, 22 May 2012 05:09:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id BF7A921F847A for ; Tue, 22 May 2012 05:09:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM6Bu0+HCzI1/2dsb2JhbABDtBKBB4IVAQEBAQMBAQEJBh4+CwwCAgIBCA0EBAEBAQoGDAsBBgEaDB8JCAEBBBMIGodsC5w5nRoEiwSEWmIDiA+JMYlMiX+Caw X-IronPort-AV: E=Sophos;i="4.75,638,1330923600"; d="scan'208";a="10427311" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 May 2012 08:07:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2012 07:51:45 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 14:09:26 +0200 Message-ID: In-Reply-To: <4FBB816F.7040900@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Interim participation registration Thread-Index: Ac04E3SUd9Q8rt5sRzyCWo+FU7QPDgAAAoVA References: <4FBA4399.4050909@ericsson.com> <4FBB816F.7040900@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Magnus Westerlund" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 12:09:57 -0000 Maybe it is important for Webex, if you plan to use Webex for remote = participation. Or other tool. I do not know. In any case, you would need = a separate doodle or a different option on the current doodle.=20 Regards, Dan > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, May 22, 2012 3:07 PM > To: Romascanu, Dan (Dan) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Interim participation registration >=20 > On 2012-05-22 13:18, Romascanu, Dan (Dan) wrote: > > Do you need a count only for people who plan to attend on-site? >=20 > Good question. Yes, the this was for physical participation. We know > that we will have some number of remote participation. I don't know = how > important it is to get a head count for them. >=20 > Cheers >=20 > Magnus >=20 > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Magnus Westerlund > >> Sent: Monday, May 21, 2012 4:31 PM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Interim participation registration > >> > >> Hi, > >> > >> I would like to have a firm understanding of how many that really > will > >> show up for either day of the interim meeting. The main purpose is > to > >> ensure that break snacks and lunch are provided in the right = amount. > >> > >> So please fill in this doodle to register your participation for > each > >> of > >> the days that you will be present. > >> > >> http://www.doodle.com/x3z6uhsy4q4s6fc4 > >> > >> Thanks > >> > >> Magnus Westerlund > >> Interim meeting host > >> > >> > >> > >> = -------------------------------------------------------------------- > -- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> = -------------------------------------------------------------------- > -- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> = -------------------------------------------------------------------- > -- > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From harald@alvestrand.no Tue May 22 06:10:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221AA21F84D9 for ; Tue, 22 May 2012 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 LZJhUqq4PYfh for ; Tue, 22 May 2012 06:10:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1652B21F84AF for ; Tue, 22 May 2012 06:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C10FF39E0F0 for ; Tue, 22 May 2012 15:10:11 +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 t1Li1tHxyHGt for ; Tue, 22 May 2012 15:10:11 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 15DFF39E08A for ; Tue, 22 May 2012 15:10:11 +0200 (CEST) Message-ID: <4FBB9032.6000809@alvestrand.no> Date: Tue, 22 May 2012 15:10:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FBA4399.4050909@ericsson.com> In-Reply-To: <4FBA4399.4050909@ericsson.com> Content-Type: multipart/alternative; boundary="------------060308010508000706060201" Subject: Re: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:10:14 -0000 This is a multi-part message in MIME format. --------------060308010508000706060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Note that the registration for the WEBRTC meeting on Monday is separate, and that the participants are listed here: http://www.w3.org/2011/04/webrtc/wiki/June_11_2012 Formalities... Harald On 05/21/2012 03:31 PM, Magnus Westerlund wrote: > Hi, > > I would like to have a firm understanding of how many that really will > show up for either day of the interim meeting. The main purpose is to > ensure that break snacks and lunch are provided in the right amount. > > So please fill in this doodle to register your participation for each of > the days that you will be present. > > http://www.doodle.com/x3z6uhsy4q4s6fc4 > > Thanks > > Magnus Westerlund > Interim meeting host > > > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------060308010508000706060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Note that the registration for the WEBRTC meeting on Monday is separate, and that the participants are listed here:

http://www.w3.org/2011/04/webrtc/wiki/June_11_2012

Formalities...

            Harald

On 05/21/2012 03:31 PM, Magnus Westerlund wrote: 
Hi,

I would like to have a firm understanding of how many that really will
show up for either day of the interim meeting. The main purpose is to
ensure that break snacks and lunch are provided in the right amount.

So please fill in this doodle to register your participation for each of
the days that you will be present.

http://www.doodle.com/x3z6uhsy4q4s6fc4

Thanks

Magnus Westerlund
Interim meeting host



----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--------------060308010508000706060201-- From mary.ietf.barnes@gmail.com Tue May 22 11:54:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF0C21F8631 for ; Tue, 22 May 2012 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cQr1U63Z1jLe for ; Tue, 22 May 2012 11:54:05 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCA121F861B for ; Tue, 22 May 2012 11:54:05 -0700 (PDT) Received: by vcqp1 with SMTP id p1so779815vcq.31 for ; Tue, 22 May 2012 11:54:04 -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=VpOPcIW1F2MxDR8STkfg9Dens17Pu3qbJQGMBR2jKn4=; b=Pb78oNUTUNxEdPTLza6NXijSHNgEHfQP594Fq1gEO6HlR+0L53nmKrowh0BWpIqGVJ QP8kgvzKQQOJrNTpgj2TaOrqNObQU86ofZBm2rVKobc5/MqZvHrU25FYM0eTA8fuvRPN PPb1oYyb0oZlRVa0l6sozHDhMjK79R6QWu15HT/asUVKi7yWTw5WftcWfmSKqF2MjBJd 4n3XMkdepdtvrKtG1DUk0Vg8km3JEuk7+laT/Q6VXC4QRAYiwwzYqgVVkZqmCQH8SamS UlH/X7azm4znILWSZrCi/C1mHMXN5i7JMym4x6Hg/cqShAyhO68e++2kwmA4+IyZT9GE UPVA== MIME-Version: 1.0 Received: by 10.220.107.6 with SMTP id z6mr1400090vco.37.1337712844621; Tue, 22 May 2012 11:54:04 -0700 (PDT) Received: by 10.52.22.143 with HTTP; Tue, 22 May 2012 11:54:04 -0700 (PDT) Date: Tue, 22 May 2012 13:54:04 -0500 Message-ID: From: Mary Barnes To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] CLUE WG interim meeting before RTCWEB meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 18:54:06 -0000 Hi, This is a reminder that we did schedule the CLUE WG interim meeting to facilitate attendance of folks that are also active in RTCWEB as there is overlap when it comes to multi-stream. The best we could do was to schedule the CLUE meeting on June 7th and 8th (the Thursday and Friday the week before the W3C WebRTC and IETF RTCWEB meetings). This results in folks that want to attend both to spend a weekend in Stockholm - whether you consider that a good thing or not, a break between two fairly intense meetings is not a bad thing, otherwise, we would end up more fried than we do after a week of IETF meetings. Anyways, as a co-chair of CLUE, I strongly encourage folks to try to attend the CLUE meeting. We have a doodle setup so that the logistics can be properly arranged: http://doodle.com/wwrdycma9ymrdn3r Ericsson is also hosting this meeting so it will be at the same location as the WebRTC & RTCWEB meetings. Regards, Mary Barnes CLUE WG co-chair From martin.thomson@gmail.com Tue May 22 15:13:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C121F86B5 for ; Tue, 22 May 2012 15:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_20=-0.74, MANGLED_SAVELE=2.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 PTaF0KsWBuih for ; Tue, 22 May 2012 15:13:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37B21F86B1 for ; Tue, 22 May 2012 15:13:05 -0700 (PDT) Received: by bkty8 with SMTP id y8so6515496bkt.31 for ; Tue, 22 May 2012 15:13:04 -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=23rYfcVzMa8vHRh5XIfyeLK9GLsTZszO7Iieu8h90sg=; b=XPrfMcleFf76mdaFCDJfVEYltIaMNeakMBBXavua5Db8/+6yprhP14TMRWWnrPvDC+ dDX+fZDyNeFiW9D5h4Jg9KRwM0zvQv3GJ+HO9sgyz51Lep8MJKks9cLujJp+uYzRaAZG GnUwLO+T01mgC0laNqNdwNuwNzG2us6VkVRddw4SqqwvDL7wtrDa+gaC+NvGwb1NxwVB Gb+yAd8fE+AgoHUlOqGZrMhh0sJrKIEWQIb+RHwXhjIn02aqQcL+PjnSxH4ZE1SegxkO T5jw4b70d2PKkyg82iOZZB6I4y2VloCEzFJzLbK34jLglO3XaWDA3gKWiSDx5ek9S+hV NFqg== MIME-Version: 1.0 Received: by 10.204.153.204 with SMTP id l12mr10379613bkw.49.1337724784605; Tue, 22 May 2012 15:13:04 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 22 May 2012 15:13:04 -0700 (PDT) Date: Tue, 22 May 2012 15:13:04 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Review of security documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:13:07 -0000 Pedantic review of draft-ietf-rtcweb-security-02 ... with reference to draft-ietf-rtcweb-security-arch-01 Both documents are in pretty good shape. They a largely coherent and comprehensive. That's not to say that they are finished. To some extent, a lot of these issues are simply due to entropy. We've made quite a few decisions in the time since these were last updated. We've also made no progress on other issues. HTTP/HTTPS S3, last paragraph before S3.1: [...], but realistically many sites do not run HTTPS [RFC2818] and so our ability to defend against network attackers is necessarily somewhat limited. This isn't especially relevant. Obviously, the standard class of problems with unsecured HTTP exist, but within the context of this application, there aren't that many more that this enables. The example in S4.1.3 is not unique to this application. It applies to any user consent that is tied to a particular web origin. In comparison to possibly visiting and _using_ a site operated by a web attacker, this is not substantially worse, or requiring significantly more effort to analyze. Of course, the only safe assumption is that you are talking to a web attacker when using unsecured HTTP. ((Aside: I'd be interested in learning how this might turn into an attack on user consent. Otherwise, this is a bit of a scary statement to just drop in without support: Note: this issue is not restricted to PAGES which contain mixed content. If a page from a given origin ever loads mixed content then it is possible for a network attacker to infect the browser's notion of that origin semi-permanently.)) NETWORK ATTACKERS Same paragraph: [...], with the assumption that protection against network attackers is provided by running HTTPS. Thankfully, the draft does not make this assumption. Attacks on HTTP are out of scope, but we still need to deal with network attackers. TYPES OF CONSENT The document talks about consent in general as being important but it doesn't do anything to address what specific consent is needed. I think that it has been well-established that consent is required for access to input devices (e.g., camera/microphone). The implication from S4.1 is that this is sufficient as well as necessary. There is one crucial piece of the argument that is absent: A site with access to camera or microphone could send media either to itself or any site that indicates consent (see CORS). Sending media over HTTP or thewebsocketprotocol is likely to perform less well than is ideal, but it would work. Therefore, it's easy to draw the implicit conclusions of the draft, namely: 1. a receipt consent mechanism like CORS is necessary, and 2. user consent for access to input devices is necessary _and_ sufficient...for this mode. PRIVATE COMMUNICATIONS AND CONSENT The above assumes that the site has access to media. That is, permission for input devices is being granted to the site. However, it is possible to imagine a mode of communications where the site mediates the creation of a secure channel, but does not have access to that channel. This changes the assumptions - and the nature of the consent - dramatically. S4.1.2 and security-arch@S5.2 covers this case, but doesn't really properly emphasize just how different this is. Just as for the entirety of S4.1, the problem then becomes one of unambiguous identification. And UI. From S4.1.2: Naturally, it is somewhat challenging to design UI primitives which express this sort of policy. Complications include group calling. How does the site ask for permissions to talk to "a@b.com" and "x@y.net"? How does such a privilege persist? Does it even make sense to persist at all? Obviously, a conference of any significant size tends toward having a bridge. At that point, input devices are most likely granted to "host.example.com". TRULY PRIVATE COMMUNICATIONS Keeping the site out of the loop requires that the browser lock down access to media recording. The trick is to ensure that the media is unmodified all the way from source to sink. It's relatively easy to ensure that media coming off the network is unmodified. It is harder to ensure that it did not get modified by a web attacker prior to being put on the network. That requires a verifiable assertion from the remote user that it did not allow a web attacker access to see or modify the stream prior to it being placed in the pipe. The distinction between media stream visibility and modifiability might be worth discussing a little. My initial thought is that it was not especially useful in this context. I can imagine work-arounds that would enable features that depend on visibility such as recording where authenticity is also desirable. IDENTIFICATION S4.1.1.1.1.1.1.1.1 asks the obvious question: [...] there is a question about whether the user can know who they are talking to. When a site has access to your media, then you are talking to the site. ...and anyone the site chooses to forward your media to. This is exactly what you get when you use SRTP security descriptions (and also EKT, if you allow the site to insert keys). USER INTERACTION CONSIDERATIONS S4.1.1.2 hides two important UI considerations: [...] great care must be taken in the design of this interface to avoid the users just clicking through and [...] the user interface chrome must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely These are both massively important. If there were a W3C companion document, then it would make sense to include this sort of stuff there. More robust treatment would be nice for: a) the limitations of consent mechanisms b) providing appropriate feedback For the latter, this can get complicated. I recall a discussion of the geolocation API that lead to the conclusion that no UI feedback would be provided. I still believe that this was a poor choice. This case bears a certain amount of similarity to that discussion. I should really join that media capture group... In any case, this probably needs at least basic treatment here, even if that is just by reference. AUTHENTICATION MODELS (Crossing over into S4 of the security-arch document here to address the use cases from S4.1.1.2 and S4.1.1.3.) It looks like there is an assumption in play here. That is, there is something like an IdP in use. Calling a site (as opposed to a person) is very much a case where the usual domain trust anchors are perfectly adequate. The site can offer an identical (or similar) certificate in the DTLS handshake as it did with the HTTPS TLS handshake. Obviously, it's not as simple as just having this chain to a trust anchor. Any site that deployed TLSA (c.f. DANE WG) would require extra checking. I'm surprised to see nothing on this particular use case. It's a particularly useful one. CALL MEDIATION AND REPUTATION S4.1.1.3 contains a discussion about a case where the reputation of one site is potentially affected by it mediating a call with a third party. In the example, sites wouldn't want advertisements they display from reflecting poorly on them. I don't see how this changes the current situation significantly. Site and ad networks work very hard to ensure that advertisements are appropriate to the context in which they are shown. Realtime calling doesn't really change this situation in any meaningful way. A very big part of this is ensuring that the source of media is correctly identified. In part, this is the same problem we already have. In addition, sites need to take some responsibility for making any necessary distinction sufficiently clear on their own interface. In this context, the burden lies with the ad network. ((Aside. I'm not sure that this is always true: [...] sites which host advertisements often learn very little about whether individual users clicked through to the ads, or even which ads were presented That's true for ads in iframes, but then the reputation concern isn't entirely applicable. If the ads are served inline, then I would have to assume that obfuscation of ad network content is the only protection against the site learning about ad content and user interactions.)) COMMUNICATIONS CONSENT The idea that a target for a media flow consents is not binary in the sense that ICE establishes. Even with the addition of an expiration time to ICE consent, there are two problems related to the volume of packets that need addressing: The rate at which STUN Binding requests are generated in ICE is dependent on the bandwidth available for media. Because this information comes from a web attacker, the browser cannot trust this information. The browser has to rate-limit Binding requests based on its own information. In practice, this probably has to be based on a fixed rate. Even once the browser has validated consent, it has no idea _how much_ media is OK to send. The difference between 8kbps audio and 5Mbps high definition video is enough to make many an internet connection melt. RTCP feedback like TMMBR is good, but maybe those packets could be made to get "lost" by a network attacker. Plus, if we are going to offer a data channel that doesn't use RTCP, then that option isn't available. BANDWIDTH LIMITING Bandwidth limiting is probably an important security feature that isn't really covered, though you touch on it in the security considerations of security-arch. SPECULATIVE STUFF Don't think that we need masking: TURN TCP probably has enough protection already and that's the only TCP I can imagine having to use, aside from HTTPS... Don't think that we need some sort of implicit consent mechanism. For consent, I don't think that it's unreasonable to expect ICE-lite at a minimum. See thread on hiding IP addresses. In order to avoid tracking via IP, clients should not use the Internet. I hear that Tor is somewhat handy at making it possible to have cake that you can eat too. That said, I'm not sure that that particular cake tastes all that nice... IdP MIXED CONTENT security-arch@S5.1 It might make sense to consider _all_ unsecured HTTP is being in the same origin for the purposes of this. Furthermore, I subscribe to the view that mixed content == unsecured. The idea that a page might become mixed content is a real concern. Terminating the session is probably the only safe choice. Here's the thought process. Initially, I thought that it might be sufficient to prevent modifications to the session once a page goes rogue. At least then if a secure browser-to-browser pipe exists that the page could not access prior to the poisoning, this pipe can continue unmodified. However, if one browser goes off the grid, then it can simply exploit any renegotiation capabilities that exist in the application to trigger changes through the signaling channel. For instance, EKT might allow the attacker to update keys. Given that it should also be possible to insert a relay (in one direction at least) by providing faked "candidates", this cracks it wide open. The more renegotiation capabilities exist on the media path, the worse this is. ICE TRANSACTION ID ...need only be hidden for Binding requests that are outstanding. Successful requests need not be hidden. (Note that this means meeting all of the success criteria specified in RFC 5245.) ICE KEEPALIVES Are not sufficient, so don't require them. Instead, require a repeat of the connectivity check. That ensures consent is refreshed and it also means that the statement about ICE-Lite remains true, which would not be so if another mechanism were used. UNLINKABILITY security-arch@S5.5 Nothing on this in the security doc. What is the goal here? Minting a new key can be expensive. How do you prevent sites from pushing the button too often and causing a different sort of problem? From stefan.lk.hakansson@ericsson.com Thu May 24 05:47:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0321F864D for ; Thu, 24 May 2012 05:47:25 -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=[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 lZDTVqGQICmf for ; Thu, 24 May 2012 05:47:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2309F21F8648 for ; Thu, 24 May 2012 05:47:23 -0700 (PDT) X-AuditID: c1b4fb25-b7ff06d000002d8f-4b-4fbe2ddad542 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5D.00.11663.ADD2EBF4; Thu, 24 May 2012 14:47:22 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 24 May 2012 14:47:22 +0200 Message-ID: <4FBE2DD9.6030501@ericsson.com> Date: Thu, 24 May 2012 14:47:21 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre4t3X3+BlcXGFus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDeH5rMU7Oat+P3+KEsD42muLkZODgkBE4n3H5YxQ9hiEhfu rWfrYuTiEBI4xSix4vY9RghnLaPEh5lPWECqeAW0JW5uOscOYrMIqEpMWNLBCGKzCdhIrO2e wtTFyMEhKhAmsfqBBkS5oMRJqFYRAWGJra96mUBsYQEPie19H8BsIYEAif1z57GCtHIKBEqc 7gYrZxawlbgw5zqULS+x/e0cZohyXYl3r++xTmAUmIVkwywkLbOQtCxgZF7FKJybmJmTXm6k l1qUmVxcnJ+nV5y6iREYfAe3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MDq5iF3gWX+UK/GxeNtDhhTL+DMLUk99/+234LyV9Yp3D1w0RPJldsRs987k 2Zu29EOz+8oiNac36yrtr9xQVjETstWa9qNKwcC+dQ6Tit+d9vPvjzszHb65w/ZzzcdKv/JJ 5Z/Dzx15fmNa6qLEs6tnPDW7+mTtfpO1y3LiPmx9MZmfa5veh7NKLMUZiYZazEXFiQCz55nm DAIAAA== Subject: Re: [rtcweb] Strawman agenda and documents deadline for interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:47:25 -0000 We (I speak for the webrtc chairs!) would like to see a session on the data channel. In addition to the protocol drafts that should be discussed (draft-ietf-rtcweb-data-channel and draft-jesup-rtcweb-data-protocol), the webrtc WG has a session on the data API on Monday, and most likely there will be things discovered in that session that must be brought forward to the rtcweb WG. Stefan for the webrtc chairs. On 05/09/2012 05:52 PM, Ted Hardie wrote: > Howdy, > > We would like document updates for the interim to be complete by June > 4th, so that folks have time to review them before the interim > meeting. Slides associated with the documents should be in by June > 9th. Below is the current strawman agenda; please comment. > > regards, > > Ted, Cullen, Magnus > > Day 1 > > - Use Cases (2 H) > * New use cases needing additional discussion if not resolved on > mailing list. > * Use cases that require cloning (yes or no?) > > > - WebRTC's RTP Usage (3 H) > * Topologies that need to be supported > - what can be at one end of peer connection and what can be at other end > * Walk through of all the pieces suggested > - how to map media streams to rtp session. > -- example: describe how retransmission SSRCs relate to main SSRCs > - mapping between RTP and what happens in JS > > - JSEP > * Discussion of State Machine > * Interactions allowed > * SDP specification > -- mapping between SDP and what happens in JS > > - Security > * Continued Consent > * Identity and IdP > * Details of Security Architecture > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu May 24 07:43:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BABC21F85E4 for ; Thu, 24 May 2012 07:43:42 -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 LIKJWU7atFxl for ; Thu, 24 May 2012 07:43:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABC0121F859E for ; Thu, 24 May 2012 07:43:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6654586vbb.31 for ; Thu, 24 May 2012 07:43: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:content-transfer-encoding; bh=OKhKRCOSj1zrCDq3HL5EgFimSSWwsJXl99WO0PPu1fE=; b=jfGuJYu2sCsZ3VE/txE2z1rqJwGPnfVCs36ZugYkfGhFGPg7K84rcFwDt4j9AKoxvp jPTjfrKL70VIwDauSEbG/3aQi5wXITKUUn8zvWWFNOJu0GurQHDPLvR6GLCOfvLBDPoJ 9dVbBV0i3ou6oIrnUFXAZDVxWnxjgM7uCUgnGL0MWBlQrgQICN9wO//87S1WRhFfsEdh uNJQn2sMOh/inIpIktv5PzBbF4X6rAoBkTnG0hiFOQX61S6/SAaBhDLp9oduBg43xVK3 abuBJgQylVipuwLxggVs9KmUxk6BqzCT9ZhXgIimDPQ0tQOzr4IYs0BLvS0LS1+UzJsQ 6u9g== MIME-Version: 1.0 Received: by 10.220.107.198 with SMTP id c6mr7009413vcp.54.1337870620976; Thu, 24 May 2012 07:43:40 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 24 May 2012 07:43:40 -0700 (PDT) In-Reply-To: <4FBE2DD9.6030501@ericsson.com> References: <4FBE2DD9.6030501@ericsson.com> Date: Thu, 24 May 2012 07:43:40 -0700 Message-ID: From: Ted Hardie To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Strawman agenda and documents deadline for interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 14:43:42 -0000 On Thu, May 24, 2012 at 5:47 AM, Stefan Hakansson LK wrote: > We (I speak for the webrtc chairs!) would like to see a session on the da= ta > channel. In addition to the protocol drafts that should be discussed > (draft-ietf-rtcweb-data-channel and draft-jesup-rtcweb-data-protocol), th= e > webrtc WG has a session on the data API on Monday, and most likely there > will be things discovered in that session that must be brought forward to > the rtcweb WG. > > Stefan for the webrtc chairs. > Thanks for the input, Stefan; do you have a sense of how much time you think is needed? regards, Ted Hardie > > On 05/09/2012 05:52 PM, Ted Hardie wrote: >> >> Howdy, >> >> We would like document updates for the interim to be complete by June >> 4th, so that folks have time to review them before the interim >> meeting. =A0Slides associated with the documents should be in by June >> 9th. =A0Below is the current strawman agenda; please comment. >> >> regards, >> >> Ted, Cullen, Magnus >> >> Day 1 >> >> - Use Cases (2 H) >> * New use cases needing additional discussion if not resolved on >> mailing list. >> * Use cases that require cloning (yes or no?) >> >> >> - WebRTC's RTP Usage (3 H) >> * Topologies that need to be supported >> - what can be at one end of peer connection and what can be at other end >> * Walk through of all the pieces suggested >> - how to map media streams to rtp session. >> =A0-- example: describe how retransmission SSRCs relate to main SSRCs >> - mapping between RTP and what happens in JS >> >> - JSEP >> * Discussion of State Machine >> * Interactions allowed >> * SDP specification >> =A0-- mapping between SDP and what happens in JS >> >> - Security >> * Continued Consent >> * Identity and IdP >> * Details of Security Architecture >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu May 24 09:03:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649AE21F84A7 for ; Thu, 24 May 2012 09:03:28 -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 zft54BIh8oyW for ; Thu, 24 May 2012 09:03:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D214821F8483 for ; Thu, 24 May 2012 09:03:27 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6744510vbb.31 for ; Thu, 24 May 2012 09:03:27 -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:cc:content-type; bh=32ttmbJf2+U+khwchotqYDwWePun/gNx9inO5yXRAE8=; b=P066sWOxjlH5AmlAoVe52OgVJTaj1ffAVH6pWl5nZJhmzXBGdHGKOuyPpp6m0Xfb44 edFnXjROTaTR3HlvXFeRl4MIWtJhq6+kjcCgFr9KZOHMTPf4R6230z/fubOfimfgVSPv 7ze31+664ghxPzQX63HKV1hWeYTHeH0ifJykQ998j9C5WrDscc9egZ3Y4ktzOxbACnpk +nd1fQS3J74eO/lfHks7fjf2g5q7IYxeMc1oXwi40Wx0xouUV3cWJMQFV6SJEiDrmd14 hZ2DKvX8m20YVpZz53orLGdNLpbDFYNVy5d7rFbl8P1Gho8WmCNfaydA9PzkAUErJYpz GRXg== MIME-Version: 1.0 Received: by 10.220.218.208 with SMTP id hr16mr7195485vcb.49.1337875407341; Thu, 24 May 2012 09:03:27 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Thu, 24 May 2012 09:03:27 -0700 (PDT) Date: Thu, 24 May 2012 09:03:27 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings Subject: [rtcweb] Updated draft agenda for the 83.5 interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 16:03:28 -0000 Here's an updated draft agenda for the 83.5 interim meeting. After each document is discussed, the chairs will be looking for reviewers who can commit to review the updated document prior to Vancouver. We will also be looking to update the milestones on each document discussed; we'll ask for each document as we go, then reconfirm or reconcile at the end of the meeting. If you can volunteer to be a reviewer now, that would be much appreciated. Note-takers and jabber-room volunteers are also needed, and early volunteers for any of the above are promised an extra cookie at every break. If you can volunteer but will not be physically present at the meeting, a suitable non-cookie alternative will be found. Please send agenda comments to the list, thanks, Ted, Cullen, and Magnus June 12, 2012 Administrivia 30 minutes Use Cases 2 hours RTP 3 hours JSEP 90 minutes Admin 30 minutes JSEP 1 hour Data Channel 90 minutes ICE DTLS 1 hour Security 3 hours From stefan.lk.hakansson@ericsson.com Fri May 25 02:07:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FC221F863F for ; Fri, 25 May 2012 02:07:22 -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=[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 u+WXNMKmmeDY for ; Fri, 25 May 2012 02:07:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 11FD521F8623 for ; Fri, 25 May 2012 02:07:13 -0700 (PDT) X-AuditID: c1b4fb25-b7ff06d000002d8f-f0-4fbf4bc00bf5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F5.14.11663.0CB4FBF4; Fri, 25 May 2012 11:07:13 +0200 (CEST) Received: from [150.132.142.229] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 May 2012 11:07:11 +0200 Message-ID: <4FBF4BBE.3090001@ericsson.com> Date: Fri, 25 May 2012 11:07:10 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> In-Reply-To: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre5B7/3+BlcPsFis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEX/V7IWXJGueLb3BlMD41rRLkZODgkBE4mz7xYyQthiEhfu rWfrYuTiEBI4xShxdMZuKGcto8ScWQtZQKp4BbQlri06xg5iswioSpx6+4YVxGYTsJFY2z2F qYuRg0NUIExi9QMNiHJBiZMzn4C1iggIS2x91csEYgsLBEps6ZoEtlgIqPXP/ldgIzkFbCUO rVgCFmcGsi/Muc4CYctLbH87hxmiXlfi3et7rBMYBWYhWTELScssJC0LGJlXMQrnJmbmpJcb 6aUWZSYXF+fn6RWnbmIEht/BLb9VdzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYzZkvH+OQ/D5pt73+197fcpTFXg5e0k0eM6p5fyHH/9J+pdsobA7R0FCV8q rPpPs2ofe7U4SyTzlTzr0Qf2rH/kj0nnVKROPJ777Z+KBf8eVzmf7yv2xleumbhdbX6Un4Ov rXdDze4rj+frddzt5j3Z2rxM+sKU2TL7guqijtyUeV667b3u/RIlluKMREMt5qLiRACtcHSG DQIAAA== Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:07:22 -0000 On 05/16/2012 03:31 AM, Cullen Jennings wrote: > > Cone and symmetric nat are probably not what exactly what we mean > here - perhaps just refer to it as the various types of NATs > described in RFC 4787. The text was just lifted in (I have close to zero knowledge); referring to RFC 4787 sounds like a good idea to me. > > Might want to add to some use case that when A calls B, and B does > not reveal their IP address to A. Based on the discussion so far, I agree that this should be added somehow. > > Like to add Alice calls Bob with an encrypted media. Bob can tell the > that the encrypted media is from Alice and not from an MITM Sounds non controversial to add to me. > > Like to add ability to make a call in a situation where even small > sounds from microphone should be sent to the other side and not > filtered out. Emergency calls are examples of this as are some games > and "jam session" I think this is already covered in the "Distr. music band" , with req A17. > > Like to add case where application has one two video streams but one > is far more important than the other. Should be a way to make sure > that preferential treatment is given the the important stream over > the less important streams. What is there now is F24: The browser MUST be able to take advantage of capabilities to prioritize voice and video appropriately. This talks only about priority of audio and video relative to other traffic, perhaps we should add something about prioritizing between different audio/video flows as well. > > In F22, "the IVR" -> "an DTMF based IVR" Agree. > > I have a hard time deciding what level the requirements should be at. > It seems likely that given the level they are currently at, the > requirements are somewhat incomplete. As long as we treat these as > partial set of requirements derived from the use cases, I'm fine with > that. > > > New use case: > > Imagine a service like webex that facilitates collaboration between > two companies called A and B. Webex has no need to see the content of > the communication from A to B. So webex might run the web server that > helps set up a RTCWeb session between A and B, but webex needs to be > able to write it's code such that it does not get the keying material > used to encrypt the media from A to B and the companies need to be > able to verify that webex did not get the keys. Webex has no need to > see the media from A to B and if it can provide this sort of promise > that it does not get the media, it makes it much easier for a > customer (say Juniper) to use webex and know the contents of their > calls are not being sold or used by a competitor. Given how much > WebRTC will be used by cloud services, this is an important feature. > When installing the "webex" application in the browser and granting > permissions to the application, it would be good to have one of the > permissions be if the JS got access to the media or keying material > for it to enforce this promise. > > Note this use case is not phrase to say this is the only way it can > work. This is not mutually exclusive with they type of use cases > described by Skype folks where there is an explicitly desire to make > sure the calling service does have the keys to decrypt the media. > > > > > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri May 25 09:02:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AA021F86AD for ; Fri, 25 May 2012 09:02: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=[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 oop1OjYVQ6yR for ; Fri, 25 May 2012 09:02:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39021F8674 for ; Fri, 25 May 2012 09:02:44 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9A2A322E257; Fri, 25 May 2012 12:02:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Fri, 25 May 2012 10:02:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <734CDDE5-445D-4864-B9CA-EA289D0244AA@iii.ca> References: <4FBA4399.4050909@ericsson.com> <4FBB816F.7040900@ericsson.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interim participation registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:02:45 -0000 It does not matter for webex. I think it is slightly nice for the = chairs and others to have an who will be remote and who will be there in = person just so they know if the people that have been involved in a = given mailing list discussion will be "present" in some form. I will be = remote. I guess next time we can make the google poll have three = options. Cullen On May 22, 2012, at 6:09 AM, Romascanu, Dan (Dan) wrote: > Maybe it is important for Webex, if you plan to use Webex for remote = participation. Or other tool. I do not know. In any case, you would need = a separate doodle or a different option on the current doodle.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Tuesday, May 22, 2012 3:07 PM >> To: Romascanu, Dan (Dan) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Interim participation registration >>=20 >> On 2012-05-22 13:18, Romascanu, Dan (Dan) wrote: >>> Do you need a count only for people who plan to attend on-site? >>=20 >> Good question. Yes, the this was for physical participation. We know >> that we will have some number of remote participation. I don't know = how >> important it is to get a head count for them. >>=20 >> Cheers >>=20 >> Magnus >>=20 >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Magnus Westerlund >>>> Sent: Monday, May 21, 2012 4:31 PM >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Interim participation registration >>>>=20 >>>> Hi, >>>>=20 >>>> I would like to have a firm understanding of how many that really >> will >>>> show up for either day of the interim meeting. The main purpose is >> to >>>> ensure that break snacks and lunch are provided in the right = amount. >>>>=20 >>>> So please fill in this doodle to register your participation for >> each >>>> of >>>> the days that you will be present. >>>>=20 >>>> http://www.doodle.com/x3z6uhsy4q4s6fc4 >>>>=20 >>>> Thanks >>>>=20 >>>> Magnus Westerlund >>>> Interim meeting host >>>>=20 >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >> -- >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> = -------------------------------------------------------------------- >> -- >>>> Ericsson AB | Phone +46 10 7148287 >>>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> = -------------------------------------------------------------------- >> -- >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>=20 >>=20 >> -- >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri May 25 09:03:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684D221F8714 for ; Fri, 25 May 2012 09:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAhiR5kt0cUX for ; Fri, 25 May 2012 09:02:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4D21F871C for ; Fri, 25 May 2012 09:02:59 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D475B22E259 for ; Fri, 25 May 2012 12:02:57 -0400 (EDT) From: Cullen Jennings Content-Type: multipart/alternative; boundary=Apple-Mail-7-1024808448 Date: Fri, 25 May 2012 10:02:57 -0600 References: <4AAE17A6-0E0A-492C-96D0-C7D0DBF5C78F@netapp.com> To: rtcweb@ietf.org Message-Id: <0D22417B-046E-4490-9A74-C877C6DCAFF2@iii.ca> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:03:00 -0000 --Apple-Mail-7-1024808448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >=20 > IAB / IRTF Workshop on > Congestion Control for Interactive > Real-Time Communication > July 28, 2012 > Vancouver, Canada > =20 > The IAB and IRTF will hold a workshop on Congestion Control for = Interactive Real-Time Communication" in Vancouver, Canada on Saturday, = July 28th, 2012 prior to the IETF-84 meeting (see = http://www.ietf.org/meeting/84/index.html). Participation at the = workshop is free of charge. There is no requirement to either register = with or attend the IETF-84 meeting that follows the workshop. > =20 > The workshop organizers would like to foster a discussion on: > What are appropriate congestion signals to use for interactive media = and data? > What existing congestion control algorithms are appropriate for = interactive media and data? What properties would be desirable in new = congestion control algorithms? > Measurement and/or simulations of new congestion signals (e.g., = delay-based) and their interaction with existing congestion control = mechanisms. > What are good available techniques for adjusting sending rates for = interactive media and data? What are the limits of those techniques? = What properties would be desirable in new techniques? > What application-specific considerations have to be taken into = account? > How can we ensure that real-time communications are well-behaved with = respect to other Internet applications while still providing good = quality? > What should the IETF and/or IRTF do? > The organizers seek position papers on any or all of these topics, as = well as other topics related to congestion control for interactive = realtime media. > =20 > Every prospective workshop participant must submit a position paper = containing a name and an email address. Authors of accepted papers will = be invited to the workshop. Papers up to 3 pages, formatted in HTML, = PDF, or plain text (for example, as a submitted Internet-Draft) are = ideal. Accepted position papers will be published. Additional details = about the meeting venue will be provided to authors of accepted papers. > Important Dates >=20 > Position paper submission deadline: June 23, 2012 > Notification to paper authors: June 30, 2012 > Workshop date: July 28, = 2012 > Additional Details >=20 > Additional details on the workshop as well as the submission process = is available at http://www.iab.org/cc-workshop/ > Contact >=20 > To sponsors: If you are interested to help us working towards better = interactive media congestion control mechanisms on the Internet (such as = by making a contribution towards catering costs and room rental), please = contact us! >=20 > In case of questions please send email to mary.ietf.barnes at = gmail.com. > =20 --Apple-Mail-7-1024808448 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


IAB / IRTF Workshop on
Congestion Control for = Interactive
Real-Time Communication

July 28, = 2012
Vancouver, Canada

 
The IAB and IRTF = will hold a workshop on Congestion Control for Interactive Real-Time = Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior = to the IETF-84 meeting (see ).  Participation at the workshop is free of charge. There = is no requirement to either register with or attend the IETF-84 meeting = that follows the workshop.
  1. What are = appropriate congestion signals to use for interactive media and = data?
  2. What existing congestion control = algorithms are appropriate for interactive media and data? What = properties would be desirable in new congestion control = algorithms?
  3. What are = good available techniques for adjusting sending rates for interactive = media and data? What are the limits of those techniques? What properties = would be desirable in new techniques?
  4. What = application-specific considerations have to be taken into = account?
  5. How can we = ensure that real-time communications are well-behaved with respect to = other Internet applications while still providing good = quality?
  6. What = should the IETF and/or IRTF do?

Important = Dates

Additional Details

Additional details on the workshop as well = as the submission process is available at To sponsors: If you are = interested to help us working towards better interactive media = congestion control mechanisms on the Internet (such as by making a = contribution towards catering costs and room rental), please contact = us!In case of questions = please send email to mary.ietf.barnes at  To: "rtcweb@ietf.org" Thread-Topic: Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents Thread-Index: Ac09pxh6IjsyEuzLTLK6g7yOaRYM+g== Date: Tue, 29 May 2012 14:26:55 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] X-AnalysisOut: [v=1.0 c=1 a=sQVNTnci9XEA:10 a=sAIEQWrZK3sA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=srMsL6ituuWTYe] X-AnalysisOut: [ky9Bs9mA==:17 a=-AcrK0NpdUhJnkzQONYA:9 a=CjuIK1q_8ugA:10 a] X-AnalysisOut: [=sqz0dyHaEY9lVqR9:21 a=cY8Cc_q-1cDHUINB:21] Subject: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 14:27:17 -0000 I reviewed the latest version of the drafts and below are my comments/sugge= stions/corrections (not as comprehensive as Mark's). In general I think the documents are well written with good references and = paint a rather comprehensive picture of the issues to be addressed for rtcw= eb. Draft-ietf-rtcweb-security-02 1.Introduction - second paragraph after the diagram:=20 "Each of their browsers exposes standardized JavaScript calling APIs which = are used by the Web server to set up a call between Alice and Bob." This statement can be a bit more clear in that the APIs are executed local= ly (in the user agent) as java script downloaded from the Web Server. The = next paragraph eludes to the fact that logic is controlled by the calling s= ervice but I think it will be important to distinguish between APIs impleme= nted by the user-agent and APIs/functions implemented by the calling servic= e. 4.1 Access to Local Devices.=20 Since this describes the threat I think is important to point out the fact = that even when the user provides consent it is difficult for them to determ= ine the real reason they give the consent to a site. Take the scenario in w= hich a site obtains consent from the user for an app that captures a clip a= nd saves it on the user's hard drive. Later on, if the user gave permanent = consent to the site, the site can obtain access to the camera for the purpo= se of streaming without the user knowing that. This can be confusing for us= ers even if they trust the site. 4.2 IP location Privacy "Note that as soon as the callee sends their ICE candidates, the callee lea= rns the callee's IP addresses."=20 This must be "the caller learns the callee's IP address" 4.3.2.3. Third Party Identity "It is possible (see[I-D.rescorla-rtcweb-generic-idp]) to use systems of th= is type to authenticate RTCWEB calls, linking them to existing user notions= of identity (e.g., Facebook adjacencies). Calls which are authenticated in thi= s fashion are naturally resistant even to active MITM attack by the calling= site." Not to get too much into semantics, I think it is important to make the dis= tinction that users are authenticated (using whatever IdP) and calls are au= thorized based on the assertions provided by the Idp for the authenticated = user. Draft-ietf-rtcweb-security-arch-01 1.Introduction "The Real-Time Communications on the Web (RTCWEB) working group is tasked w= ith standardizing protocols for real-time communications between Web browse= rs." While there's nothing inaccurate about the statement, I would like to make = it more generic because it is more than just communication between web brow= sers. In my opinion the WEB part in the acronym is all about using the web = technologies to enable real time communications. A proposed edited definition would be "... standardization protocols for en= abling real-time communications within user-agents using web technologies (= e.g JavaScript)". 6.2 Privacy I have been trying to identify the appropriate section for a rather controv= ersial requirement: Lawful Intercept. It is expected that service provider= s for RTCWeb/WebRTC will be required to provide support to lawful intercept= and I think we need to capture these requirements so we can map them to th= e security architecture.=20 Thanks, Dan From lists@infosecurity.ch Tue May 29 07:47:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFAF11E809B for ; Tue, 29 May 2012 07:47:37 -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 Lo0m1Zp3FJEf for ; Tue, 29 May 2012 07:47:36 -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 8552611E808A for ; Tue, 29 May 2012 07:47:36 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so2188834wib.13 for ; Tue, 29 May 2012 07:47:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=+MzolvlonCzu9Q+rxEH8J6ZQJ5Nk0d/xdYTBiHdr1u0=; b=BkfNsGVd1d9ntr0NrOLsNQGpyq1CqGdNeGtR1EU/7848xANQZscy46Mh4nsfcuD4UD qG6w8V3aQ+K+VWUwSFubnOydjUG7ywnHph8phoKX553F7Oe+eyei5jlZ520eexLd3oJ/ GhmG+egFzsLqddNDuHWVpJupE8aG/UQsqlKHUXQrrPDzZnre0yQo+R6pj8UCUGXdm6L0 lS3AcBdNcB9OkUBQ8XFhzNny413Ynv57KvJ5b5EmeQpTjJOypg9XUoWx0US9q9uwW4FS 7S/bkr5ikJRWvK2m6UQJ6aAfV89U3L4kCWfmXjSw/d+bnwHp5Hv7TnDrjra1A4l+6E2H yG6g== Received: by 10.216.196.147 with SMTP id r19mr7846723wen.87.1338302855509; Tue, 29 May 2012 07:47:35 -0700 (PDT) Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. [93.57.41.37]) by mx.google.com with ESMTPS id hv7sm41377555wib.0.2012.05.29.07.47.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 07:47:34 -0700 (PDT) Sender: Fabio Pietrosanti Message-ID: <4FC4E183.90202@infosecurity.ch> Date: Tue, 29 May 2012 16:47:31 +0200 From: "Fabio Pietrosanti (naif)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> In-Reply-To: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmjfpReEbsAjPrhN1sap5h6+k1RY6sWApDMdQtkAZEKAvt/9yjL3AMihHdvnlpwvxkKGau0 Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 14:47:37 -0000 On 5/29/12 4:26 PM, DRUTA, DAN wrote: > 6.2 Privacy > > I have been trying to identify the appropriate section for a rather controversial requirement: Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide support to lawful intercept and I think we need to capture these requirements so we can map them to the security architecture. IETF Policy on Wiretapping http://tools.ietf.org/html/rfc2804 Fabio From harald@alvestrand.no Tue May 29 08:51:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5529921F86F4; Tue, 29 May 2012 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 yrmS5h0F5Y+p; Tue, 29 May 2012 08:51:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E9B1321F86D5; Tue, 29 May 2012 08:51:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2A4039E106; Tue, 29 May 2012 17:51:12 +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 BhFlJdEdEcQ4; Tue, 29 May 2012 17:51:11 +0200 (CEST) Received: from [192.168.179.204] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5744939E031; Tue, 29 May 2012 17:51:08 +0200 (CEST) Message-ID: <4FC4F062.40209@alvestrand.no> Date: Tue, 29 May 2012 17:50:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" , mmusic References: <20120529154655.31962.25833.idtracker@ietfa.amsl.com> In-Reply-To: <20120529154655.31962.25833.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120529154655.31962.25833.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020209030308030403010803" Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:51:15 -0000 This is a multi-part message in MIME format. --------------020209030308030403010803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As directed in the Paris IETF meeting, this draft now tries to be a more generic mechanism with a specific specified application to media streams. It is still marked with "comments to RTCWEB, please", but it is up to the chairs which group (if any) should adopt it as a WG item. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-msid-02.txt Date: Tue, 29 May 2012 08:46:55 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-alvestrand-rtcweb-msid-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-msid Revision: 02 Title: Cross Session Stream Identification in the Session Description Protocol Creation date: 2012-05-29 WG ID: Individual Submission Number of pages: 10 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations betweeen media streams within different RTP sessions. This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of"media stream" /"media stream track" using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. The IETF Secretariat --------------020209030308030403010803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit As directed in the Paris IETF meeting, this draft now tries to be a more generic mechanism with a specific specified application to media streams.

It is still marked with "comments to RTCWEB, please", but it is up to the chairs which group (if any) should adopt it as a WG item.

                  Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-02.txt
Date: Tue, 29 May 2012 08:46:55 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 02
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2012-05-29
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations betweeen media streams within
   different RTP sessions.

   This mechanism is used to signal the association between the RTP
   concept of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media
   stream track&quot; using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat
--------------020209030308030403010803-- From cb.list6@gmail.com Tue May 29 10:02:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4411E80E6 for ; Tue, 29 May 2012 10:02:43 -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, 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 BBAzg4RNSCeS for ; Tue, 29 May 2012 10:02:42 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A037E11E80BC for ; Tue, 29 May 2012 10:02:42 -0700 (PDT) Received: by dacx6 with SMTP id x6so5609219dac.31 for ; Tue, 29 May 2012 10:02:42 -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=odlLBCJduhc/4B0OgPW5QIUfnQHpJLwxbVdWHjswmSA=; b=Z3TPpd54qh/9tW6ZaDItz6t7iGuEyiinpw0ZlDoD6lSOjbwNScSJw0/wk3eqn6y6lp l3NELqt8Ae9Tr7Uy/xuM/X6e0kUOhtXJn5gmI/eN/mS7DEYATNeZ5QO786zX5fXKhCOH ABVnRQ8Qk1ISeOpM4UKD+qOFUfBXMIVOnn6qqnFrny4SclakLbNKJ8G69Bs8hLqBkPKP opYXonZJuEwKuP2TzhpbEtAwQo9PeVE4OlkXsXfWv2YwmPsn48bxMNxTglgjnN0Yzapn m+NUKID733zOar/36HtWCBKcwvpvjUA/qZ6TyDbx4mvXl7gN3iyi+kpR1c9mDUZ/l79T clqw== MIME-Version: 1.0 Received: by 10.68.238.228 with SMTP id vn4mr39483039pbc.132.1338310962324; Tue, 29 May 2012 10:02:42 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Tue, 29 May 2012 10:02:42 -0700 (PDT) Date: Tue, 29 May 2012 10:02:42 -0700 Message-ID: From: Cameron Byrne To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:02:43 -0000 Is there yet a pointer on how a SIM / IMS based identity will work with the webRTC web server for authentication? I think the obvious approach is for the SIM secret key to be bound to a username / password on the web server, and the web server proxies the authentication and registration into IMS (if you give me the right username credentials via the web, i will register you into IMS with the secret key), but that requires the undesirable step of exposing the SIM secret key to the web server or someplace outside the HSS/HLR for binding with the username password. Thoughts? Pointers? Thanks, CB From martin.thomson@gmail.com Tue May 29 10:17:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF711E80EB for ; Tue, 29 May 2012 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 QlqX68rcW2LN for ; Tue, 29 May 2012 10:17:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E87DA11E80E5 for ; Tue, 29 May 2012 10:17:01 -0700 (PDT) Received: by bkty8 with SMTP id y8so4060268bkt.31 for ; Tue, 29 May 2012 10:17:01 -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=33uKze44fos6D8cTLeF/2klPH3dx8c+s4eJVjKB9z/s=; b=0urfJ1n+Kbksmi6d9SdQ70eKftxrF388crVx9y69vDoQ42jD21DUKkpe+n0rnPGvYI nS2/3isBW0eQ8kpM0Mr4z/w8Qctdvs+HXx4JKG8Rbx0kSHN5SHgalizMPsxueotWCt7Z cCQ7ibIdcv2oycq9ZMVlZ/Dw6E8CfEXYnCcveidt+LE9uOHqM7ezh4MucHbc71tyCiU0 AVO95lC3OrvZuTXm2gB/xXrZHLc/aKx7jESFfBU+eRl8aa7Fp8tWbv10a+us09tICftp kHy4mhdmJ43J1TgJ+Qju7we4cFYe3YtIyQuNHECdzLv/VivxxbCoNE95iswnmNaj0L0q CHaA== MIME-Version: 1.0 Received: by 10.205.119.12 with SMTP id fs12mr4388753bkc.49.1338311820934; Tue, 29 May 2012 10:17:00 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 29 May 2012 10:17:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 10:17:00 -0700 Message-ID: From: Martin Thomson To: Cameron Byrne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:17:03 -0000 That's assuming that you want to authenticate as a mobile identity. Why would it not be sufficient to authenticate as a linked identity? That is, I am "john.smith@example.com" and some of my calls originate or terminate at "+1-234-555-6789". Can you expand on your use case a little? On 29 May 2012 10:02, Cameron Byrne wrote: > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? > > I think the obvious approach is for the SIM secret key to be bound to > a username / password on the web server, and the web server proxies > the authentication and registration into IMS (if you give me the right > username credentials via the web, i will register you into IMS with > the secret key), but that requires the undesirable step of exposing > the SIM secret key to the web server or someplace outside the HSS/HLR > for binding with the username password. > > Thoughts? =C2=A0Pointers? > > Thanks, > > CB > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cb.list6@gmail.com Tue May 29 10:22:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9F11E810D for ; Tue, 29 May 2012 10:22:09 -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 ZCQITg3HRa69 for ; Tue, 29 May 2012 10:22:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 869AA11E810B for ; Tue, 29 May 2012 10:22:07 -0700 (PDT) Received: by dacx6 with SMTP id x6so5630753dac.31 for ; Tue, 29 May 2012 10:22:07 -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=hmv/zyQgZEJLmT8deRnOMYCK4EjYFY7ckDjyL77rc+8=; b=fbqcyiuhy7DrD8o6KGbaqTb2sE1r4Yg8QwLBof+nIq6orrAOczUdVkAE22K2/g6QZx Qz3Zklm3K3/cAOwOKvrWeq4GvULrnDlEZjOqmR2KpFsCaxBokXGUg/Mk9i0yi47aCMjM qfKzlfvWwuZUMdBQX6Vv9Vwcu59au+/YWp7GX9mwqUYMo4zyArX/RxPDQwWyQota4Pz1 LcB00YR/AaUEGl6Io5uE1nJsxcjydj8uvd9EAzG69cEZGDxDNafpddi0OHOpHu3CALW9 wROwg2pTnr0HVBIDG/7qECXK5jgja18NQGgPlUsF7JWnqhWKBDogupoM34Xe1iUJiVUb /MCQ== MIME-Version: 1.0 Received: by 10.68.234.101 with SMTP id ud5mr7863165pbc.41.1338312127250; Tue, 29 May 2012 10:22:07 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Tue, 29 May 2012 10:22:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 10:22:07 -0700 Message-ID: From: Cameron Byrne To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:22:09 -0000 On Tue, May 29, 2012 at 10:17 AM, Martin Thomson wrote: > That's assuming that you want to authenticate as a mobile identity. > Why would it not be sufficient to authenticate as a linked identity? > > That is, I am "john.smith@example.com" and some of my calls originate > or terminate at > "+1-234-555-6789". > > Can you expand on your use case a little? > Basic use case is exposing mobile operator IMS services via webrtc. Such that webrtc is an IMS clients of sorts and the various IMS services are exposed via webrtc just as they are exposed to an IMS client (voice, video, presence, IM, ...). Using the mobile identity to register into the IMS domain seems to be the simplest fit if authentication is possible. From a deployment and operational ease perspective, it sure would be nice if nothing had to change in the IMS cloud and webrtc was just a proxy / client for accessing the IMS services. CB > On 29 May 2012 10:02, Cameron Byrne wrote: >> Is there yet a pointer on how a SIM / IMS based identity will work >> with the webRTC web server for authentication? >> >> I think the obvious approach is for the SIM secret key to be bound to >> a username / password on the web server, and the web server proxies >> the authentication and registration into IMS (if you give me the right >> username credentials via the web, i will register you into IMS with >> the secret key), but that requires the undesirable step of exposing >> the SIM secret key to the web server or someplace outside the HSS/HLR >> for binding with the username password. >> >> Thoughts? =A0Pointers? >> >> Thanks, >> >> CB >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Tue May 29 10:26:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9706E21F854F for ; Tue, 29 May 2012 10:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 o+NMegu5AxlN for ; Tue, 29 May 2012 10:26:32 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7F21F8548 for ; Tue, 29 May 2012 10:26:31 -0700 (PDT) Received: by bkty8 with SMTP id y8so4070463bkt.31 for ; Tue, 29 May 2012 10:26:31 -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=zvBK4iiGaTTcLfvv1Bw/2jU34ZIm5ljEszo63gPN4aI=; b=fhzk7LXVvZ9Nd2ESbMssmO0MuHjTbiZv+We8lnuzecFBKzZnsK+yInFCSMNAkU9b9l 294QU2CBXM/Lb6MhZeLCur0N24X4mztUAbDocjt+wnSMzJo0qZelVqn1Z7O+VSkmrHm8 E91GEOfz4n2sl7qeL0pbNdR8C5xrf7+KZhew8nEYd5DDn41bYpsZHjpymqaoJtq4SQku TXbAyNFUW9LTc62vL/BR2yOr2SIA1UfFe4GMtEQ8NHNStL0Cb56qUyBIk8Daf0xYmTMa UGvKKYuGdMOKwX5tzUOVTb/KcbMvadKjoLTsVsKDbcj0+j74chqx9/UeR22hT7i8RwdT fPBA== MIME-Version: 1.0 Received: by 10.204.152.195 with SMTP id h3mr6874846bkw.119.1338312390713; Tue, 29 May 2012 10:26:30 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 29 May 2012 10:26:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 10:26:30 -0700 Message-ID: From: Martin Thomson To: Cameron Byrne Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:26:32 -0000 On 29 May 2012 10:22, Cameron Byrne wrote: > Using the mobile identity to register into the IMS domain seems to be > the simplest fit if authentication is possible. From a deployment and > operational ease perspective, it sure would be nice if nothing had to > change in the IMS cloud and webrtc was just a proxy / client for > accessing the IMS services. How your clients authenticate with your service is largely not a problem for this working group... That said, if you want to authenticate as an IMS UE, then you need to be able to offer the credentials that a UE would offer. So why not proxy the authentication requests too? Then the server doesn't need to store credentials. From rbarnes@bbn.com Tue May 29 10:29:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C988121F855D for ; Tue, 29 May 2012 10:29:05 -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 Dif-bDT6RPvq for ; Tue, 29 May 2012 10:29:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37D21F8550 for ; Tue, 29 May 2012 10:29:05 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:60059) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZQDg-000L8G-EM; Tue, 29 May 2012 13:28:32 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 29 May 2012 13:29:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:29:05 -0000 To answer your question directly, I don't think there's a current = document. However, ISTM that the HSS/HLR could just act as an Identity Provider = [1], for example by layering BrowserID [2] on top of the IMS: -- UE generates key pair locally -- UE authenticates to HSS/HLR -- UE presents public key to HSS/HLR -- HSS/HLR provides a certificate containing that public key -- UE presents that certificate to the remote party -- Remote party validates certificate under HSS/HLR public key The main question would then be what identifiers a relying party would = allow an HSS/HLR to vouch for. For SIP URIs, there's no problem, = because the domain of the HSS/HLR would be clear (the domain part of the = URI). But for telephone numbers, the HSS/HLR would have to be a "third = party" IdP, which is problematic [3]. Hope this helps, --Richard [1] [2] = [3] Slide 5 of = On May 29, 2012, at 1:02 PM, Cameron Byrne wrote: > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? >=20 > I think the obvious approach is for the SIM secret key to be bound to > a username / password on the web server, and the web server proxies > the authentication and registration into IMS (if you give me the right > username credentials via the web, i will register you into IMS with > the secret key), but that requires the undesirable step of exposing > the SIM secret key to the web server or someplace outside the HSS/HLR > for binding with the username password. >=20 > Thoughts? Pointers? >=20 > Thanks, >=20 > CB > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Tue May 29 10:36:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B111E80F7 for ; Tue, 29 May 2012 10:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 xuzKYgWajSr4 for ; Tue, 29 May 2012 10:36:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D011E80EE for ; Tue, 29 May 2012 10:36:25 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4THaOdI011144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 May 2012 12:36:24 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4THaN1e002538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 May 2012 12:36:24 -0500 Received: from [135.222.232.150] (USMUYN0L055118.mh.lucent.com [135.222.232.150]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4THaMSB021361; Tue, 29 May 2012 12:36:23 -0500 (CDT) Message-ID: <4FC50916.7060200@alcatel-lucent.com> Date: Tue, 29 May 2012 13:36:22 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> <4FC4E183.90202@infosecurity.ch> In-Reply-To: <4FC4E183.90202@infosecurity.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 17:36:26 -0000 Yes, but Dan's proposal surely takes this into consideration as I read it. To this end, I think we need to ensure that the requirements that we develop do not interfer with Lawful Intercept requirements that providers must implement. (And to effect that we don't have to touch the LI requirements per se.) Igor On 5/29/2012 10:47 AM, Fabio Pietrosanti (naif) wrote: > On 5/29/12 4:26 PM, DRUTA, DAN wrote: >> 6.2 Privacy >> >> I have been trying to identify the appropriate section for a rather controversial requirement: Lawful Intercept. It is expected that service providers for RTCWeb/WebRTC will be required to provide support to lawful intercept and I think we need to capture these requirements so we can map them to the security architecture. > IETF Policy on Wiretapping > http://tools.ietf.org/html/rfc2804 > > Fabio > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Tue May 29 11:16:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6411E80F0 for ; Tue, 29 May 2012 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.129 X-Spam-Level: X-Spam-Status: No, score=-7.129 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 KT039IbNCHAd for ; Tue, 29 May 2012 11:16:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29E21F86F6 for ; Tue, 29 May 2012 11:16:15 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q4TIGCYU007648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 May 2012 13:16:12 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4TIGBwI002588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 May 2012 13:16:12 -0500 Received: from [135.222.232.150] (USMUYN0L055118.mh.lucent.com [135.222.232.150]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4TIG9OZ020825; Tue, 29 May 2012 13:16:09 -0500 (CDT) Message-ID: <4FC51269.1010707@alcatel-lucent.com> Date: Tue, 29 May 2012 14:16:09 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020409090702060102060306" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:16:16 -0000 This is a multi-part message in MIME format. --------------020409090702060102060306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cameron, Indeed, there is a lot of interesting work done in this field. (A few thousand messages back you will find some postings on the subject, including mine.) A few references will follow, but first--the problem. The problem is the access to "the SIM secret key." The latter is unavailable by design: all ISIM operations are performed by the card. IMS itself builds on the AKA protocol, which establishes the necessary keys. From there, 3GPP recommends bootstrapping using the Generic Bootstrapping Architecture. 3GPP defines this in detail in 3GPP TS 33.220. 3GPP has a technical report, TR 33.924, which specifies an implementation of OpenID with GBA. One problem here is client deployment. Until GB function is deployed in the Client, it is, of course, impossible to use any solution that depends on it. Hence the alternative solution: to use AKA. My colleagues and I have described a way to do so in a Bell Labs Technical Journal paper http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/abstract. Subsequently, a method to implement OpenID/AKA interworking has been specified by ITU-T in Recommendation Y.2722 NGN Identity Management Mechanisms. (All ITU-T Recommendations as well as 3GPP documents are available on their respective sites.) But the latter solution is still a non-solution as long as there is no client API for interactions with the SIM card. And this was the conclusion of a discussion on this list a while ago... We need either such an API or GBA deployment to progress. Igor On 5/29/2012 1:02 PM, Cameron Byrne wrote: > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? > > I think the obvious approach is for the SIM secret key to be bound to > a username / password on the web server, and the web server proxies > the authentication and registration into IMS (if you give me the right > username credentials via the web, i will register you into IMS with > the secret key), but that requires the undesirable step of exposing > the SIM secret key to the web server or someplace outside the HSS/HLR > for binding with the username password. > > Thoughts? Pointers? > > Thanks, > > CB > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020409090702060102060306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cameron,

Indeed, there is a lot of interesting work done in this field. (A few thousand messages back you will find some postings on the subject, including mine.)  A few references will follow, but first--the problem.

The problem is the access to "the SIM secret key."  The latter is unavailable by design: all ISIM operations are performed by the card. IMS itself builds on the AKA protocol, which establishes the necessary keys. From there, 3GPP recommends bootstrapping using the Generic Bootstrapping Architecture. 3GPP defines this in detail in 3GPP TS 33.220. 

3GPP has a technical report, TR 33.924, which specifies an implementation of OpenID with GBA. One problem here is  client deployment.  Until GB function is deployed in the Client, it is, of course, impossible to use any solution that depends on it. 

Hence the alternative solution: to use AKA. My colleagues and I have described a way to do so in a Bell Labs Technical Journal paper http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/abstract. Subsequently, a method to implement OpenID/AKA interworking has been specified by ITU-T in   Recommendation  Y.2722 NGN Identity Management Mechanisms. (All ITU-T Recommendations as well as 3GPP documents are available on their respective sites.)

But the latter solution is still a non-solution as long as there is no client API for interactions with the SIM card. And this was the conclusion of a discussion on this list a while ago...

We need either such an API or GBA deployment to progress.

Igor




On 5/29/2012 1:02 PM, Cameron Byrne wrote: 
Is there yet a pointer on how a SIM / IMS based identity will work
with the webRTC web server for authentication?

I think the obvious approach is for the SIM secret key to be bound to
a username / password on the web server, and the web server proxies
the authentication and registration into IMS (if you give me the right
username credentials via the web, i will register you into IMS with
the secret key), but that requires the undesirable step of exposing
the SIM secret key to the web server or someplace outside the HSS/HLR
for binding with the username password.

Thoughts?  Pointers?

Thanks,

CB
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------020409090702060102060306-- From martin.thomson@gmail.com Tue May 29 12:41:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5730511E80C2 for ; Tue, 29 May 2012 12:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 s6CftQJj7C3S for ; Tue, 29 May 2012 12:41:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D272311E80B6 for ; Tue, 29 May 2012 12:41:48 -0700 (PDT) Received: by bkty8 with SMTP id y8so4217286bkt.31 for ; Tue, 29 May 2012 12:41: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:content-transfer-encoding; bh=2wV47++Zl4nRyLNN2hkrPgqQZByZvqgQPA7zShopBks=; b=hpaU2LJ6fTkWjih+cVrA990FR0neLlxwaKiuYLhkY+u6HZWZoo8HhPw7+maqRi7FuA tSeMJ20y8+MWz0snMxgqtSHSmNakjUt6ZBUHixKekUWuWXq2GHw6Ok7D6bx0cCpyEpvf nvE4NRfEnAk2lhYu1fqsMhvty5qoh9uXQvhRjgvjO9Hz8Z806AK0+yIfBKb7HpUTLd5l fBOBeoqReqKai2ajatm4HuPFniuWaPN0VF2+rN+sajM2QmTqLnpRiOiijvmTmv2vkUEL XPaKgRFgxE9sxPhnETIrNG9+DUrDAIkLeSOUZrpknDsakMsnhzpqkOhJybkttF742SaO 18Yw== MIME-Version: 1.0 Received: by 10.204.152.13 with SMTP id e13mr7444646bkw.46.1338320507868; Tue, 29 May 2012 12:41:47 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 29 May 2012 12:41:47 -0700 (PDT) In-Reply-To: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Tue, 29 May 2012 12:41:47 -0700 Message-ID: From: Martin Thomson To: "DRUTA, DAN" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 19:41:50 -0000 On 29 May 2012 07:26, DRUTA, DAN wrote: > I reviewed the latest version of the drafts and below are my comments/sug= gestions/corrections (not as comprehensive as Mark's). :) (see From: header) > 4.1 Access to Local Devices. > Since this describes the threat I think is important to point out the fac= t that even when the user provides consent it is difficult for them to dete= rmine the real reason they give the consent to a site. Take the scenario in= which a site obtains consent from the user for an app that captures a clip= and saves it on the user's hard drive. Later on, if the user gave permanen= t consent to the site, the site can obtain access to the camera for the pur= pose of streaming without the user knowing that. This can be confusing for = users even if they trust the site. Once a site has your camera, there's no fundamental difference between still frame capture and video streaming (for example). Streaming is just an optimization of the recording interface already present. A site can acquire still images and upload them (using JSONP, HTTP form post, whatever) one by one. Streaming just means that they can do so without clogging up my network connection with 30 JPEGs per second. I had to think about this one a bit before understanding why this isn't a problem. Maybe that can be rectified by adding text. The more challenging interface problem deals with the presentation of permissions dialogs for specific remote users, not the browser. The security architecture draft hints that this might be necessary, but it offers a far more challenging UI design problem than the above. > 4.2 IP location Privacy > "Note that as soon as the callee sends their ICE candidates, the callee l= earns the callee's IP addresses." > This must be "the caller learns the callee's IP address" addresses :) > 6.2 Privacy > > I have been trying to identify the appropriate section for a rather contr= oversial requirement: =C2=A0Lawful Intercept. It is expected that service p= roviders for RTCWeb/WebRTC will be required to provide support to lawful in= tercept and I think we need to capture these requirements so we can map the= m to the security architecture. Every time I think of this, I am more convinced that there is nothing that needs to be specified. Interestingly, the IdP proposal potentially moves the onus for meeting these requirements to the IdP, ... impersonation being the key. From harald@alvestrand.no Tue May 29 13:43:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0F11E80C1 for ; Tue, 29 May 2012 13:43:53 -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 sdFGo-1nYfKe for ; Tue, 29 May 2012 13:43:53 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C186511E8085 for ; Tue, 29 May 2012 13:43:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E72F39E0FA for ; Tue, 29 May 2012 22:43:52 +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 Kc41+KxrC4ve for ; Tue, 29 May 2012 22:43:51 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 64BDF39E031 for ; Tue, 29 May 2012 22:43:51 +0200 (CEST) Message-ID: <4FC53507.3080902@alvestrand.no> Date: Tue, 29 May 2012 22:43:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 20:43:53 -0000 On 05/29/2012 07:02 PM, Cameron Byrne wrote: > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? Is there a standard Javascript API defined for access to SIM-based identity services? Once that exists, it seems to be all a Small Matter Of Javascript. As long as that does not exist, we seem to be building without a foundation. From igor.faynberg@alcatel-lucent.com Tue May 29 14:16:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98B21F86A5 for ; Tue, 29 May 2012 14:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[AWL=-0.398, 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 dH7CAnE+7zAl for ; Tue, 29 May 2012 14:16:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46521F86A3 for ; Tue, 29 May 2012 14:16:53 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4TLGqXx012505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 May 2012 16:16:52 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4TLGqd3021546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 May 2012 16:16:52 -0500 Received: from [135.222.232.150] (USMUYN0L055118.mh.lucent.com [135.222.232.150]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4TLGpTE005928; Tue, 29 May 2012 16:16:51 -0500 (CDT) Message-ID: <4FC53CC3.3090306@alcatel-lucent.com> Date: Tue, 29 May 2012 17:16:51 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FC53507.3080902@alvestrand.no> In-Reply-To: <4FC53507.3080902@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 21:16:54 -0000 Right, and I would not even require that it be Javascript. Say, it is device-specific so only the browser can use it. Igor On 5/29/2012 4:43 PM, Harald Alvestrand wrote: > On 05/29/2012 07:02 PM, Cameron Byrne wrote: >> Is there yet a pointer on how a SIM / IMS based identity will work >> with the webRTC web server for authentication? > Is there a standard Javascript API defined for access to SIM-based > identity services? > > Once that exists, it seems to be all a Small Matter Of Javascript. > As long as that does not exist, we seem to be building without a > foundation. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Wed May 30 01:54:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8121F86C8 for ; Wed, 30 May 2012 01:54:02 -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=[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 4gGmRIA+3Inu for ; Wed, 30 May 2012 01:54:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD121F86D7 for ; Wed, 30 May 2012 01:54:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-6f-4fc5e02781b0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 54.80.28636.720E5CF4; Wed, 30 May 2012 10:53:59 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Wed, 30 May 2012 10:53:58 +0200 Message-ID: <4FC5E024.1010206@ericsson.com> Date: Wed, 30 May 2012 10:53:56 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPJMWRmVeSWpSXmKPExsUyM+Jvra76g6P+Bgv/Klms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmX97MVtMlWzNv5nqWBsVmii5GTQ0LARKLzz3N2CFtM4sK9 9WxdjFwcQgKnGCVuznrLBOGsZZRoe3yfCaSKV0Bb4svjM6wgNouAqsTF29PB4mwCNhJru6cA 2RwcogJhEqsfaECUC0qcnPmEBcQWEVCXuPzwAjtIibCAhsT/uWDVzAL2Eg+2loFUMAvISzRv nc0MYgsJ6Eq8e32PdQIj3ywkg2YhdMxC0rGAkXkVo3BuYmZOermhXmpRZnJxcX6eXnHqJkZg IB3c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFRudZhx l/1WWo/Ns9jkU/lfrRWeNl4ruadetEf+xPuGjsC+nbe9q52KD5iliHLe2nPBa+ON/zx6/K3V KcclZu6zXXEimqUoZvea3O13o8orAubXBOstehzu94FJIjHlWXTAD811HBJno2oKZ/7a3Hny +aEdC8qOvPis/m/fR40Srg/L/j6476nEUpyRaKjFXFScCABYNEXA8gEAAA== Subject: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:54:02 -0000 The rtcweb chairs asked for input on the use-case document on April 27th [1]. Browsing the emails that followed, I note: 1. Proposal for a call center use case (made by Jim Barnett) [2] 2. Proposal to add peer-to-peer file sharing to the simple video comm service (made by Tim Terriberri) [3] 3. Comments related to security, SRTP and key exchange, F20 (by Dan Wing) [4] 4. Request for clarifying “eavesdropping”, Andrew Hutton [5] 5. Enterprise policies use-cases proposed, Roman Shpount [6] 6. Multiparty with low complex central node, Stefan Håkansson [7] 7. Multiparty with central node that can not decipher media Oscar Ohlsson [8] 8. Four new reqs proposed (to be mapped to either new or existing use-cases), one additional use-case proposed, by Cullen Jennings [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP address to A 8b. Req: B can tell that the encrypted media is from A and not from a MITM 8c. Req: Be able to switch off Voice activity detection (if present) 8d. Req: Be able to prioritize between streams New use-case: “Collaboration between companies with node [in media path] that does/can not decipher media” 9. Proposal from Magnus Westerlund to clarify the language a bit [10] regarding 4. in this list Is anything important missing from the list above? Going through this list (and the discussion that followed on each item) it seems quite clear that: A. The language should be clarified (as Magnus proposed [10]), e.g. to clarify that also the data channel should be encrypted (this relates to 3. and 9. in the previous list) B. One more derivative of the “Simple Video Communication Service” use-case should be added to add peer-to-peer file sharing (this proposal got some support, no objection, and was also mentioned many times during the MV interim) C. There is no need to clarify “eavesdropping” (item 4. in the previous list); EKR proposed to do that as part of the security document instead D. For the new requirements proposed by Cullen (8a - d in the previous list), 8a and 8b can be incorporated in existing use cases, 8c is already covered in the “Distributed Music Band” use-case, 8d can be added to the “Hockey Game Viewer” use case. Regarding 8d it can be noted that there is already a requirement on "being able to use priority functions in network nodes" (F24); 8d would be different and relate more to how the browser reduces send rate for different flows as a response to e.g. network congestion. The reqs seem uncontroversial to me. Unless there are objections to this, the editors plan to update the document according to A - D above. It is less clear on what to do regarding the call-center use case [2], the enterprise policies use-cases [6] and the two use-cases where a central node (in the media path) must not be able to access deciphered media [8] and [9]; I think this should be discussed at the interim meeting. Comments? Stefan [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html [4] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html [5] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html [6] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html [7] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html [8] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html [9] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html [10] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html From Markus.Isomaki@nokia.com Wed May 30 02:14:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48F321F86C8 for ; Wed, 30 May 2012 02:14:40 -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 c1jPJjgAV60v for ; Wed, 30 May 2012 02:14:40 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D771321F8698 for ; Wed, 30 May 2012 02:14:39 -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 q4U9EYst023197; Wed, 30 May 2012 12:14:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 12:14:34 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.96]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Wed, 30 May 2012 11:14:33 +0200 From: To: , Thread-Topic: [rtcweb] authenticating against IMS HSS/HLR Thread-Index: AQHNPbz4jeohEtU82U6vZNW1Ji5hFpbiCy1g Date: Wed, 30 May 2012 09:14:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.24.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 May 2012 09:14:34.0344 (UTC) FILETIME=[A0FFF680:01CD3E44] X-Nokia-AV: Clean Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:14:41 -0000 Hi, RFC 4169 defines digest-AKA, which is how SIM-card based AKA authentication= is used within the context of HTTP digest. It could be used for user authe= ntication for HTTP after TLS has been setup.=20 There are some platforms that enable SIM access to at least some special ap= plications. Presumably browser could be one of them and a Javascript API co= uld be also exposed to apps if needed. The web server would need a Radius interface to operator HLR/HSS. I don't know if anything else would be needed. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Cameron Byrne >Sent: 29 May, 2012 20:03 >To: rtcweb@ietf.org >Subject: [rtcweb] authenticating against IMS HSS/HLR > >Is there yet a pointer on how a SIM / IMS based identity will work with th= e >webRTC web server for authentication? > >I think the obvious approach is for the SIM secret key to be bound to a >username / password on the web server, and the web server proxies the >authentication and registration into IMS (if you give me the right usernam= e >credentials via the web, i will register you into IMS with the secret key)= , but >that requires the undesirable step of exposing the SIM secret key to the w= eb >server or someplace outside the HSS/HLR for binding with the username >password. > >Thoughts? Pointers? > >Thanks, > >CB >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed May 30 02:31:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4B21F86DF for ; Wed, 30 May 2012 02:31:48 -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 LZDBndLhNEuF for ; Wed, 30 May 2012 02:31:48 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C621F86DD for ; Wed, 30 May 2012 02:31:46 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT8XpASUJ6zM9ZdqJj26ul7e6YG4znu/Z@postini.com; Wed, 30 May 2012 02:31:46 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 30 May 2012 05:32:10 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 30 May 2012 15:01:40 +0530 From: "Ravindran, Parthasarathi" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Regarding the use-case document Thread-Index: AQHNPkHH1GnjCWGVq0iTWXWu67SC5ZbiCn9A Date: Wed, 30 May 2012 09:31:39 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> References: <4FC5E024.1010206@ericsson.com> In-Reply-To: <4FC5E024.1010206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:31:49 -0000 Stefan, 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" identi= ty for agents (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295= .html) and also Andrew Hutton mentioned the same in the another mail (http:= //www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) 2) Also in another mail thread, "Anonymous" identity for customer is discus= sed as part of http://www.ietf.org/mail-archive/web/rtcweb/current/msg0425= 4.html In case any more information required for clarity, please let me know. Also= , I'm fine with discussion about these usecase in interim meeting. =20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Stefan Hakansson LK >Sent: Wednesday, May 30, 2012 2:24 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Regarding the use-case document > >The rtcweb chairs asked for input on the use-case document on April 27th >[1]. > >Browsing the emails that followed, I note: > >1. Proposal for a call center use case (made by Jim Barnett) [2] > >2. Proposal to add peer-to-peer file sharing to the simple video comm >service (made by Tim Terriberri) [3] > >3. Comments related to security, SRTP and key exchange, F20 (by Dan >Wing) [4] > >4. Request for clarifying "eavesdropping", Andrew Hutton [5] > >5. Enterprise policies use-cases proposed, Roman Shpount [6] > >6. Multiparty with low complex central node, Stefan H=E5kansson [7] > >7. Multiparty with central node that can not decipher media Oscar >Ohlsson [8] > >8. Four new reqs proposed (to be mapped to either new or existing use- >cases), one additional use-case proposed, by Cullen Jennings [9]. Reqs: >8a. Req: When A calls B, B does not reveal their IP address to A 8b. >Req: B can tell that the encrypted media is from A and not from a MITM >8c. Req: Be able to switch off Voice activity detection (if present) 8d. >Req: Be able to prioritize between streams New use-case: "Collaboration >between companies with node [in media path] that does/can not decipher >media" > >9. Proposal from Magnus Westerlund to clarify the language a bit [10] >regarding 4. in this list > >Is anything important missing from the list above? > >Going through this list (and the discussion that followed on each item) >it seems quite clear that: > >A. The language should be clarified (as Magnus proposed [10]), e.g. to >clarify that also the data channel should be encrypted (this relates to >3. and 9. in the previous list) > >B. One more derivative of the "Simple Video Communication Service" >use-case should be added to add peer-to-peer file sharing (this proposal >got some support, no objection, and was also mentioned many times during >the MV interim) > >C. There is no need to clarify "eavesdropping" (item 4. in the previous >list); EKR proposed to do that as part of the security document instead > >D. For the new requirements proposed by Cullen (8a - d in the previous >list), 8a and 8b can be incorporated in existing use cases, 8c is >already covered in the "Distributed Music Band" use-case, 8d can be >added to the "Hockey Game Viewer" use case. Regarding 8d it can be noted >that there is already a requirement on "being able to use priority >functions in network nodes" (F24); 8d would be different and relate more >to how the browser reduces send rate for different flows as a response >to e.g. network congestion. The reqs seem uncontroversial to me. > >Unless there are objections to this, the editors plan to update the >document according to A - D above. > > > >It is less clear on what to do regarding the call-center use >case [2], the enterprise policies use-cases [6] and the two use-cases >where a central node (in the media path) must not be able to access >deciphered media [8] and [9]; I think this should be discussed at the >interim meeting. > >Comments? > >Stefan > >[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >[3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >[4] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >[5] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >[6] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >[7] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >[8] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >[9] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >[10] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From goran.ap.eriksson@ericsson.com Wed May 30 05:06:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9921F86CE for ; Wed, 30 May 2012 05:06:58 -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 DO+hThbndut7 for ; Wed, 30 May 2012 05:06:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D589F21F86A1 for ; Wed, 30 May 2012 05:06:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-1a-4fc60d5f8fd8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.5D.28636.F5D06CF4; Wed, 30 May 2012 14:06:56 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.214]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 30 May 2012 14:06:55 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Cullen Jennings , "rtcweb@ietf.org" Date: Wed, 30 May 2012 14:06:54 +0200 Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: Ac0zA5qZVcnRZnjIR+yvH/t7O1ABcgLVSGfw Message-ID: References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> In-Reply-To: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW4C7zF/gx5ni47JbBZr/7WzOzB5 TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZP3vmMxa8V6yYumkGWwNjg3QXIyeHhICJxPrO P2wQtpjEhXvrgWwuDiGBU4wSEw/2MYEkhAQWMkq0X7UAsdkEvCWmrTjLCmKLANmd/7qYQWwW AVWJBc1tYHFhgWCJgxv2skHUhEhcnXiGHcI2klh45B5YPa9AuMS5/xNYIebbSPzZ/wqshlPA VuLQiiWMIDajgKzE/e/3WEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBD1MhKnFv1nhajX k7gxdQobhK0tsWzha6i9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc9HJDvdSi zOTi4vw8veLUTYzA+Di45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwGirW3rOIXSt7VZzr7Whf52K1a6eurjsnfGWZu5DP2OC4ixPPnWcsEH1UekmU0Ov 2ry891bKO1qu3La8Wlydm8UY9s/m0ePLr94stc6ymhGnXx74/4Rp3QpPj09+hSIvX+X/PxJ5 n93Nbv987ppZXtJ7OmQiOMu8l8+9HfN7xS3O9c9TDS9Yz1RiKc5INNRiLipOBADMNq4+XQIA AA== Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:06:58 -0000 Hi Cullen Inline. G=F6ran=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: den 16 maj 2012 03:31 > To: rtcweb@ietf.org > Subject: [rtcweb] Comments on=20 > draft-ietf-rtcweb-use-cases-and-requirements-07 >=20 >=20 > Cone and symmetric nat are probably not what exactly what we=20 > mean here - perhaps just refer to it as the various types of=20 > NATs described in RFC 4787.=20 >=20 > Might want to add to some use case that when A calls B, and B=20 > does not reveal their IP address to A. >=20 > Like to add Alice calls Bob with an encrypted media. Bob can=20 > tell the that the encrypted media is from Alice and not from an MITM >=20 > Like to add ability to make a call in a situation where even=20 > small sounds from microphone should be sent to the other side=20 > and not filtered out. Emergency calls are examples of this as=20 > are some games and "jam session" >=20 > Like to add case where application has one two video streams=20 > but one is far more important than the other. Should be a way=20 > to make sure that preferential treatment is given the the=20 > important stream over the less important streams.=20 I agree that this is a relevant area to address to secure that WebRTC is co= mpetitive compared to apps done in native OS's, especiallin in enterprise context. The current use case document states something like "being able to use prio= rity functions in network nodes". This is vague since it touches many matters such as whether to put audio an= d video on the same IP-flow or have them in different ones, which is essential when considering mapping on LTE radio channels; th= e potential use of DS to identify flows, which may be relevant in enterprise context, etc, how to cater for treament of st= uff on the datagram channel, multihoming consequences, etc. I am not sure however how far into such matters we should go in this WG, bu= t given the importance of making a good solution working across OS's and browser vendors and access technologi= es, I am leaning towards support a discussions about such details in this WG for instance using the use case document. What is Your take of this?=20 >=20 > In F22, "the IVR" -> "an DTMF based IVR" >=20 > I have a hard time deciding what level the requirements=20 > should be at. It seems likely that given the level they are=20 > currently at, the requirements are somewhat incomplete. As=20 > long as we treat these as partial set of requirements derived=20 > from the use cases, I'm fine with that.=20 >=20 >=20 > New use case: >=20 > Imagine a service like webex that facilitates collaboration=20 > between two companies called A and B. Webex has no need to=20 > see the content of the communication from A to B. So webex=20 > might run the web server that helps set up a RTCWeb session=20 > between A and B, but webex needs to be able to write it's=20 > code such that it does not get the keying material used to=20 > encrypt the media from A to B and the companies need to be=20 > able to verify that webex did not get the keys. Webex has no=20 > need to see the media from A to B and if it can provide this=20 > sort of promise that it does not get the media, it makes it=20 > much easier for a customer (say Juniper) to use webex and=20 > know the contents of their calls are not being sold or used=20 > by a competitor. Given how much WebRTC will be used by cloud=20 > services, this is an important feature. When installing the=20 > "webex" application in the browser and granting permissions=20 > to the application, it would be good to have one of the=20 > permissions be if the JS got access to the media or keying=20 > material for it to enforce this promise.=20 >=20 > Note this use case is not phrase to say this is the only way=20 > it can work. This is not mutually exclusive with they type of=20 > use cases described by Skype folks where there is an=20 > explicitly desire to make sure the calling service does have=20 > the keys to decrypt the media.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From igor.faynberg@alcatel-lucent.com Wed May 30 07:40:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3584111E80C0 for ; Wed, 30 May 2012 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=0.205, 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 vDeW9U8s9zYk for ; Wed, 30 May 2012 07:40:05 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 973D311E8099 for ; Wed, 30 May 2012 07:40:05 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4UEe4Ab021822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 May 2012 09:40:04 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4UEe4ZI008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 May 2012 09:40:04 -0500 Received: from [135.244.3.66] (faynberg.lra.lucent.com [135.244.3.66]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q4UEe3da015792; Wed, 30 May 2012 09:40:03 -0500 (CDT) Message-ID: <4FC63143.9010709@alcatel-lucent.com> Date: Wed, 30 May 2012 10:40:03 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:40:06 -0000 On 5/30/2012 5:14 AM, Markus.Isomaki@nokia.com wrote: > ... > There are some platforms that enable SIM access to at least some special applications. Presumably browser could be one of them and a Javascript API could be also exposed to apps if needed. Could you please supply a reference to any such platform? > The web server would need a Radius interface to operator HLR/HSS. Actually, it would have been Diameter, but in reality the web server cannot (and should not) talk to HSS directly; it will talk to an entity that maps the IMS identity to OpenID or whatever other identity is used. Igor >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of ext Cameron Byrne >> Sent: 29 May, 2012 20:03 >> To: rtcweb@ietf.org >> Subject: [rtcweb] authenticating against IMS HSS/HLR >> >> Is there yet a pointer on how a SIM / IMS based identity will work with the >> webRTC web server for authentication? >> >> I think the obvious approach is for the SIM secret key to be bound to a >> username / password on the web server, and the web server proxies the >> authentication and registration into IMS (if you give me the right username >> credentials via the web, i will register you into IMS with the secret key), but >> that requires the undesirable step of exposing the SIM secret key to the web >> server or someplace outside the HSS/HLR for binding with the username >> password. >> >> Thoughts? Pointers? >> >> Thanks, >> >> CB >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cb.list6@gmail.com Wed May 30 08:01:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDDA21F866A for ; Wed, 30 May 2012 08:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 KmtTW2UXqeuW for ; Wed, 30 May 2012 08:01:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5640E21F863D for ; Wed, 30 May 2012 08:01:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so68717pbc.31 for ; Wed, 30 May 2012 08:01: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:content-transfer-encoding; bh=4sysqphKhy80W18k1GQFnEKtoEyKEHZIyvCOvIEFJso=; b=pCWWPC2KSUmvVW5V2fZEjya2SZAJCM4JJSUS/m+gp2r3Uy9Ue+40pOB8s1+g0P5VaQ pp5C5LpiTKI8n8WXIrvn75SLMCCjU7e9p2bToFtKzvvRkL1YOPHOr/Rqq3Ci6Ox6cyqs 2eRIL8yp8sKPHVklgmMmpcLxkjYox4qKkWtFkaRaMYmvTPBMbl5bmQWlz/VE0XJ7jxna E9rqQtHCotpsDTniCfjtfkYoOZaUeXIcmCHTzCDxstQ4kkkp1sAv4UiO4u9bPFvP3RCc IKgyJd6bGPQvR2H05RScdgJV2WZ9Z5yvVHP+5FM0s55Q87h6gR8Wp67oLrBJh5NrQgRq rsOA== MIME-Version: 1.0 Received: by 10.68.230.68 with SMTP id sw4mr7363143pbc.142.1338390072068; Wed, 30 May 2012 08:01:12 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Wed, 30 May 2012 08:01:11 -0700 (PDT) In-Reply-To: <4FC51269.1010707@alcatel-lucent.com> References: <4FC51269.1010707@alcatel-lucent.com> Date: Wed, 30 May 2012 08:01:11 -0700 Message-ID: From: Cameron Byrne To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 15:01:13 -0000 On Tue, May 29, 2012 at 11:16 AM, Igor Faynberg wrote: > Cameron, > > Indeed, there is a lot of interesting work done in this field. (A few > thousand messages back you will find some postings on the subject, includ= ing > mine.)=A0 A few references will follow, but first--the problem. > > The problem is the access to "the SIM secret key."=A0 The latter is > unavailable by design: all ISIM operations are performed by the card. IMS > itself builds on the AKA protocol, which establishes the necessary keys. > From there, 3GPP recommends bootstrapping using the Generic Bootstrapping > Architecture. 3GPP defines this in detail in 3GPP TS 33.220. > > 3GPP has a technical report, TR 33.924, which specifies an implementation= of > OpenID with GBA. One problem here is=A0 client deployment.=A0 Until GB fu= nction > is deployed in the Client, it is, of course, impossible to use any soluti= on > that depends on it. > Thanks, this is probably the pointer i need. GBA is already available to me and we have it deployed in the network and on devices. I will need to do more reading on this and how it all really works. The goal is that the IMS service is completely abstracted from the UE and the IMS services and associated identities can be fully instantiated on any devices that has a WebRTC browser (smart tv, wifi-only tablet, refrigerator...) Cameron > Hence the alternative solution: to use AKA. My colleagues and I have > described a way to do so in a Bell Labs Technical Journal paper > http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/abstract. > Subsequently, a method to implement OpenID/AKA interworking has been > specified by ITU-T in =A0 Recommendation=A0 Y.2722 NGN Identity Managemen= t > Mechanisms. (All ITU-T Recommendations as well as 3GPP documents are > available on their respective sites.) > > But the latter solution is still a non-solution as long as there is no > client API for interactions with the SIM card. And this was the conclusio= n > of a discussion on this list a while ago... > > We need either such an API or GBA deployment to progress. > > Igor > > > > > > On 5/29/2012 1:02 PM, Cameron Byrne wrote: > > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? > > I think the obvious approach is for the SIM secret key to be bound to > a username / password on the web server, and the web server proxies > the authentication and registration into IMS (if you give me the right > username credentials via the web, i will register you into IMS with > the secret key), but that requires the undesirable step of exposing > the SIM secret key to the web server or someplace outside the HSS/HLR > for binding with the username password. > > Thoughts? Pointers? > > Thanks, > > CB > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From stefan.lk.hakansson@ericsson.com Thu May 31 00:27:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8E21F8657 for ; Thu, 31 May 2012 00:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 bRc2ex3UmpCt for ; Thu, 31 May 2012 00:27:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8421F8655 for ; Thu, 31 May 2012 00:27:57 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-dd-4fc71d7cf159 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.16.00702.C7D17CF4; Thu, 31 May 2012 09:27:57 +0200 (CEST) Received: from [150.132.142.229] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Thu, 31 May 2012 09:27:56 +0200 Message-ID: <4FC71D7A.9040601@ericsson.com> Date: Thu, 31 May 2012 09:27:54 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4FC5E024.1010206@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VrdW9ri/wZ2nHBa3Tp9hsVj7r53d gcljyZKfTB6XPv9nD2CK4rJJSc3JLEst0rdL4Mo4vuItS8ER/YrlTyYzNTA2qXcxcnJICJhI TL0+gRXCFpO4cG89WxcjF4eQwClGiXetB5hAEkICaxklWrcJg9i8AtoSb/4+YAaxWQRUJfoO NbCD2GwCNhJru6cA1XNwiAqESax+oAFRLihxcuYTFhBbRMBC4vbSzWwgNrOAusSdxefAWoUF TCXaXj1jhFiVL/Hs9zGwGk6BAImeNz2MEPW2EhfmXGeBsOUlmrfOZoao15V49/oe6wRGwVlI 1s1C0jILScsCRuZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiBgXpwy2+DHYyb7osdYpTmYFES 59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFOf55d6M59B8PqWH0Clxv8eeG4Y+2s 4DPKobMMZtoIPkhUdnx/QtGO+XHJqfVzZnP4lj0yrV6VPM3o1Kz5y4PlFAPf61R9ree5vzW4 p+ubkMXBzty1eivDTBmWLdN9tSZGOyTQ99zTP/c1WPZGzPEUVxGOvVBWve3pAr4f6xY+M/z+ fsG3YxeVWIozEg21mIuKEwHCzZ3lIgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:27:59 -0000 On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: > Stefan, > > > 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" > identity for agents > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) > and also Andrew Hutton mentioned the same in the another mail > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) > > 2) Also in another mail thread, "Anonymous" identity for customer is > discussed as part of > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html > > In case any more information required for clarity, please let me > know. Also, I'm fine with discussion about these usecase in interim > meeting. Hi Partha, I would prefer if we discussed this at the interim before adding. The main reason is that the use-case document, and requirements, currently focus on media and data streams. When doing the first draft we deliberately left things like identity handling, find-and-connect and so on out of scope. This was partly inspired by the charter (that talks about enabling innovation on top of a set of basic components - those being peer-to-peer audio, video and data) and partly from that there are already a lot of web services used every day which has solved this - they have implemented presence, text chat, messaging, ... already and in theory it would be simple to add video etc. if we just got those "basic components" in place. If the use-case document is to be updated to cover things like identity, user management and so on that would be a big change, and I would prefer that to be discussed before starting actual work. Br, Stefan > > Thanks Partha > >> -----Original Message----- From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: >> [rtcweb] Regarding the use-case document >> >> The rtcweb chairs asked for input on the use-case document on April >> 27th [1]. >> >> Browsing the emails that followed, I note: >> >> 1. Proposal for a call center use case (made by Jim Barnett) [2] >> >> 2. Proposal to add peer-to-peer file sharing to the simple video >> comm service (made by Tim Terriberri) [3] >> >> 3. Comments related to security, SRTP and key exchange, F20 (by >> Dan Wing) [4] >> >> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] >> >> 5. Enterprise policies use-cases proposed, Roman Shpount [6] >> >> 6. Multiparty with low complex central node, Stefan Håkansson [7] >> >> 7. Multiparty with central node that can not decipher media Oscar >> Ohlsson [8] >> >> 8. Four new reqs proposed (to be mapped to either new or existing >> use- cases), one additional use-case proposed, by Cullen Jennings >> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP >> address to A 8b. Req: B can tell that the encrypted media is from A >> and not from a MITM 8c. Req: Be able to switch off Voice activity >> detection (if present) 8d. Req: Be able to prioritize between >> streams New use-case: "Collaboration between companies with node >> [in media path] that does/can not decipher media" >> >> 9. Proposal from Magnus Westerlund to clarify the language a bit >> [10] regarding 4. in this list >> >> Is anything important missing from the list above? >> >> Going through this list (and the discussion that followed on each >> item) it seems quite clear that: >> >> A. The language should be clarified (as Magnus proposed [10]), e.g. >> to clarify that also the data channel should be encrypted (this >> relates to 3. and 9. in the previous list) >> >> B. One more derivative of the "Simple Video Communication Service" >> use-case should be added to add peer-to-peer file sharing (this >> proposal got some support, no objection, and was also mentioned >> many times during the MV interim) >> >> C. There is no need to clarify "eavesdropping" (item 4. in the >> previous list); EKR proposed to do that as part of the security >> document instead >> >> D. For the new requirements proposed by Cullen (8a - d in the >> previous list), 8a and 8b can be incorporated in existing use >> cases, 8c is already covered in the "Distributed Music Band" >> use-case, 8d can be added to the "Hockey Game Viewer" use case. >> Regarding 8d it can be noted that there is already a requirement on >> "being able to use priority functions in network nodes" (F24); 8d >> would be different and relate more to how the browser reduces send >> rate for different flows as a response to e.g. network congestion. >> The reqs seem uncontroversial to me. >> >> Unless there are objections to this, the editors plan to update >> the document according to A - D above. >> >> >> >> It is less clear on what to do regarding the call-center use case >> [2], the enterprise policies use-cases [6] and the two use-cases >> where a central node (in the media path) must not be able to >> access deciphered media [8] and [9]; I think this should be >> discussed at the interim meeting. >> >> Comments? >> >> Stefan >> >> [1] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >> [2] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >> [3] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >> [4] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >> [5] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >> [6] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >> [7] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >> [8] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >> [9] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >> [10] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From Jim.Barnett@genesyslab.com Thu May 31 06:05:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF56C21F869A for ; Thu, 31 May 2012 06:05: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 JVQotWZRFA5r for ; Thu, 31 May 2012 06:05:22 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id E9F6821F8650 for ; Thu, 31 May 2012 06:05:22 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q4VD5EPT000202; Thu, 31 May 2012 06:05:15 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 06:05:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2012 06:04:17 -0700 Message-ID: In-Reply-To: <4FC71D7A.9040601@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Regarding the use-case document Thread-Index: Ac0+/upU8FjbfbKmSt2zOvFaLlK9PgALcLCQ References: <4FC5E024.1010206@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> <4FC71D7A.9040601@ericsson.com> From: "Jim Barnett" To: "Stefan Hakansson LK" , "Ravindran, Parthasarathi" X-OriginalArrivalTime: 31 May 2012 13:05:14.0743 (UTC) FILETIME=[04EF0070:01CD3F2E] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:05:23 -0000 Yes, let's set aside some time to discuss this at the interim. When I = brought up call center use cases a while ago, we reached the conclusion = that the webRTC endpoint was the corporate gateway/ACD and that anything = behind it (including the agent) was out of scope (which is another way = of saying that it could work any way the corporation wanted.) The = result was that call centers fell under legacy inter-op and no changes = were needed to the use cases. =20 In general corporate/call center uses of webRTC will be important, so = it's worth going over this once more to make sure we agree on how they = fit into the framework. - Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Stefan Hakansson LK Sent: Thursday, May 31, 2012 3:28 AM To: Ravindran, Parthasarathi Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding the use-case document On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: > Stefan, > > > 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" > identity for agents > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) > and also Andrew Hutton mentioned the same in the another mail > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) > > 2) Also in another mail thread, "Anonymous" identity for customer is=20 > discussed as part of=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html > > In case any more information required for clarity, please let me know. = > Also, I'm fine with discussion about these usecase in interim meeting. Hi Partha, I would prefer if we discussed this at the interim before adding. The = main reason is that the use-case document, and requirements, currently = focus on media and data streams. When doing the first draft we = deliberately left things like identity handling, find-and-connect and so = on out of scope. This was partly inspired by the charter (that talks about enabling = innovation on top of a set of basic components - those being = peer-to-peer audio, video and data) and partly from that there are = already a lot of web services used every day which has solved this - = they have implemented presence, text chat, messaging, ... already and in = theory it would be simple to add video etc. if we just got those "basic = components" in place. If the use-case document is to be updated to cover things like identity, = user management and so on that would be a big change, and I would prefer = that to be discussed before starting actual work. Br, Stefan > > Thanks Partha > >> -----Original Message----- From: rtcweb-bounces@ietf.org=20 >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: >> [rtcweb] Regarding the use-case document >> >> The rtcweb chairs asked for input on the use-case document on April=20 >> 27th [1]. >> >> Browsing the emails that followed, I note: >> >> 1. Proposal for a call center use case (made by Jim Barnett) [2] >> >> 2. Proposal to add peer-to-peer file sharing to the simple video comm = >> service (made by Tim Terriberri) [3] >> >> 3. Comments related to security, SRTP and key exchange, F20 (by Dan=20 >> Wing) [4] >> >> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] >> >> 5. Enterprise policies use-cases proposed, Roman Shpount [6] >> >> 6. Multiparty with low complex central node, Stefan H=E5kansson [7] >> >> 7. Multiparty with central node that can not decipher media Oscar=20 >> Ohlsson [8] >> >> 8. Four new reqs proposed (to be mapped to either new or existing >> use- cases), one additional use-case proposed, by Cullen Jennings=20 >> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP=20 >> address to A 8b. Req: B can tell that the encrypted media is from A=20 >> and not from a MITM 8c. Req: Be able to switch off Voice activity=20 >> detection (if present) 8d. Req: Be able to prioritize between streams = >> New use-case: "Collaboration between companies with node [in media=20 >> path] that does/can not decipher media" >> >> 9. Proposal from Magnus Westerlund to clarify the language a bit [10] = >> regarding 4. in this list >> >> Is anything important missing from the list above? >> >> Going through this list (and the discussion that followed on each >> item) it seems quite clear that: >> >> A. The language should be clarified (as Magnus proposed [10]), e.g. >> to clarify that also the data channel should be encrypted (this=20 >> relates to 3. and 9. in the previous list) >> >> B. One more derivative of the "Simple Video Communication Service" >> use-case should be added to add peer-to-peer file sharing (this=20 >> proposal got some support, no objection, and was also mentioned many=20 >> times during the MV interim) >> >> C. There is no need to clarify "eavesdropping" (item 4. in the=20 >> previous list); EKR proposed to do that as part of the security=20 >> document instead >> >> D. For the new requirements proposed by Cullen (8a - d in the=20 >> previous list), 8a and 8b can be incorporated in existing use cases,=20 >> 8c is already covered in the "Distributed Music Band" >> use-case, 8d can be added to the "Hockey Game Viewer" use case. >> Regarding 8d it can be noted that there is already a requirement on=20 >> "being able to use priority functions in network nodes" (F24); 8d=20 >> would be different and relate more to how the browser reduces send=20 >> rate for different flows as a response to e.g. network congestion. >> The reqs seem uncontroversial to me. >> >> Unless there are objections to this, the editors plan to update the=20 >> document according to A - D above. >> >> >> >> It is less clear on what to do regarding the call-center use case=20 >> [2], the enterprise policies use-cases [6] and the two use-cases=20 >> where a central node (in the media path) must not be able to access=20 >> deciphered media [8] and [9]; I think this should be discussed at the = >> interim meeting. >> >> Comments? >> >> Stefan >> >> [1] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >> [2] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >> [3] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >> [4] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >> [5] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >> [6] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >> [7] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >> [8] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >> [9] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >> [10] >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >> _______________________________________________ rtcweb mailing list=20 >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu May 31 06:31:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4394921F8675 for ; Thu, 31 May 2012 06:31:43 -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 2bRqbfQK7PaH for ; Thu, 31 May 2012 06:31:42 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id E30F121F865E for ; Thu, 31 May 2012 06:31:41 -0700 (PDT) Received: from [192.168.157.66] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 3EBF737A906; Thu, 31 May 2012 14:40:45 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Thu, 31 May 2012 14:31:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B307791-B30F-4F65-A7A0-965E171E429F@phonefromhere.com> References: <4FC5E024.1010206@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> <4FC71D7A.9040601@ericsson.com> To: "Jim Barnett" X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:31:43 -0000 Much as I hate to re-open this, I think there is a significant use-case = for Agents using webRTC, especially in pop-up (e.g. campaign based) call centers. This would (potentially be the reverse of the case you described, with = webRTC on the inside,=20 probably still talking through the ACD/gateway. So, yes, this merits some further discussion in my view too. T. On 31 May 2012, at 14:04, Jim Barnett wrote: > Yes, let's set aside some time to discuss this at the interim. When I = brought up call center use cases a while ago, we reached the conclusion = that the webRTC endpoint was the corporate gateway/ACD and that anything = behind it (including the agent) was out of scope (which is another way = of saying that it could work any way the corporation wanted.) The = result was that call centers fell under legacy inter-op and no changes = were needed to the use cases. =20 >=20 > In general corporate/call center uses of webRTC will be important, so = it's worth going over this once more to make sure we agree on how they = fit into the framework. >=20 > - Jim >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Stefan Hakansson LK > Sent: Thursday, May 31, 2012 3:28 AM > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Regarding the use-case document >=20 > On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: >> Stefan, >>=20 >>=20 >> 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" >> identity for agents >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) >> and also Andrew Hutton mentioned the same in the another mail >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) >>=20 >> 2) Also in another mail thread, "Anonymous" identity for customer is=20= >> discussed as part of=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html >>=20 >> In case any more information required for clarity, please let me = know.=20 >> Also, I'm fine with discussion about these usecase in interim = meeting. >=20 > Hi Partha, >=20 > I would prefer if we discussed this at the interim before adding. The = main reason is that the use-case document, and requirements, currently = focus on media and data streams. When doing the first draft we = deliberately left things like identity handling, find-and-connect and so = on out of scope. >=20 > This was partly inspired by the charter (that talks about enabling = innovation on top of a set of basic components - those being = peer-to-peer audio, video and data) and partly from that there are = already a lot of web services used every day which has solved this - = they have implemented presence, text chat, messaging, ... already and in = theory it would be simple to add video etc. if we just got those "basic = components" in place. >=20 > If the use-case document is to be updated to cover things like = identity, user management and so on that would be a big change, and I = would prefer that to be discussed before starting actual work. >=20 > Br, > Stefan >=20 >>=20 >> Thanks Partha >>=20 >>> -----Original Message----- From: rtcweb-bounces@ietf.org=20 >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >>> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: >>> [rtcweb] Regarding the use-case document >>>=20 >>> The rtcweb chairs asked for input on the use-case document on April=20= >>> 27th [1]. >>>=20 >>> Browsing the emails that followed, I note: >>>=20 >>> 1. Proposal for a call center use case (made by Jim Barnett) [2] >>>=20 >>> 2. Proposal to add peer-to-peer file sharing to the simple video = comm=20 >>> service (made by Tim Terriberri) [3] >>>=20 >>> 3. Comments related to security, SRTP and key exchange, F20 (by Dan=20= >>> Wing) [4] >>>=20 >>> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] >>>=20 >>> 5. Enterprise policies use-cases proposed, Roman Shpount [6] >>>=20 >>> 6. Multiparty with low complex central node, Stefan H=E5kansson [7] >>>=20 >>> 7. Multiparty with central node that can not decipher media Oscar=20 >>> Ohlsson [8] >>>=20 >>> 8. Four new reqs proposed (to be mapped to either new or existing >>> use- cases), one additional use-case proposed, by Cullen Jennings=20 >>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP=20 >>> address to A 8b. Req: B can tell that the encrypted media is from A=20= >>> and not from a MITM 8c. Req: Be able to switch off Voice activity=20 >>> detection (if present) 8d. Req: Be able to prioritize between = streams=20 >>> New use-case: "Collaboration between companies with node [in media=20= >>> path] that does/can not decipher media" >>>=20 >>> 9. Proposal from Magnus Westerlund to clarify the language a bit = [10]=20 >>> regarding 4. in this list >>>=20 >>> Is anything important missing from the list above? >>>=20 >>> Going through this list (and the discussion that followed on each >>> item) it seems quite clear that: >>>=20 >>> A. The language should be clarified (as Magnus proposed [10]), e.g. >>> to clarify that also the data channel should be encrypted (this=20 >>> relates to 3. and 9. in the previous list) >>>=20 >>> B. One more derivative of the "Simple Video Communication Service" >>> use-case should be added to add peer-to-peer file sharing (this=20 >>> proposal got some support, no objection, and was also mentioned many=20= >>> times during the MV interim) >>>=20 >>> C. There is no need to clarify "eavesdropping" (item 4. in the=20 >>> previous list); EKR proposed to do that as part of the security=20 >>> document instead >>>=20 >>> D. For the new requirements proposed by Cullen (8a - d in the=20 >>> previous list), 8a and 8b can be incorporated in existing use cases,=20= >>> 8c is already covered in the "Distributed Music Band" >>> use-case, 8d can be added to the "Hockey Game Viewer" use case. >>> Regarding 8d it can be noted that there is already a requirement on=20= >>> "being able to use priority functions in network nodes" (F24); 8d=20 >>> would be different and relate more to how the browser reduces send=20= >>> rate for different flows as a response to e.g. network congestion. >>> The reqs seem uncontroversial to me. >>>=20 >>> Unless there are objections to this, the editors plan to update the=20= >>> document according to A - D above. >>>=20 >>>=20 >>>=20 >>> It is less clear on what to do regarding the call-center use case=20 >>> [2], the enterprise policies use-cases [6] and the two use-cases=20 >>> where a central node (in the media path) must not be able to access=20= >>> deciphered media [8] and [9]; I think this should be discussed at = the=20 >>> interim meeting. >>>=20 >>> Comments? >>>=20 >>> Stefan >>>=20 >>> [1] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >>> [2] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >>> [3] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >>> [4] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >>> [5] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >>> [6] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >>> [7] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >>> [8] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >>> [9] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >>> [10] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >>> _______________________________________________ rtcweb mailing list=20= >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu May 31 08:01:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA821F8710 for ; Thu, 31 May 2012 08:01:52 -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 KTzOB6xVkY6p for ; Thu, 31 May 2012 08:01:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 292D221F8700 for ; Thu, 31 May 2012 08:01:52 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A23A722E25B; Thu, 31 May 2012 11:01:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4FB34CAD.80103@ericsson.com> Date: Thu, 31 May 2012 09:01:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FB2E8FC.40404@thaumas.net> <4FB34CAD.80103@ericsson.com> To: Milan Young , public-media-capture@w3.org X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] TCP vs UDP for media X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:01:53 -0000 You should take this as a requirement to the public-media-capture@w3.org = list (added to thread). It seem reasonable to want to specify which = codec the data returned from getusermedia should use.=20 On May 16, 2012, at 12:43 AM, Magnus Westerlund wrote: > On 2012-05-16 03:37, Young, Milan wrote: >> Yes, existing web technologies for transport would work fine. In >> fact I wrote a demo based on WebSockets, the AudioAPI, and >> getUserMedia. But it's a bit cludgy and only transmits PCM audio. >>=20 >> Would my use case for live access to an encoded media stream be a >> good fit for a revised MediaStreamRecorder? Would this group the >> right place to host such an effort? >=20 > I think this is something you should take to the W3C. As it appear to = be > primarily an API question. Getting access to the content in the JS > application or request the browser to record to a local file which = later > can be uploaded it would not be in this WG. >=20 > Cheers >=20 > Magnus Westerlund > WG chair >=20 >>=20 >> Thanks >>=20 >> -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com] >> Sent: Tuesday, May 15, 2012 4:47 PM To: Ralph Giles Cc: Young, >> Milan; rtcweb@ietf.org Subject: Re: [rtcweb] TCP vs UDP for media >>=20 >> On Tue, May 15, 2012 at 4:38 PM, Ralph Giles >> wrote: >>> On 12-05-15 4:22 PM, Young, Milan wrote: >>>=20 >>>> I'm wondering if any thought has been given to TCP as a media >>>> transport. >>>=20 >>> Where low latency transmission isn't an issue, one can generally >>> fall back to established TCP-based protocols, like HTTP streaming >>> and websockets, so we haven't really worried about that angle in >>> the context of webrtc. >>>=20 >>> Recording the stream is a requirement, so probably something could >>> be built using that, merging recordings from each endpoint to fix >>> up any dropped packets. >>=20 >> Agreed. This seems like something that could be done using just=20 >> getUserMedia() plus existing Web technologies. >>=20 >> -Ekr _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
On Mon, May 7, 2012 at 10:10 P= M, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent= .com> wrote:

You raise a good point since = some candidates may be released before cloning occurs. =A0So this is another bug in the procedure.=A0 I would suggest that the configuration also be passed to the CPC and that if any of the required candidates are released before cloning occurs that they be reallocated.

=A0

Alternately, we could recomme= nd that candidates be kept allocated longer than usual and that if cloning is attem= pted after any of the candidates are released then the cloning procedure fails.<= u>

=A0

The latter approach should be= sufficient for SIP forking scenarios, but others may prefer the generality of the form= er.=A0 Or maybe both?=A0 Any votes?

=A0


My suggestion was that instead of t= he clone method to have a method that returns reference to the offer object= . This separate object holds the candidates while references to it exist. W= hen this object is passed during creation of peer connection, peer connecti= on is initialized as a clone of an existing peer connection This way applic= ation has the explicit control of the ICE candidate lifetimes. I would thin= k this would be the most flexible.=A0
On May 6, 2012 11:54 AM, "Ejzak, Richard P = (Richard)" <ric= hard.ejzak@alcatel-lucent.com> wrote:

Harald asked for a proposal for PeerConnection cloning,= so here it goes:

=C2=A0

I propose to create a new constructor =E2=80=9CClonePee= rConnection=E2=80=9D (CPC below) with the following semantics.

=C2=A0

  1. CPC will create a new PeerConnection object when successful.=C2=A0 The resulting PC behaves = just like any other PC except as described below.
  2. CPC will take as input a reference to an existing PeerConnection (PC) object (no configuration = or IceCallback parameters).
  3. CPC can clone any other PC (including a cloned PC).=C2=A0 The sequence of cloning is not importan= t and parents have no particular status different from any generation of clone.
  4. CPC will fail if either the local description of the parent PC is not set or the parent PC ICE is = in ICE_CLOSED or ICE_GATHERING state.=C2=A0 The parent PC can be in the OPENING or ACTIVE state.
  5. The CPC object will inherit the local streams, local ICE candidates, and local description of the PC.<= u>
  6. The remote streams and remote description for the CPC object will be set to empty.
  7. The CPC object will be set to the OPENING state to reflect that only the local description is set.
  8. The ICE states other than CLOSED and GATHERING will be handled independently for each PC and its clones (as is true in standard forking scenarios).
  9. The ICE state for this clone will be set to ICE_WAITING to reflect that all candidates are availabl= e but the remote configuration is not yet set.
  10. The PC and its clone(s) use a common pool of media resources.
  11. If the parent PC object has already released unused resources (final ANSWER), resources are reallocated as available to reflect the capabilities for each stream (= as they would be reflected in a createOffer).=
  12. The local streams might multicast toward the remote targets depending on the directionality attributes independently set for each PC and clone.
  13. The application should manage the directionality attributes for remote streams from different target= s to avoid resource conflicts.

=C2=A0

CPC will be used primarily if forking is anticipated or actually occurs. =C2=A0It can also be used to clone a stable PC if desired = for other reasons. =C2=A0When used for SIP forking, creation of the clone can b= e delayed until an ANSWER actually arrives from a 2nd target as lo= ng as final ANSWER hasn=E2=80=99t been applied to the parent (PRANSWER is OK).= =C2=A0The parent always handles the first target; the first clone handles the 2n= d target; etc. =C2=A0The application can even try to clone for forking after = the first ANSWER is applied to the parent and resources are released, as long a= s the local description has not changed, at the risk that some resources need= ed for the 2nd target are no longer available and must be renegotia= ted.

=C2=A0

Comments on this proposal are welcome.

=C2=A0

Richard

=C2=A0


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

On Wed, May 9, 2012 at 4:18 AM, Likepeng <likepeng@huawei.com= > wrote:

I think it is useful to have such a draft which provides a mappin= g between SIP and ROAP/JSEP protocols.

=C2=A0

Previously Cullen has an expired draft related to this:=

http://tools.ietf.org/html/draft-jenning= s-rtcweb-signaling-gateway-00

=C2=A0

Some time ago, I submitted a draft to map ROAP with XMPP/Jingle.<= u>

http://datatracker.ietf.org/doc/draf= t-li-rtcweb-roap-jingle-interworking/

=C2=A0

I need to update it to reflect the JSEP concept.

=C2=A0

I would appreciate if anybody has interest to work with me about = this.

=C2=A0

Thanks,

Kind Regards

Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Avasaral= a, Ranjit
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:<= /span> 2012=E5=B9=B45=E6=9C=889=E6=97=A5 14:49
=E6=94=B6=E4=BB=B6=E4=BA=BA: rtcwe= b@ietf.org
=E4=B8=BB=E9=A2=98: [rtcweb] Mapping between SIP and ROAP/JSEP

=C2=A0

Hi

=C2=A0

Is there any interest in the co= ming up with a mapping between SIP and ROAP/JSEP protocols?=C2=A0 Though JS= EP is a set of APIs as of now which map closely with ROAP APIs, ROAP has me= ssages like OFFER,ANSWER and OK which can be mapped to SIP.

=C2=A0

Comment?

=C2=A0

Thanks

=C2=A0

Regards

Ranjit

=C2=A0


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